A Portal Architecture Review Talk Overview n n

A Portal Architecture Review

Talk Overview n n n Portal architectures JSR 168 review A motivating example Building grid clients with the Java COG. Combining the Java COG with Java Server Faces.

A Famous Web Portal

A Famous Portal, After Login

What to Notice n After logging in, my colors, layouts, and content all changed. • I get my stock list, my Bloomington weather, my news stories, etc. • I got rid of “Garfield” n As we will see later, each of these content fragments (encircled) is managed by a thing called a portlet… • … I don’t guarantee that this is true for Yahoo’s web site but it is true for a large class of enterprise Java portal systems. n Portlets are the key to portal software reuse.

Let 10, 000 Flowers Bloom n Many portal projects have been launched since late ’ 90 s. • Hot. Page from SDSC, NCSA efforts, DOD, DOE Portals, NASA IPG • 2002 Special Issue of Concurrency and Computation: Practice and Experience. n The field continues to be active • Global Grid Forum 14 Science Gateway workshop in June 2005. • About 15 gateways will be described in upcoming issue of Concurrency. • GCE 2005 workshop at Supercomputing 05. n n http: //www. ggf. org/ggf_events_lodging_ggf 15. htm How do we share and reuse all of this work?

Three-Tiered Architecture Portal User Interface Grid and Web Protocols JDBC, Local, or Remote Connection Portal Client Stub Database Service Database Portal Client Stub Grid Resource Broker Service HPC or Compute Cluster Portal Client Stub Information and Data Services Grid Information Services, SRB Three-tiered architecture is accepted standard for accessing Grid and other services

JSR 168 Overview Java Portlet Stadard

What Is a Portlet? n n A portlet is a piece of Java code that manages the content of one section of a web portal’s HTML. It can do anything else that a Java web application can do. • You can connect a portlet to a database, invoke a web service, download an RSS feed, etc. n n It lives in a portlet container, which creates, manages, and destroys all the portlets of the portal. Portlet containers are part of portals. • Portals must do other things like manage login, users, groups, layouts, etc. n JSR 168 standardizes two main things: • How the portlet container manages portlet lifecycles • How the portlets are programmed.

What is JSR 168? n From the portlet development point of view, it is really very simple: • You write a java class that extends Generic. Portlet. • You override/implement several methods inherited from Generic. Portlet. • You use some supporting classes/interfaces n n n Many are analogous to their servlet equivalents Some (portletsession) actually seem to be trivial wrappers around servlet equivalents in Pluto. I have a complete example in the extended slides. • See also tutorial slides.

Some Open Source JSR 168 Containers n Grid. Sphere • http: //www. gridsphere. org n u. Portal • http: //www. uportal. org n Life. Ray • http: //sourceforge. net/projects/lportal n e. Xo platform • http: //www. exoplatform. com n String. Beans • http: //www. nabh. com/projects/sbportal n Jetspeed 2 • http: //portals. apache. org/jetspeed-2/

Some Generic. Portlet. java Methods Method Description Init Called when the portlet is created. Override if you need to set initial params. do. View Controls what happens immediately before the portlet is displayed in view mode. Normally you override this. do. Help, do. Edit Other portlet display modes process. Action Place for handling any <form> actions before turning over to the display mode method (like do. View). You should override this for web forms.

Some Supporting Classes/Interfaces Class Description Portlet. Context Similar to servlet context; get context info and the Request. Dispatcher from here. Portlet. Session Stores attribute information for a single portlet application across multiple requests. Render. Request, Render. Response The request and response objects available to the do. View() method. Similar to the normal servlet request Action. Request, Acti The request and response objects available on. Response to the process. Action() method. Similar to the servlet request and response objects. Portlet. URL Use this to create URLs that reference the portal. Portlet. Request. Disp Use this to include/forward to a JSP or atcher servlet in the same portlet app. Window. State See if you are in minimized, maximized, normal state.

The Big Picture n n As a portlet developer, the previous set of classes are all you normally touch. The portlet container (Pluto) is responsible for running your portlets. • Init, invoke methods, destroy. n Portlets have a very limited way of interacting with the container. • The API is basically one-way.

A Comment on Portlet Coding n JSR 168 seems to make some important and dubious assumptions • Developers will gladly ignore other development methodologies/frameworks like Velocity, Struts, and Java Server Faces. • Developers instead want to write a Generic. Portlet extension for every single portlet they develop. n And write really complicated process. Action() and do. View() methods. • Developers will like the specific JSR 168 portlet-style Model -View-Controller that it forces on them. n Fortunately, these other development environments can be mapped to portlet actions. • In the OGCE project, we have developed support for Velocity portlets. • We are transitioning to Java Server Faces

A Grid Portlet Scenario Developing a Simple Grid Portlet Application

A Quantum Chemistry Code Submission Form n n You have been asked to develop a submission form for the Democritos group’s Quantum Espresso (QE) package. These forms should help users set up and run QE applications on the Tera. Grid and other Grid installations. • Mix of GT 2, GT 4, Condor, etc. , for submission n n You are told to initially support the Plane Wave Self Consistent Field (PWSCF) code. Other QE applications may follow. • These may be coupled with PWSCF into simple workflows, but this is a later problem.

Your Deployment Architecture Your portal server runs at FSU. Portal Server @FSU It acts as a common Gateway to different grid toolkit installations and resources GT 4 @TG Tera. Grid LSF GT 2 @UMN MSI PBS

Some Issues n You decide the JSR 168 style portlets are the way to go… • But of course the PWSCF portlet doesn’t exist yet. n You will need to also support other Quantum Espresso codes. • Would like to reuse as much code as possible. • But your PWSCF portlet isn’t reusable at that level. n You also would like to simplify saving user input data and session archiving.

PWSCF Web Forms for Submission

Your Choices n n n JSR 168 will allow you to share your portlet code with other collaborators. The Java COG Kit will help hide the differences between Grid toolkits for common tasks. Vanilla JSF will help simplify your portlet development in several ways. • JSF decouples your backing code from the Servlet API n n You can write your backing code as pure Java Beans/Plain Old Java Objects. You don’t have to adopt, maintain HTTP parameter name conventions. • Your form input backing beans can be serialized/deserialized with Castor. n Coupling JSF and COG will allow you to compose your Grid actions using simple JSF taglibs. • You can reuse your Grid taglibs in other Quantum Espresso portlets. • You can compose composite actions

The Java Co. G Kit Gregor von Laszewski Argonne National Laboratory University of Chicago gregor@mcs. anl. gov http: //www. cogkit. org (as interpreted by MEP)

Co. G Kits n n Co. G Kits make Grid programming simple and new technologies are easy to integrate We focus on a Co. G Kit for Java • Python also available (K. Jackson, LBNL) • Availability: Java Co. G Kit since 1997 n The Co. G provides two important things • A higher level client programming environment than stubs. • A shield against different versions of the Globus toolkit n Same high level API works with GT 2. 4, GT 3. 0. 2, GT 3. 2. 0, GT 3. 2. 1, GT 4. 0. 0

Co. G Abstraction Layers Nano materials Bio. Disaster Informatics Management Applications Portals Development Support Co. GGridfaces. Layer Co. G Grid. IDE Co. GDataand and. Task. Management. Layer Co. GAbstraction. Layer Co. G GT 2 Co. G GT 3 OGSI classic Co. G GT 4 WS-RF Co. G Condor Unicore Co. G SSH Co. G Others Avaki SETI

Task Handler Task Specification The class diagram is the same for all grid tasks (running jobs, modifying files, moving data). Service Security Context Classes also abstract toolkit provider differences. You set these as parameters: GT 2, GT 4, etc. Service Contact

Java COG Summary n The Java COG 4 interfaces provide high level abstractions for building Grid clients. • Abstract out differences between Grid toolkits. • Provide task abstractions that form the basis for constructing DAG-style, file-based workflow. n The COG can be used to build a wide range of clients • Desktops, grid shells, and of course portals. • Portlets are a well known way to build reusable portal components.

Building Grid Portlets with Java Server Faces

Limitations of Portlets n Portlets provide a way to bundle and share a complete application. • RSS portlet, Grid. FTP portlet, SRB portlet, etc. • Portlets combine the user interface view and action code. n But in science gateway development, we often need finer grained components. • “When user clicks button, upload file, launch code, and move data someplace when done. ” • Combines “Grid. FTP” and “Job Submit” portlets… • Or maybe OGSA-DAI or SRB or …. n We need a way for the view and action code must be developed from reusable parts.

JSF and Science Gateways n JSF enables you back your science application input form portlets with Java Beans. • Again, these are independent of the servlet container, so are easy to test and to reuse in other applications. n But also, Java Beans can be easily serialized with XML. • Castor, XML Beans • Marshal and un-marshal user input for persistent storage in XML storage services n OGSA-DAI, GPIR, WS-Context • Potentially, can develop backing code as XML Schema and generate the code.

JSF for Grid Enabled HTML Widgets n Natural program: develop Java Bean wrappers around Java COG kit, OGSA-DAI client API, SRB Jargon, etc. • Allows simple integration with JSF. n Some issues exist • JSF only manages individual bean instances. • But grid portlets will need to manage an unknown number of bean instances. n You may launch and monitor many different jobs. • We need a way of scripting composite actions created out of multiple reusable actions.

COG Bean Wrappers n Recall the COG structure • Executable tasks abstract basic grid actions and hide toolkit version differences. • These tasks can be collected into file-based DAG workflows. n First problem is simple: wrap tasks as beans to make them available to JSF. • Generic. Grid. Bean defines the interface n Second problem is managing multiple individual tasks.

Managing Multiple Grid Tasks n We must create and manage multiple beans for each task. • That is, I submit the job four times in one session. • Similarly, we can create multiple task graph clones. n n We do this by cloning and storing each bean. Beans have listeners and maintain state. • Unsubmitted, active, suspended, resumed are “live” n Stored in live repository • Failed, canceled, completed, unknown are “dead” n n Stored in archive (WS-Context or other) Alternative approach: use one bean that is a bean factory for Generic. Grid. Task beans.

Task Submission Form Corresponding JSF snippets <o: task. Graph id="my. Graph" method="#{taskgraph. test}" > <o: task id="task 1" method="task. create" type="File. Transfer" /> <o: task id="task 2" method="task. create" type="Job. Submit" /> <o: task id="task 3" method="task. create" type="File. Transfer" /> <o: task. Add name="task 1" method="taskgraph. add" /> <o: task. Add name="task 2" depends="task 1" method="taskgraph. add" /> <o: task. Add name="task 3" depends="task 2" method="taskgraph. add" /> </o: task. Graph> <h: panel. Grid columns="3" > <h: output. Text value="Hostname (*) "/> <h: input. Text value="#{task. hostname}"/> </h: panel. Grid> <h: panel. Grid columns="3" > <h: output. Text value="Provider (*) "/> <h: input. Text value="#{task. provider}"/> </h: panel. Grid> <h: panel. Grid columns="2"> <h: command. Button id="submit" value="Submit" action="#{taskgraph. submit. Action}"/> <h: command. Button value="Clear" type="Reset"/> </h: panel. Grid>

Task Monitoring with JSF Data Model Corresponding Java class. public class Job { private String job. Id; private String status; private String submit. Date; private String finish. Date; } <h: data. Table value="#{job. Data. jobs}" var="job"> <h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Job ID" /> </f: facet> <h: output. Text value="#{job. Id}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Submit Date" /> </f: facet> <h: output. Text value="#{job. submit. Date}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Finish Date" /> </f: facet> <h: output. Text value="#{job. finish. Date}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Status" /> </f: facet> <h: output. Text value="#{job. status}"/> </h: column> </h: data. Table>

Extended Slides

The Java Co. G Kit Gregor von Laszewski Argonne National Laboratory University of Chicago gregor@mcs. anl. gov http: //www. cogkit. org (as interpreted by MEP)

Co. G Kits n n Co. G Kits make Grid programming simple and new technologies are easy to integrate We focus on a Co. G Kit for Java • Python also available (K. Jackson, LBNL) • Availability: Java Co. G Kit since 1997 n The Co. G provides two important things • A higher level client programming environment than stubs. • A shield against different versions of the Globus toolkit n Same high level API works with GT 2. 4, GT 3. 0. 2, GT 3. 2. 0, GT 3. 2. 1, GT 4. 0. 0

Co. G Abstraction Layers Nano materials Bio. Disaster Informatics Management Applications Portals Development Support Co. GGridfaces. Layer Co. G Grid. IDE Co. GDataand and. Task. Management. Layer Co. GAbstraction. Layer Co. G GT 2 Co. G GT 3 OGSI classic Co. G GT 4 WS-RF Co. G Condor Unicore Co. G SSH Co. G Others Avaki SETI

Task Handler Task Specification The class diagram is the same for all grid tasks (running jobs, modifying files, moving data). Service Security Context Classes also abstract toolkit provider differences. You set these as parameters: GT 2, GT 4, etc. Service Contact

Setting Up Task and Specification Task task=new Task. Impl(“mytask”, Task. JOB_SUBMISSION); task. set. Provider(“GT 2”); Job. Specification spec= new Job. Specification. Impl(); spec. set. Executable(“rm”); spec. set. Batch. Job(true); spec. set. Arguments(“-r”); … task. set. Specification(spec);

Setting Up the Service and Security Context Service service=new Service. Impl(Service. JOB_SUBMISSION); service. set. Provider(“GT 2”); Security. Context security. Context= Core. Factory. new. Security. Context(“GT 2”); //Use cred object from Proxy. Manager security. Context. set. Credentials(cred); service. set. Security. Context( (Security. Context)security. Context);

Set Up Service Contact and Finish Service. Contact service. Contact= new Service. Contact(“myhost. myorg. org”); service. set. Service. Contact(service. Contact); task. set. Service( Service. JOB_SUBMISSION_SERVICE, service); Task. Handler handler=new Generic. Task. Handler(); handler. submit(task);

Coupling Co. G Tasks n n The COG abstractions also simplify creating coupled tasks. Tasks can be assembled into task graphs with dependencies. • “Do Task B after successful Task A” n Graphs can be nested.

Java COG Summary n The Java COG 4 interfaces provide high level abstractions for building Grid clients. • Abstract out differences between Grid toolkits. • Provide task abstractions that form the basis for constructing DAG-style, file-based workflow. n The COG can be used to build a wide range of clients • Desktops, grid shells, and of course portals. • Portlets are a well known way to build reusable portal components.

Building Grid Portlets with Java Server Faces

Limitations of Portlets n Portlets provide a way to bundle and share a complete application. • RSS portlet, Grid. FTP portlet, SRB portlet, etc. • Portlets combine the user interface view and action code. n But in science gateway development, we often need finer grained components. • “When user clicks button, upload file, launch code, and move data someplace when done. ” • Combines “Grid. FTP” and “Job Submit” portlets… • Or maybe OGSA-DAI or SRB or …. n We need a way for the view and action code must be developed from reusable parts.

PWSCF Web Forms for Submission

Java Server Faces Overview n JSF can solve the reusable portlet widget problem. • JSF can also work in “standalone” mode outside of portlets. • Potentially independent of Web applications. n n n XUL and Swing widget bindings We will first examine JSF generally Conclude with integrating JSF and COG

Advantages of JSF n JSF hides communication details that connect HTML forms with backing code. • You don’t have to worry about servlet specific request, response, and session objects. • You don’t have to maintain fragile naming conventions for <input> tags. n Developers only need to develop Java. Beans and tag libraries. • Beans are independent of Web applications. • Can be easily written and tested outside of servlet containers. • Compatible popular “Inversion of Control” based systems like JSF and Spring

JSF and Science Gateways n JSF enables you back your science application input form portlets with Java Beans. • Again, these are independent of the servlet container, so are easy to test and to reuse in other applications. n But also, Java Beans can be easily serialized with XML. • Castor, XML Beans • Marshal and un-marshal user input for persistent storage in XML storage services n OGSA-DAI, GPIR, WS-Context • Potentially, can develop backing code as XML Schema and generate the code.

A JSF Example <HTML> <HEAD> <title>Hello</title> </HEAD> <%@ taglib uri="http: //java. sun. com/jsf/html" prefix="h" %> <%@ taglib uri="http: //java. sun. com/jsf/core" prefix="f" %> <body bgcolor="white"> <f: view> <h: form id="entry. Form" > <h 2> Enter some text in the form below</h 2> <h: input. Text id="user. St" value="#{multi. Event. Bean. user. String}"/> <h: command. Button id="submit" action="success" value="Submit" > <f: action. Listener type="multi. Event. Test. Listener 1"/> <f: action. Listener type="multi. Event. Test. Listener 2"/> </h: command. Button> </h: form> </f: view> </body> </HTML>

The JSF Page n Note everything with <f: > or <h: > namespace prefix is a JSF tag. • Usually, <h: > tags mimic HTML widgets. • <f: > is for non-rendered stuff. • Everything else is good old HTML. n There are three different Java classes here. • • They are all in the package multi. Event. Test multi. Event. Bean. java is just a bean with typical get/set methods. • Listener 1. java and Listener 2. java implement the javax. faces. event. Action. Listener interface. n n All 3 classes are called when you click the command button. Also, take a look at <input. Text>. This is roughly equivalent to <input name=“” value=“”>. • But no name needed. JSF handles parameter names for you and connects them to the beans you specify. • This greatly simplifies writing generic actions.

A Simple Example: Html. Data. Grid <%@ taglib uri="http: //java. sun. com/jsf/html" prefix="h" %> <%@ taglib uri="http: //java. sun. com/jsf/core" prefix="f" %> <f: view> <h 2> This shows an example of how to use Html. Data. Table to display some results. </h 2> <h: data. Table value="#{Value. Bean. item. List}" var="values" border="1"> <h: column> <f: facet name="header"> <h: output. Text value="Column 1"/> </f: facet> <h: output. Text value="#{values. value 1}"/> </h: column> <f: facet name="header"> <h: output. Text value="Column 2"/> </f: facet> <h: output. Text value="#{values. value 2}"/> </h: column> </h: data. Table> </f: view>

It Looks Like This

Some Explanation n The <h: data. Table> binds to a particular data set with value=“Value. Bean. item. List”. • Value. Bean. item. List must be java. util. List, java. sql. Result. Set or similar. • The values of these lists may be beans also. n The var=“” just defines a useful internal value. • Here, each entry in the list is set equal to “values”. • In the example, the items in the list happen to be simple beans with member variables “value 1” and “value 2” along with appropriate getter/setters. n n When you load the page, it just iterates through the entries in Value. Bean. item. List and creates the table, as you instructed. Note again there are no loops in the actual page. Also, you don’t know anything about the data you are getting.

JSF Magic: Data Models n The M in MVC is the Data Model • “Abstract” representation of a data structure n n That is, not tied to the display of the data (“view”) JSF Data. Model extension classes include • • • Arrays: wrap arrays of Java objects Lists: wraps a java. util. List of Java objects Results: for JSTL’s Result object, which itself wraps SQL Result. Sets. • Result. Sets: also for JDBC, wraps the Results. Set object directly. • Scalar: Wraps an individual Java object. n n Typically, these should follow Bean patterns for naming member data and their associated getter/setters. You can write your own specialized Data Models. • XMLData. Model, for wrapping an XML data bean, comes to mind. • RSSData. Model is another that I found. n These are associated with UIData classes in the JSF page for display. • Html. Data. Table is an example.

JSF Form Validators n The user interface stuff (<f: > and <h: >) has lots of built-in validators • Verify that input entries are integers, doubles, etc. • Verify that input entries fall within the correct range (1 to 10 in the guess. Number example). • Verify the string has the right length. n You can extend to write your own specialized validators

Integrating JSF and COG 4 Mehmet Nacar and Marlon Pierce

JSF for Grid Enabled HTML Widgets • Natural program: develop Java Bean wrappers around Java COG kit, OGSA-DAI client API, SRB Jargon, etc. – Allows simple integration with JSF. • Some issues exist – JSF only manages individual bean instances. – But grid portlets will need to manage an unknown number of bean instances. • You may launch and monitor many different jobs. – We need a way of scripting composite actions created out of multiple reusable actions.

COG Bean Wrappers • Recall the COG structure – Executable tasks abstract basic grid actions and hide toolkit version differences. – These tasks can be collected into file-based DAG workflows. • First problem is simple: wrap tasks as beans to make them available to JSF. – Generic. Grid. Bean defines the interface • Second problem is managing multiple individual tasks.

JSF Task Management Class Structure

Managing Multiple Grid Tasks • We must create and manage multiple beans for each task. – That is, I submit the job four times in one session. – Similarly, we can create multiple task graph clones. • We do this by cloning and storing each bean. • Beans have listeners and maintain state. – Unsubmitted, active, suspended, resumed are “live” • Stored in live repository – Failed, canceled, completed, unknown are “dead” • Stored in archive (WS-Context or other) • Alternative approach: use one bean that is a bean factory for Generic. Grid. Task beans.

Managing Multiple Tasks

Creating Task Graphs • COG Task Graphs correspond to composite JSF Web Form actions. – Do X, Y, and then Z when user clicks the button. • Each of these actions may be reused, but the entire action is new. • We must do two things – Wrap the COG Task. Graph. Handler with a bean and bean manager. – Provide tag bindings for defining the custom actions.

Constructing Task Graphs

Task Submission Form Corresponding JSF snippets <o: task. Graph id="my. Graph" method="#{taskgraph. test}" > <o: task id="task 1" method="task. create" type="File. Transfer" /> <o: task id="task 2" method="task. create" type="Job. Submit" /> <o: task id="task 3" method="task. create" type="File. Transfer" /> <o: task. Add name="task 1" method="taskgraph. add" /> <o: task. Add name="task 2" depends="task 1" method="taskgraph. add" /> <o: task. Add name="task 3" depends="task 2" method="taskgraph. add" /> </o: task. Graph> <h: panel. Grid columns="3" > <h: output. Text value="Hostname (*) "/> <h: input. Text value="#{task. hostname}"/> </h: panel. Grid> <h: panel. Grid columns="3" > <h: output. Text value="Provider (*) "/> <h: input. Text value="#{task. provider}"/> </h: panel. Grid> <h: panel. Grid columns="2"> <h: command. Button id="submit" value="Submit" action="#{taskgraph. submit. Action}"/> <h: command. Button value="Clear" type="Reset"/> </h: panel. Grid>

Task Monitoring with JSF Data Model Corresponding Java class. public class Job { private String job. Id; private String status; private String submit. Date; private String finish. Date; } <h: data. Table value="#{job. Data. jobs}" var="job"> <h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Job ID" /> </f: facet> <h: output. Text value="#{job. Id}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Submit Date" /> </f: facet> <h: output. Text value="#{job. submit. Date}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Finish Date" /> </f: facet> <h: output. Text value="#{job. finish. Date}"/> </h: column> <f: facet name="header"> <h: output. Text style="font-weight: bold" value="Status" /> </f: facet> <h: output. Text value="#{job. status}"/> </h: column> </h: data. Table>

Expressing Task Graphs with Tags <%@taglib uri="http: //java. sun. com/jsf/core" prefix="f"%> <%@taglib uri="http: //java. sun. com/jsf/html" prefix="h"%> <%@taglib uri="http: //www. ogce. org/gsf/task" prefix="o"%> ……… <o: task. Graph id="my. Graph" method="#{taskgraph. test}" > <o: task id="task 1" method="task. create" type="File. Transfer" /> <o: task id="task 2" method="task. create" type="Job. Submit" /> <o: task id="task 3" method="task. create" type="File. Transfer" /> <o: task. Add name="task 1" method="taskgraph. add" /> <o: task. Add name="task 2" depends="task 1" method="taskgraph. add" /> <o: task. Add name="task 3" depends="task 2" method="taskgraph. add" /> </o: task. Graph>