This three-tiered architecture is depicted above. The figure greatly simplifies most portal systems described in  but serves as a conceptual illustration. The portal interface consists of Web interfaces that work with remote services through the service tier. The portal (presentation) layer not only must manage user information but also maintains “client stubs” that interact with a usually remote service tier. In the figure, the top-most horizontal thread illustrates a typical three-tiered scenario from e-business, in which the portal contacts the remote database through a client-server system. The server in turn contacts the database. The middle thread indicates a second user portal scenario in which a “portal client stub” accesses a Grid service through a standard Grid protocol. This service (such as a resource broker accessed through GRAM) in turn spawns a job on a High Performance Computer (HPC) system. The final thread illustrates portal access to Grid specific data and information services such as the Storage Resource Broker (SRB)  . This architecture has been widely adopted, and from this we conclude that computing portal architectures are well established, with a range of standard services for accessing the Grid through such systems as the Java  and Perl  CoG kits.
Portals, Portlets, and Clients to Grid Services Marlon Pierce Community Grids Lab Indiana University [email_address]
Globus and others in the Global Grid Forum realized that they needed to provide more than just a bag of services
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, W3C).
See http://www-128.ibm.com/developerworks/library/ws-resource/ogsi_to_wsrf_1.0.pdf for some discussion.
GT 4 release (April 2005) attempts to correct these problems.
Some Globus 2 Services v. Globus 4 Web Services
PKI X.509 certificates used for mutual authentication
GSSAPI-based socket connections
Uses Resource Specification Language (RSL)
Binds to PBS, LSF, and possibly other schedulers with third party plugins (support may vary).
Note GT 4 includes GridFTP 2.0, which is a different codebase from GridFTP 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
Your certificates work in both GT versions.
Replaces RSL with XML Job Descriptors.
Uses Reliable File Transfer and GridFTP to support file staging and multiple jobs (which is a pain to install).
Binds to PBS, LSF
Reliable File Transfer (RFT)
Uses “scheduling” techniques to do batch file transfers that don’t require persistent client connections.
Three-tiered architecture is accepted standard for accessing Grid and other services
Portal User Interface Grid Resource Broker Service Grid and Web Protocols Information and Data Services Database Service Database HPC or Compute Cluster Grid Information Services, SRB Portal Client Stub Portal Client Stub Portal Client Stub JDBC, Local, or Remote Connection
From the portlet development point of view, it is really very simple:
You write a java class that extends GenericPortlet .
You override/implement several methods inherited from GenericPortlet.
You use some supporting classes/interfaces
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 GenericPortlet.java Methods Place for handling any <form> actions before turning over to the display mode method (like doView). You should override this for web forms. processAction Other portlet display modes doHelp, doEdit Controls what happens immediately before the portlet is displayed in view mode. Normally you override this. doView Called when the portlet is created. Override if you need to set initial params. Init Description Method
Some Supporting Classes/Interfaces The request and response objects available to the processAction() method. Similar to the servlet request and response objects. ActionRequest,ActionResponse Use this to include/forward to a JSP or servlet in the same portlet app. PortletRequestDispatcher Use this to create URLs that reference the portal. PortletURL See if you are in minimized, maximized, normal state. WindowState The request and response objects available to the doView() method. Similar to the normal servlet request RenderRequest, RenderResponse Stores attribute information for a single portlet application across multiple requests. PortletSession Similar to servlet context; get context info and the RequestDispatcher from here. PortletContext Description Class
The extended example makes some important and dubious assumptions
Developers would want to write a GenericPortlet extension for every single portlet they develop.
And write really complicated processAction() and doView() 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.
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 Depends heavily on EJB. Interesting set of portlets but too non-portable. LifeRay I found this difficult to use, had some incompatibilities with CoG jars. ExoPortal Supports WSRP, JSF. I have not yet evaluated. StringBeans Supports WSRP; JSF support planned. I have used extensively, but prefer GridSphere. uPortal Supports JSF. I recommend. Popular container in scientific portal community. GridSphere Comments Container
The Java CoG Kit Gregor von Laszewski Argonne National Laboratory University of Chicago [email_address] http://www.cogkit.org
We use the COG to illustrate some basic portlet programming features.
We use the COG4 APIs in our ProxyManager, Job Submission, and GridFTP portlets
Hides differences between Globus Toolkit versions.
Is also structured to handle task-based workflow and job composition.
For more detailed examples, see the extended version of these slides.
Task Task Handler Service Task Specification Security Context Service Contact The class diagram is the same for all grid tasks (running jobs, modifying files, moving data). Classes also abstract toolkit provider differences. You set these as parameters: GT2, GT4, etd.