Background Science Applications Physics Climate Groundwater Fusion Energy Life Sciences Materials & Chemistry SciDAC Institutes Collaboratories Enabling Technologies Applied Mathematics Computer Science Visualization & Data Mgt. SciDAC Outreach Participating Orgs Grant Solicitations FY2007 FY2006 FY2005 FY2004 FY2001 Collateral Materials SciDAC Review magazine '06 Progress Report (pdf) Publications 2001-5 (pdf) Logos Search Collateral (from SciDAC 1) Browse by Affiliation Browse by Author Browse by Title DOE Office of Advanced Scientific Computing Research (ASCR) Program Managers only

Middleware Technology to Support Science Portals: A Gateway to the Grid

Dennis Gannon, PI. Department of Computer Science, Indiana University
Randall Bramley, co-PI, Department of Computer Science Indiana University

A Science Portal is problem solving environment that allows scientists the ability to program, access and execute distributed "Grid" applications from a conventional Web Browser and other desktop tools. In such a portal, scientific domain knowledge and tools are presented to the user in terms of the application science and not in terms of complex distributed computing protocols. The goal is to allow the scientist to focus completely on the science by making the Grid a transparent extension of the user's desktop computing environment.

A Grid Portal is a point of access to a Grid system. It provides an environment where the user can access Grid resources and services, execute and monitor Grid applications and collaborate with other users. The portal provides a consistent "Grid context" for the user's Grid interactions. To understand this, consider the way we interact with a single computer. When we start-up or log-on to a computer, we are presented with a desktop and file folders and other objects such as applications, documents and even running processes that may be still running from our last login session. This environment is the users current context on that machine.

For users of Grid systems, their context consists of remote files, on-line data sources, directory services and applications, and remotely running jobs and workflows distributed over the entire set of Grid resources. In other words, for Grid users, the context is completely distributed. The portal provides a single point where the user a can access his or her current Grid context. This includes information about all recent Grid objects created or destroyed by the user while interacting with the Grid. The portal also provides a platform upon which Grid collaborations can take place. Consequently, the Portal must also provide mechanisms to share ones context, applications data objects, journals and research papers with ones collaborators.

The Grid Portal Prototype is based on two standard technologies that are perfectly suited to this task. At the user interface level, the portal is just another web site. It is based on the Java standard Jetspeed portlet engine and custom Java-based interactive tools. In the back-end, where the portal meets the specific Grid services, everything we are doing is based on the Open Grid Services Architecture (OGSA).

Figure 1: Screen dump showing Grid portlets for the Alliance collaboration portal using tools from Indiana, NCSA, Argonne, Texas and Michagan.

By adopting a standard front-end and a standard Grid back-end we are now able to integrate our work with other that have made the same commitment. Within the Global Grid Forum, we have established such as consortium. The collaborators include Indiana, NCSA, Texas, Argonne and Michigan. The key to the technology is a portal component called a portlet, which is a small unit of the portal interface that the user can easily configure into his or her environment. The approach to the design of the Grid portal is to provide the user with a family of portlets that can be configured to operate with each of the Grid Services that a user interacts with.

The current portal prototype provides users with the following set of portlets.

1. A Grid Proxy Credentials Manager that manages the users authentication certificates so that they be used by the other portlets on the users behalf.
2. Resource Browsers that provide the user with the current state of the resources that he or she is authorized to use.
3. Information Service Interfaces that provide the user with current information about the users data space. In the future this will include Data Grid interfaces as they become available.
4. Job Status Tools that allow the user the ability to monitor remote jobs.
5. Messaging Systems, which allow groups of users to post and read messages about common projects.
6. Event and logging Systems that keep track of application events and log them for later discovery from the portal. This also includes tools for journaling and recording event histories as part of experiment metadata.
7. Portlets to Access Application Factory Services, which manage the details of complex, multi-component remote applications and workflows.

The Application Factory service (see Figure 2) is one instance of the general design pattern used in the portal. Most portlets are designed to be the front end for a remote Grid Service. In fact, because of the design of the Open Grid Service Infrastructure (OGSI) it is possible to automatically derive a portlet interface dynamically from any grid service. This is because each Grid Service has a generic port that can be used to interrogate the service to determine all the properties of all of its other ports. Consequently, a service portlet can interrogate a service, discover its other ports and build an interface on the fly.

Figure 2. An application factory service is a Grid Service that can be contacted by the portal. The factory service contains a script that is executed on behalf of the user to instantiate a set components of a distributed application or an instance of a workflow engine.

Another important service of the portal is to help manage the metadata that is associated with executions of a user's applications. A metadata cache directory based on the portals event and logging system, allows the user to have a searchable index of all of his or her application notes, data-file annotations and indexes into remote metadata directories that provide the location of the actual experimental data. This component of the portal is still under design.

Availability

A prototype implementation is available to interested users. It is up and running at
http://www.extreme.indiana.edu/xportlets/.
Because the OGSA and OGSI are still being designed, an official release of the portlet code is still premature. However, we expect the first beta release by Sept. 2003. The First official release of the portlet package will be in Oct. 2003.

back to project page