The Computational Grid [3] (or Grid for short) promises to be a powerful platform for computationally-intensive and data-intensive applications. Such applications come from biology [4], chemistry [], and physics [5] communities or virtual organizations [6]. Grid-enabling these applications oftentimes becomes a hurculean effort, utilizing several Grid software packages [7,8,9,10,11,12] to leverage the power and achieve performance on the Grid. Furthermore, these applications are already fairly large and complex with hundreds to thousands of input parameters; Grid-enabling these applications only increases this size and complexity due to additional setup/configuration procedures. This is a challenge for Grid application developers because they often have to expend significant additional programming effort in order to make their applications "user-friendly" for other members of their community. Oftentimes, this amounts to achieving a fine balance of constructing an user interface that reveals enough detail so that users can see the Grid "at work" but not too much detail that users get discouraged and walk away.
The three main services that an user interface provides to end-users to facilitate running their Grid-enabled applications on a particular set of resources are launching, monitoring, and archiving. The steps involved in launching an application are 1) collect all of the data/information needed to execute an application, 2) format the data/information into a request that be sent to Grid resources and/or a scheduler, and 3) send the request(s). Monitoring the launched Grid application or job involves checking generic job status information such as what resources are being used and how the job is distributed among them. Monitoring information can also be application-specific (e.g., summary graphs) to relate more intuitive progress information and can also relate quality of the job results. Finally, archiving involves storing a record of the job and its results so that it can be discovered by other collaborators.
In practice, user interfaces that perform the above functions are most often implemented as web portals or Grid portals. The advantage of Grid portals is that only the server running the Grid portal needs to have access to Grid tools and services (which are often not easy to deploy). Users of the Grid portal can then access the portal through any machine with just a web browser.
There are numerous Grid portal products currently available [] varying in their functionality and focus. However, most Grid portal products do provide a common set of core of services (e.g., credential management, file transfering, and resource management). While these portals may utilize the same underlying Grid APIs [13,14,15,16], very few share the same code which implements the interfaces inside their portal. One reason is that traditional web portal building mechanisms are fairly low-level which seems to foster monolithic designs that make it difficult to take a component from one portal and plug it into another. However, recent developments of commodity web portal frameworks aim to change this.
A web portal framework provides a generic set of high-level portal services such as account management and customization of the appearance and layout of a portal (even on a per user basis). The functionality of portal is determined by portal plug-ins called portlets. A portal provider will install a number of relevant portlets for a community and those users may load any number of portlets into their account. Each portlet is loaded into a pane and the user can arrange and nest the panes into a layout which best serves them. Existing implementations of web portal frameworks which conform to a portlet API include Jakarta Jetspeed [17] and IBM Websphere [18].
This emergence of web portal frameworks is causing a paradigm shift in Grid portal development. Programmers can now decompose their portals into portlets and share the generic components with other portal projects thus minimizing code replication. The xportlets project [19] is one such effort. However, programmers still need to construct the application-specific aspect of their Grid portal.
Traditionally, Grid portals which are customized for a particular application are referred to as science portals. The goal for a science portal is to provide end-users (i.e., application scientists) with access to an intuitive interface for executing their applications on the Grid. In previous work [20], we found that active notebooks were an effective abstraction for providing the application-specific part of a science portal. Simply put, an active notebook contains HTML forms which describe an application-specific interface and scripts to process the forms when submitted by the user. These scripts are Jython scripts and implement the application-specific aspects of launching, monitoring, and archiving jobs. These active notebook executes inside a portal framework called the XCAT Science Portal [20] which performs notebook archiving make it possible to re-execute or run similar jobs. However, the XCAT Science Portal framework suffers from the same monolithic portal design as noted earlier. Therefore, the goal of this work is to redesign the active notebook concept using commodity web portal framework technology herein referred to as a xbook.
A xbook is a self-contained application-specific user interface which works in conjunction with a xbook portlet to plug itself into a science portal. A xbook is served by a xbook server and may be discovered through a xbook directory service.
The following steps detail how a user would interact with the xbook portal architecture and is illustrated in Figure 1.1:
The rest of the document describes this xbook architecture.
