Portals Portlets and Clients to Grid Services Marlon

Portals, Portlets, and Clients to Grid Services Marlon Pierce Community Grids Lab Indiana University mpierce@cs. indiana. edu

Useful Links n These slides are available from here: • http: //www. servogrid. org/slide/i. SERVO/ IRIS_Web. Services_2005/ n General portlet tutorial information is available from here: • http: //www. servogrid. org/slide/i. SERVO/ NMI/OGCE 2 Tutorial. Material/ n Grid portlets are available from here: • http: //www. collab-ogce. org

Outline n n n Globus toolkit review Computational Portals and Portlets Building Grid Portlets with the Java Co. G Kit

Purpose of Talk n I am not affiliated with Globus and do not develop Globus Web Services. • I just use Globus services as-is. • My slides are from this point of view. n n n My emphasis is on building Web Portals from portlets as clients to Grid services using the Java COG kit. The Java Co. G kit project is lead by Gregor von Laszewski at Argonne National Labs I work with Gregor through the Open Grid Computing Environments project. • We build portlets using the Java Co. G n I also lead portlet and Web Service development for the NASA SERVOGrid project. • Grid services, GIS services

SERVOGrid Summary n Portlet-based portal n • Use Geographical Information System standards. • Web Feature Service • With portal extensions to support secure remote portlets. n “Execution Grid” Web Services n n • Run remote tasks using Ant job managers. • Move files around (upload, download, crossload). • Maintain persistent user session state n n Provide data portal applications. • Monitor jobs quakesim. jpl. nasa. org Encodes GPS, Seismic, and Fault data archives as GML. Working on high performance web services. • Web Map Service n n Generates interactive web maps using features and other map servers. Streaming video version in development. • Sensor Grid Services “Context” • Application metadata to describe applications. Data Grid Web Services n n n Real time streaming GPS Data mining on streams Information Grid Services • Extended UDDI • WS-Context for session metadata. www. crisisgrid. org

Globus Toolkit Overview n n The Globus Toolkit provides foundations for building “Virtual Organizations. ” Single Sign-On Authentication • Log in once, access all machines on your Grid. n Grid Security Infrastructure • Public Key Infrastructure • Generic Security Service programming interfaces n Secure Remote Resource Access • Remotely execute tasks. • Interact with both shells and queuing systems. n n Secure, high performance file transfer Information services for your grid resources.

Globus Toolkit 2. x n GT 2 services implemented as Unix services. • You quite commonly manage them through /etc/xinetd. d or similar. n Standard services in xinetd. d: • GRAM gatekeeper for running remote tasks. • Grid. FTP for file transfers n Upload, download, and third party. • MDS information services • My. Proxy: a remote credential repository so that you don’t need to keep lots of copies of your private key. n n Support for both remote shell operations and queuing systems. • • n Jim Basney at NCSA is the My. Proxy guy. PBS and LSF tend to be best supported. You may be able to find others. Many other Globus-related tools have come and gone.

Globus Toolkit and Web Services n Globus and others in the Global Grid Forum realized that they needed to provide more than just a bag of services • • n n n Needed a framework for building new services. Needed standard languages for writing service APIs Standard messaging envelopes. Web Services were the natural fit. The Open Grid Services Architecture (OGSA) outlines the basic premise of the Globus approach to Web Services. Globus Toolkit 3. x was the initial implementation of these ideas. But it was found to be unsustainable. • Initial spec (“OGSI”) was too monolithic, took to long to approve, made custom extensions to WSDL, had portions that were superseded by the main stream Web Service community, and was disconnected from the general community (OASIS, W 3 C). • See http: //www-128. ibm. com/developerworks/library/wsresource/ogsi_to_wsrf_1. 0. pdf for some discussion. n GT 4 release (April 2005) attempts to correct these problems.

Some Globus 2 Services v. Globus 4 Web Services n n PKI X. 509 certificates used for mutual authentication GSI Security n n • GSSAPI-based socket connections n n • Your certificates work in both GT versions. GRAM • Uses Resource Specification Language (RSL) • Binds to PBS, LSF, and possibly other schedulers with third party plugins (support may vary). n WS-GRAM • Replaces RSL with XML Job Descriptors. • Uses Reliable File Transfer and Grid. FTP to support file staging and multiple jobs (which is a pain to install). • Binds to PBS, LSF Grid. FTP • Note GT 4 includes Grid. FTP 2. 0, which is a different codebase from Grid. FTP 1. 17 bundled in previous Globus releases. • We have reported some incompatibilities, which I think have been addressed in GT 4. 0. 1. Still PKI X. 509 based mutual authentication… But used now with Web Service Security: SSL and WS-Security n Reliable File Transfer (RFT) • Web Service-based • Uses “scheduling” techniques to do batch file transfers that don’t require persistent client connections. • Builds on Grid. FTP.

Grid (and Web Service) Clients n Web and Grid Services run in service hosting environments. • Apache Axis, Globus WS container, etc. n Clients likewise need to run in client hosting environments. • Graphical Use Interfaces, Desktops, Web Browser Portals • But also grid and web service shells. n n Gridshell, HPSearch We will focus on portals, since these are the most common and have standards.

Building Grid Portals

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 • An upcoming issue of Concurrency will survey the current field. • Based on Global Grid Forum 14 Science Gateway workshop in June 2005. • GCE 2005 workshop at Supercomputing 05. n n http: //www. ggf. org/ggf_events_lodging_ggf 15. htm Global Grid Forum’s Grid Computing Environments (GCE) Research Group • Community forum n 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

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.

JSR 168 Overview A General Review of JSR 168

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 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. • It is a black box->black hole. • The API is basically one-way.

A Comment on Portlet Coding n The extended example makes some important and dubious assumptions • Developers would 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. • Developers will gladly ignore other development methodologies/frameworks like Velocity, Struts, and Java Server Faces. 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

Some Free JSR 168 Containers Container Comments Grid. Sphere Supports JSF. I recommend. Popular container in scientific portal community. u. Portal Supports WSRP; JSF support planned. I have used extensively, but prefer Grid. Sphere. Life. Ray Depends heavily on EJB. Interesting set of portlets but too non-portable. Exo. Portal I found this difficult to use, had some incompatibilities with Co. G jars. String. Beans Supports WSRP, JSF. I have not yet evaluated.

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

The Story So Far… n n Globus has several interesting services that can be used out of the box. Portlets can be used to build portals out of reusable parts. Portlets (as Java code) can also be used to invoke remote services. Now we will look at how to do this for Grid applications.

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 programming 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

Grid Portlet Overview n n In the tutorial examples, we look at writing JSR 168 portlets using JSP and Velocity. Grid Portlets are just portlets, and portlets are just Java applications. • Use the Java Co. G to make calls from the portlet code to the desired Grid service. • Can also make non-COG calls, such as to Grid. Port API. n These APIs are not be portlet-specific, since you should be able to reuse the Grid APIs from other Java clients. • You can also build Web Services out of them. • NCSA’s OGRE (general), Trebuchet (application specific) are examples • NCSA Tupelo also makes use of COG in its metadata management services.

COG and Portlets n n We use the COG to illustrate some basic portlet programming features. We use the COG 4 APIs in our Proxy. Manager, Job Submission, and Grid. FTP portlets • Hides differences between Globus Toolkit versions. • Is also structured to handle task-based workflow and job composition. n For more detailed examples, see the extended version of these slides.

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, etd. 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);

Summary and Future Directions n n Portlets provide a way to build reusable Web components. The Java COG kit provides a nice abstraction layer for building Grid portlets. Portlets can be written using JSP, Velocity, and JSF. In our OGCE project, we previously concentrated on Velocity but are now moving to Java Server Faces. • Provides a clear way to build reusable widgets, not just portlets. n n AJAX techniques (such as Google Maps) provide a very way to build interactive Web Service clients. There is a larger problem: can we define a general user interface component? • Portlets would be a subclass • But also include shells and desktop clients. n These components would also require standard supporting services: • Login, access control, layout management, ….

Basic Portlet Programming Guide

In Action: Get started. public class Junk. Portlet extends Generic. Portlet { public void init(){ //Do any initialization. } //Rest of the methods on following slides go here. … }

Override do. View() protected void do. View( Render. Request req, Render. Response res) throws Portlet. Exception, IOException { //Include the desired JSP or HTML page. //We could also use out to write directly to the response. Window. State state=req. get. Window. State(); if(!state. equals(Window. State. MINIMIZED)) { res. set. Content. Type("text/html"); Portlet. Request. Dispatcher rd= get. Portlet. Context(). get. Request. Dispatcher(“My. J SP. jsp”); rd. include(req, res); } }

The JSP Page <portlet: define. Objects/> <% Portlet. Session portlet. Session=render. Request. get. Portlet. Session(); portlet. Session. set. Attribute("localattname", "localattval "); Portlet. URL url=render. Response. create. Action. URL(); String the. Action. String=url. to. String(); %> HTML Content is here. A form is below. <form method=post action="<%=the. Action. String%>"> <input type=…> </form>

Some Notes n Include the <%portlet: defined. Objects/%> tag, which will instantiate render. Request, render. Response, and portlet. Config objects. • You can then just use them, as with request, response, and other JSP implicit objects. n The render. Request gives you access to the Portlet. Session, if you want to store session variables. • One of the trouble points. n n The Use render. Response gives you access to the Portlet. URL object. the Portlet. URL to generate a URL for the <form action> • So that it points to portlet container and gets handled by the process. Action() method, rather than going of into space. • Handle href URLs similarly. • This is one of the sticking points.

Lastly, Override process. Action() n n When you invoke the form on the previous JSP, the portlet container will pass the action handling to the process. Action method. The Action. Request can be used to get any of the <input> parameters in a way similar to the usual Http. Servlet. Request. When the process. Action method returns, the container then invokes the appropriate do method (usually do. View). If you need to pass <form> parameters on to do. View, add them to the Action. Response. • This will give them to the Render. Request. • The example shows how to add ALL parameters. public void process. Action (Action. Request request, Action. Response action. Response) throws Portlet. Exception, java. io. IOException { //Process request parameters … //Add any other request params // to the render. Request action. Response. set. Render. Par ameters(request. get. Paramete r. Map()); }

Deploying Portlet Applications n The portlet container (i. e. u. Portal) runs as a distinct web application. • That is, it has its own directory in tomcat. • Moreover, it runs as a separate context, with its own classloader, session management, etc. n Portlet applications are deployed as distinct war files/web applications. • You go through the container webapp to get to the portlet webapp. • Portlets in the same application share jars, classes, and runtime stuff like request and session variables. • Portlets in different portlet apps do not share anything. n JSR 168 containers vary in the specifics of their deployment procedures.

Writing Grid Portlets Extended Example

Grid Portlet Overview n n Previously we looked at writing JSR 168 portlets using JSP and Velocity. Grid Portlets are just portlets • Use the Java Co. G to make calls from the portlet code to the desired Grid service. • Can also make non-COG calls, such as to Grid. Port API. n These APIs should not be portlet-specific, since you should be able to reuse the Grid APIs from other Java clients. • NCSA’s OGRE (general), Trebuchet (application specific) are examples • NCSA Tupelo also makes use of COG in its metadata management services.

COG and Portlets n n We will use the COG to illustrate some basic portlet programming features. We use the COG 4 APIs in our Proxy. Manager, Job Submission, and Grid. FTP portlets • Hides differences between Globus Toolkit versions. • Is also structured to handle task-based workflow and job composition. n But for in-depth COG questions, we defer to Gregor’s group. • Available through AG session today. • Or docs available through www. cogkit. org n OGCE is an open consortium, and there are other alternatives. • OGRE job management builds on COG for Workflow • Grid. Port uses the GGF Community Scheduling Framework and higher level tools (job sequencers, for instance). • Use what you like

Getting Proxy Credentials n n The key ingredient is getting proxy credentials into the portal and sharing between different portlets. We use My. Proxy for this • Advantage: you don’t have to store users’ long term keys on the web server. • Disadvantage: you have to run a separate My. Proxy server; users have to put keys there outside the portal. n n You must include the OGCE 2 My. Proxy portlet (or a variation of it) in your Grid portal to do any other Grid stuff. OGCE 1 also had support for grid-proxy-init. • Would be able to add this, but you would need to manage your users’ long term keys.

n n Proxy Manager Under the Hood See ogce 2/indiana/extreme/Proxy. Manager/mod ules/portlet/src for templates and code. Templates illustrate several Velocity scripting concepts. • Control structures, variables n But the action code is more interesting. • This is where you do your Grid coding. • Use Velocity’s Context object to communicate strings back to your templates.

Proxy Manager Code n n n Key part here is the do. Get_proxy() method. Abbreviated code on the right. My. Proxy class: import from Co. G kit. GSSCredential class: standard Java security class. Proxy. Manager class: used by us to pass credentials between portlets. public void do. Get_proxy() { My. Proxy myproxy= new My. Proxy(…); GSSCredential proxy= myproxy. get(…); Proxy. Manager. add. Pr oxy(…); }

Writing Simple Job Submission Portlets n For portlets, you have to deal with two main Grid issues: • Getting the credential from the proxy store. • And then using it. n The Co. G APIs provide an additional nice layer of Grid abstraction for Grid tasks. • We will look at this for wrapping GRAM calls. n We will assume the following: • You have your project set up to be warred with maven. • You have chosen a development technology (like JSP + portlets or Velocity portlets). • You will be collecting the necessary input information from an HTML <form>. • You will be putting the action code in either the portlet (perhaps as a Java. Bean) or Velocity action handler. • All code snippets below go in this portlet/action code.

Write the Method Skeleton n In your action code, write a method to do job submission. • For Velocity, this maps to the “event. Submit_” form parameter in your template. • In portlets, this code is called by your process. Action method. n You will need to pass it, minimally, the Action. Request and Action. Response objects. public void do. Submit. Job( Action. Request req, Action. Response resp, …) { //Next, get proxy //Then, run command. }

Get the Proxy n n n Now get the proxy from the local store. The Proxy. Manager class calls the static method get. Default. Proxy to look up your credential using your portlet session. You need these imports • org. ietf. jgss. GSSCredential • xportlets. proxymanager. Pro xy. Manager. • javax. portlet. * for everything else. n This assumes that you have retrieved a credential from the My. Proxy server. public do. Submit. Job( Action. Request req, Action. Response res) { //Get the proxy Portlet. Session sess= req. get. Portlet. Session() GSSCredential cred= Proxy. Manager. get. Default. Pr oxy(sess); //Next, run command }

Run the Command n n The Co. G 4 interfaces now come into play. You should first understand the general Co. G approach. The COG 4 interfaces attempt to abstract things at several layers • Tasks: a generic Grid function n Remote command execution, file operation, or information inquiry. Has a specification and service Is run by a handler • Specification: set the type of task (job submit, etc. ) and its specific parameters. • Service: sets the Globus Toolkit (or other) provider, security context, and service contact information. • Task. Handler: runs the task. n Note this scheme is intended to shield you from programming differences of different Globus toolkits.

Making Contact with the Portal n n The remaining issue is getting information from the HTML forms to the appropriate Co. G calls. This is done through the Portlet. Request object. • Typically, it is actually the Action. Request subclass. n In your do. Submit. Job() command, just use • String param=request. get. Parameter(“Param-Name”); • “Param-Name” is replaced with the input parameter name in your HTML form. n n <input type=text name=“Param-Name” value=“rm -r *. *”> In following code snippets, “quoted strings” are usually what you would pass in from the Web form.

An Extended Code Example: 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);

Extended Code Example: 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);

Extended Example: 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);

Monitoring Tasks n Monitoring running tasks submitted by the COG is done through a status listener. • Write a class that implements Status. Listener interface • Create an instance of your listener and add it to the task: n n task. add. Status. Listener(my. Listener); There is a small problem with doing this in a portal application • The listener must be instantiated in the action code, along with the rest of the COG classes. • But these are lost after the action completes. n Simple solution: store it in the Portlet. Session • This will keep the listener object alive after the action completes • Get the session from the Portlet. Request (more typically, its subclass, Action. Request) • Sample code n n Portlet. Session session=request. get. Portlet. Session(); session. set. Attribute(“mytask”, my. Listener); • When you are curious about your task’s status, fetch it out of the session by name.