The XCAT Science Portal

Sriram Krishnan Randall Bramley Dennis Gannon

Rachana Ananthakrishnan Madhusudhan Govindaraju

Aleksander Slominski Yogesh Simmhan Jay Alameda

Richard Alkire Timothy Drews Eric Webb

Department of Computer Science, Indiana University, Bloomington, IN 47404, USA

Tel: 812-***-****, Fax: 812-***-****, abqq4k@r.postjobfree.com

National Center for Supercomputing Applications, Champaign, IL 61820, USA

Tel: 217-***-****, Fax: 217-***-****, abqq4k@r.postjobfree.com

Department of Chemical Engineering, University of Illinois, Urbana, IL 61801, USA

Tel: 217-***-****, Fax: 217-***-****, abqq4k@r.postjobfree.com

Abstract

This paper describes the design and prototype implementation of the XCAT Grid Science Por-

tal. The portal lets grid application programmers script complex distributed computations and

package these applications with simple interfaces for others to use. Each application is pack-

aged as a notebook which consists of web pages and editable parameterized scripts. The portal

is a workstation-based specialized personal web server, capable of executing the application

scripts and launching remote grid applications for the user. The portal server can receive

event streams published by the application and grid resource information published by Net-

work Weather Service (NWS) [35] or Autopilot [16] sensors. Notebooks can be published and

stored in web based archives for others to retrieve and modify. The XCAT Grid Science Portal

has been tested with various applications, including the distributed simulation of chemical pro-

cesses in semiconductor manufacturing and collaboratory support for X-ray crystallographers.

2

1 Introduction

The concept of a Science Portal was rst introduced by the National Computational Science Al-

liance (NCSA) as part of a project designed to provide computational biologists with access to

advanced tools and databases that could be shared by a community of users via web technology.

A Science Portal can be broadly de ned as an application speci c environment for using and pro-

gramming complex tasks involving remote resources. Over the past year the Science Portal concept

has been heavily in uenced by the emergence of the Grid [13] as a computational platform.

A Grid is a set of distributed services and protocols that have been deployed across a large set of re-

sources. These services include authentication, authorization, security, namespaces and le/object

management, events, resource co-scheduling, user services, network quality of service, and infor-

mation/directory services. Together these services enable applications to access and manage the

remote resources and computations. Web-based Grid Portals provide mechanisms to launch and

manage jobs on the grid, via the web. Grid Science Portals are problem solving environments that

allow scientists the ability to program, access and execute distributed applications using grid re-

sources which are launched and managed by a conventional Web browser and other desktop tools.

In such portals, scienti c 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 system ef-

fectively makes the grid into a vast and powerful computation engine that seamlessly extends the

user s desktop to remote resources like compute servers, data sources and on-line instruments.

3

This paper describes the XCAT Science Portal (XCAT-SP) which is an implementation of the

NCSA Grid Science Portal concept. XCAT-SP is based on the idea of an active document which

can be thought of as a notebook containing pages of text and graphics describing the science

of a particular computational application and pages of parameterized, executable scripts. These

scripts launch and manage the computation on the grid, and results are dynamically added to the

document in the form of data or links to output results and event traces.

XCAT-SP is a tool which allows the user to read, edit, and execute these notebook documents. The

goal of this research and the focus of this paper is to address the following set of questions.

How well does the active document model work for real scienti c applications?

How does one use scripts to steer computations from the portal?

What is a simple and ef cient mechanism to store and retrieve data speci c to each applica-

tion?

How should the portal be designed to interact with an event system to receive feedback from

the remotely executing applications?

How can a portal use a grid monitoring system to provide resource utilization information

about its environment?

2 Existing Grid Portals

The area of Grid Portal design is now an extremely active and important part of the emerging Grid

research agenda. The existing projects can be grouped into three categories :

4

User Portals for simple job submission and tracking, le management and resource selection

Portal Construction Kits, that provide the APIs necessary for a portal to communicate with

Grid services

Science Portals, as de ned earlier

In the user portal category, the NPACI Hot Page [31] is the rst and most successful system. Other

user portal projects are the European project Unicore [5], Nimrod-G from Australia [12], and the

IPG Launch Pad, which is the user portal for NASA s Information Power Grid [7] .

At least three projects provide portal construction toolkits. The Argonne Commodity Grid (CoG) [20]

toolkit is a Java interface for Globus. GPDK from Lawrence Berkeley Labs [9] is a JSP API for

CoG, and JiPANG from Tokyo Institute of Technology [28], uses Sun Microsystem s Jini [26] to

provide an interface to both CoG and networked solvers like Ninf [29] and Netsolve [8].

Science Portals have a variety of forms. Some are designed around relatively speci c application

domains. For example, the Cactus Portal [19] from the Albert Einstein Institute was originally de-

signed for black hole simulations and the ECCE/ELN [30] project from ORNL, LBNL and PNNL

is for Computational Chemical Engineering. The Lattice Portal [23] from Jefferson Labs is a user

portal for high-energy physics. One category of science portals directly addresses the problem of

building multidisciplinary applications. The Gateway project [6] and the Mississippi project [34]

use CORBA [15] and Enterprise Java Beans (EJB) [27] to build a three-tier architecture for launch-

ing and scheduling multiple applications. These two projects also use scripting to orchestrate large,

complex application scenarios. Another CORBA-based project is the Rutgers Discover portal [11]

5

which also provides a good interface for computational steering and collaborations.

3 The XCAT Science Portal

A prototype science portal that tests some of the features described above has been developed at

Indiana University with the help of the Chemical Engineering Team from NCSA. The portal dif-

fers in its architecture from the examples described above because it does not use a centralized web

server on a remote machine. Instead the portal software that runs on each user s desktop/laptop

has a built-in server. The reason for this is that the XCAT Science Portal is designed to integrate

the user s desktop environment with the remote grid resources. If the portal resides elsewhere, the

only tools the user can use to interact with the Grid is a Web browser or other HTTP clients. In

our model, the portal server provides a single, local gateway between the Grid Services and local

applications. A local web browser can still interact with it through HTTP, but other applications

may possibly communicate with it via local protocols and services, such as COM [25], .NET [24]

and Bonobo/Gnome [1].

As illustrated in Figure 1, the major components of the portal server include:

A Java-based server engine, which spawns off a set of Java Servlets that manage access to

the other components. The current version runs on Jakarta Tomcat 4.0, and is deployable as

a Web Archive (WAR) le, and works on various avors of Windows and Unix.

A notebook database. A notebook is an active document de ned by an XML object that

describes a set of resources used in a computational application. It consists of documents,

6

web pages, execution scripts, and other notebooks.

A Script Engine that is used to execute complex Grid operations. The scripting is currently

in Jython, a pure Java implementation of the Python scripting language which has become

popular with many computational scientists. We provide Jython-based interfaces to the Ar-

gonne CoG toolkit, which in turn, provides access to Globus functionality and the GSI [21]

Grid authentication mechanisms. It also has an API that allows easy access to the DOE

Common Component Architecture (CCA) services [22].

An Event Subsystem that is capable of handling event messages, which may be generated by

grid resources or user applications.

A Grid Performance Monitor that provides the user with a view of available resources, their

current loads and network loads.

A Component Browser that uses an SQL Database backend to provide the user with infor-

mation about components which can be deployed. The user can use this information to write

Jython scripts to create and wire together components.

A Remote File Management Interface that uses the GSI enabled FTP service.

3.1 The Notebook Database

The underlying directory structure of the lesystem is used as the database to support the portal.

The database stores a notebook corresponding to each computational application. Each notebook

is stored as a directory and each page of the notebook is stored in a different subdirectory. An XML

le containing meta-data about the notebook and a list of pointers and references to the pages in

the notebook is also stored in the local database. Figure 2 shows a snippet of such an XML le. It

7

describes a notebook session, with a title Notebook Intro, containing a notebook page, BigPicture.

The complete schemas can be viewed at http://www.extreme.indiana.edu/an/xsd.

The active document representing a notebook session can be converted into a Java Archive (JAR)

and the meta information about the notebook can be stored in a WebDAV [17] server. This meta

information includes the URI for the actual location of the archive. Notebook users can browse the

information about published sessions using a WebDAV client. This enables them to get information

like notebook name, author, abstract etc. about the session before actually deciding to retrieve the

archive. The author of the notebook can decide to set privileges like enabling only read or allowing

updates on the archived session by other authors. The authorization information is stored in the

WebDAV server as an Access Control List. The JAR can be published into a repository using

GSI-enabled FTP or other le transfer services. Since the JAR corresponds to an active document,

it is self-suf cient and can be simply plugged into an authorized user s local database, and is ready

to use. Thus, the portal users in a scienti c community can collaborate with their peers by sharing

data corresponding to their experiments.

3.2 Grid Application Scripting

One difference between a user portal and a science portal is the complexity of the tasks that the

portal supports. A user portal allows users to submit single jobs to the grid. The portal provides

features to make it very simple to manage the job, providing load-time and run-time information,

and to help the user select resources and to monitor the execution of the job. In a science portal,

the applications tend to be more complex. A single scienti c experiment may involve running

8

many different computational simulations and data analysis tasks. It may involve coupled multi-

disciplinary applications, collaboration, and remote software components linked together to form

a distributed application. Often these complex tasks may take a great deal of effort to plan and

orchestrate, and the entire application may need to be run many times each with a slightly different

set of parameter values. We have found that the best way to allow this sort of computation to be

carried out is to allow the scientist access to a simple scripting language which has been endowed

with a library of utilities to manage Grid applications. Furthermore, we provide a simple tool

which allows the scientist to build a web form interface to con gure and launch the scripts. Users

of the scripts simply ll in parameter values to the web form and then click the Submit button. This

launches a script which executes on the user s desktop, but manages remote applications on the

grid. Our prototype implementation uses the Jython language for scripting because it is popular

with scientists and has an excellent interface to Java, and we make the scripts grid-enabled by pro-

viding an API to Globus Services using the Cog Toolkit.

Figure 4 illustrates a portal interface, which is typically application-dependent and is con gurable

by the users. In the panel on the left, there is a view of an open notebook session. It consists of

a set of pages and script forms. In this gure, the form for a simple script which launches a local

visualization application is shown. Parameter values selected by the user from the form page are

bound to variables in the script. By selecting Edit both the script and the form page may be edited

as shown in Figure 5. In this case, the script launches a local program called animator which takes

as a parameter the name of a simulation output le to animate. In this example the script is trivial,

but it is not much more dif cult to write a script to launch an application on the grid and to manage

remote les.

9

A second form of scripting is used to manage the local details of the program s execution on a

remote site. The remote applications are managed by application managers. In most cases, the ap-

plications that the scientists and engineers want to run on the Grid are not grid aware, i.e. they are

ordinary programs that read and write data to and from les. In some cases, we have access to the

application source, but often that is not available - e.g, when using commercial applications codes.

An application manager is an agent process that helps the application make use of grid services.

For example, the manager can stage input les from remote locations or invoke post-processing

on the application output when the application has nished. The manager also serves as an event

conduit between the application and the portal. If the application dies or creates a le, the manager

can send an event back to the portal with the appropriate message. The application manager is

shown in Figure 6.

The application manager can also act as a service broker for the application. The manager can reg-

ister itself with the Grid Information Service [14] and advertise the application s capabilities. If a

user with the appropriate authorization discovers it, then the manager can launch the application on

behalf of the user and mediate the interaction with the user. For example, suppose the application

is a library for solving sparse linear systems of equations on a large parallel supercomputer. The

manager can export a remote solver interface that takes a sparse linear system as input and returns

solution vectors and error ags as output. If a user has a remote reference to the manager, the

solver can be invoked by a remote method call passing a linear system (or its URI) as a parameter

and the solution vector can be received as a result of the call. This is the model used by JiPANG to

invoke Ninf and Netsolve.

10

In the XCAT system, the application managers conform to the DOE Common Component Archi-

tecture (CCA) speci cation. XCAT is our implementation of the CCA speci cation, built on top

of XSOAP (formerly SoapRMI [32]), that allows the users to write CCA compliant components

in C++ and Java. The application managers are designed to be scriptable components, which have

one standard port providing the creator with the ability to download a script which the component

can run. The scripting language and library used by the component is identical to the language

and library available to the portal engine. The application managers combine the advantages of

a persistent remote shell with that of a remote object which may be invoked through a well de-

ned set of interfaces. Furthermore, the interfaces that a manager component supports can change

dynamically by simply downloading a new script. This allows the portal to dynamically change

the behavior of a remote application to suit new problems or requirements. For a more detailed

description of the Application Manager, including APIs, consult ProgGrid [4].

XCAT provides a Jython based scripting interface to instantiate remote components, wire them to-

gether using input and output ports and orchestrate the computations. The portal uses this scripting

interface, whose API is described in Figure 8.

3.3 Event Subsystem

The XCAT Science Portal uses the SOAP Events system [33] to decouple communication between

the scripting engine and the remote jobs launched by the portal. This decoupling ensures that the

11

remote applications can continue execution when the portal itself shuts down. Communication is

reestablished seamlessly when the portal is restarted. The events that occur in the interim are stored

by a persistent event channel and can be retrieved by the portal on restart. A remote job can be an

instantiated component that reads and writes les or a Grid Monitoring Architecture (GMA) [2]

that collects data for fault detection and performance tuning from a computational grid. Such sys-

tems can indicate their progress by sending out events at regular intervals to interested listeners.

The SOAP Events system is based on XSOAP which uses HTTP as the network protocol and

SOAP 1.1 [3] compliant XML messages as the wire protocol. By using XSOAP, the portal can

receive events from any SOAP 1.1 system. As SOAP events are just XML strings, they can be

published by writing preformatted strings onto a socket, allowing frameworks that use different

languages and platforms to publish to the channel. To make the channel rewall-friendly, we allow

the publishers to push events to the channel and the subscribers to pull events from it. Such

a model obviates the need for the event channel to initiate the communication with publishers or

listeners that may reside behind rewalls. We simulate asynchronous event noti cation to the lis-

tener by using listener agents (see Figure 10). The listener agents constantly query the channel

for newly arrived events and forward these events to the listener. The agent and the channel use a

cookie-based scheme to monitor the retrieved events. A cookie, held by the agent, has complete

state information about the progress of the event pull invocation. Using this cookie, the listener

agent can resume the pull in case the channel fails and is restarted. Publishers use similar agents

to ensure delivery of events to the channel so that network outages or failure of the channel do not

prevent the event from being sent. The publisher agents store the unsent events in a local store

and periodically retry publishing them. The listener and publisher agents can also locate a suitable

12

event channel to connect to, based on a set of constraints provided by the listener or publisher

application. Event channels register with a directory service when they start and the agents use this

service to select the channel.

The portal listener registers with the listener agent running on the local machine using Jython

scripts, as illustrated by snippets of code in Figure 11. The listener agent locates the nearest or a

well-known SOAP event channel using the directory service. The listener can use a lter to restrict

the events it receives to those that it is interested in. This ltering can be based on matching event

attributes or using SQL to query the persistent channel. Applications can provide information

about the status of their computation by publishing events to the event channel via the publisher

agent.

The event channel, in its simplest incarnation is just a listener and publisher working in tandem.

With all its features enabled, it provides for complex ltering and querying, persistence to allow

retrieval of historical events and handling of user de ned events that the channel is not aware of.

3.4 The Grid Performance Monitor

The Grid Performance Monitor (GPM) uses the event subsystem to provide the user with visual-

ization of available resources and the current and predicted future loads on these resources. The

data for these loads is obtained from the NWS. The GPM is designed as a thin layer on top of

SoapRMI events and an event channel. This provides the portal with the exibility to cooperate

13

and exchange signals/events with a vast variety of event generators.

The event visualizer component of the GPM subscribes to the event channel through its agent. The

visualizer registers interest only in those events that are for resource utilization or a related type.

Using the event channel precludes the need for a global registry of all sensors. Sensors send events

to the event channel at periodic intervals. Detection of a stoppage in events from a particular sen-

sor can be determined to be due to the failure of the sensor. Event generators that send events at

irregular intervals can be required to send simple heart-beat events at regular intervals to indicate

that they are still operational.

Figure 12 shows an example of an XML resource event. The XML Schema event system lends

itself to extensibility and self-describing event formats, thus making it possible for the portal to

interoperate with a wide variety of other event systems, including the NWS, Autopilot sensors.

Applications that are aware of their resource utilizations can also write application-level resource

events, and send it to the event channel. Thus, the user can not only receive resource utilization

information of the target machines, but also the performance information from their executing

applications.

3.5 Authentication & Security

In the future, the portal is planned to be run in one of two modes : personal or multiuser. At

present, we only support the personal mode, while work on the multiuser mode is in progress. In

both cases, the authentication is handled via the Globus GSI. The user can either use local Globus

14

credentials on the portal s server via the Globus CoG Kit, or can remotely upload credentials into

the portal via the MyProxy [10] CoG Kit. The initial startup screen has text elds for the user

to enter in the appropriate information: his/her Globus credential password for a local credential,

or a server, tag name and password for a MyProxy credential. In either case, the portal server

loads a GlobusProxy object from the relevant source for use in authentication and instantiation, on

behalf of the user. In the personal mode, only the owner is authorized to run jobs using the portal,

while in the multiuser mode the user can run jobs if he/she is permitted to use the portal, which

can be con gured by the portal owner, using some Access Control List mechanism. If cookies are

enabled by the user, the server sets a cookie object in the user s browser that maps the session to

the Proxy so that, when the user leaves the site, his/her identity isn t lost. This helps the portal do

better session management. Even if the user has disabled the use of cookies, the portal works ne,

although it loses some of its session tracking capabilities.

4 Sample Applications

The XCAT Science Portal has been used for a number of different applications. It has been used

for distributed simulation of chemical processes in semiconductor manufacturing by a team of

Chemical Engineers at NCSA, for collaboratory support by a team of X-ray crystallographers

at Indiana University, and for Linear Systems Analysis [4], and Collision Risk Assessment of

Satellites with space debris [4] by the Extreme Computing Lab at Indiana University. We describe

two of the above in the next subsections.

15

4.1 NCSA Chemical Engineering

The work done with the Chemical Engineering team from NCSA is an example of the kind of

science problems the portal is intended to solve. The simulation models the process of copper

electrodeposition in a submicron sized trench which is used to form the interconnection on micro-

processor chips. The simulation consists of two linked codes. One consists of a continuum model

of the convective diffusion processes in the deposition bath adjacent to the trench. The second

consists of a Monte Carlo model of events that occur in the near-surface region where solution

additives in uence the evolution of deposit shape and roughness during lling of the trench. The

codes communicate by sharing data les about common boundary conditions. Figure 13 shows the

coupled codes and the lter that is added to insure stability of the linked computational system.

The codes are run separately on the Grid. The transfer of les is done using grid based le-

management and transfer utilities. The interface to the Grid is provided by Application Man-

agers . As described before, these are wrappers which provide access to grid services such as GSI,

grid-events, etc. to the codes and make them grid-aware. Each execution is set-up and controlled

from the controlling Jython script which runs inside the portal. The primary mechanism for get-

ting feedback is the event system. Grid le-management tools can be used to transfer output les

which are generated. Events which come back from the applications are handed off to event han-

dlers which have been registered, or are logged. Special events could be used to trigger off event

handlers which can change or control the course of the execution.

This application illustrates several interesting scenarios in collaboration. The experiment is set up

16

by the chemical engineers using the tools provided in the portal. Simple web forms are created

for parameter input which will control the experiment. An example of one such form is shown

in Figure 15. Subsequent users do not need to know about these parameters or the mechanics of

the grid computation. They will interact with only the portal web interface and event noti cation

mechanisms.

4.2 IU Xports project

A second application is a collaboratory for X-ray crystallographers using the beam lines at Ar-

gonne s Advanced Photon Source (APS) and Lawrence Berkeley s Advanced Light Source (ALS).

This work will allow users at remote laboratories to send sample crystals to the beam lines, col-

laborate with the scientists preparing and mounting the sample, then to receive initial images of

the execution, over the network. They can then dynamically upload new control parameters or, if

the sample appears awed, terminate the run. In addition to large amounts of data (up to a Ter-

abyte/day) and numbers of les (1-3 per second) this application requires multiple video streams,

accessing high-speed research networks, and synchronous geographically distributed collabora-

tion.

The portal was used to launch part of the experimental setup from the client site. Using the Jython

controlling script and the Java Application Managers, local applications were launched and con-

trolled. The setup of the experiment closely resembled that of the Chemical Engineering one.

Events were used to get feedback on the progress of the execution.

17

5 Conclusions

This paper has described the XCAT Science Portal system. The contributions of this research

project include

providing a generic programming tool for grid application designers that allows them to

script complex applications, and access them using a simple forms based web browser inter-

face.

providing an active document model for packaging applications for collaborative purposes.

demonstrating how a grid event system can be integrated into both the grid applications and

resource monitoring to provide the user with important feedback about the runtime behavior

of his or her applications.

showing that a distributed software component architecture (in this case the DOE CCA

model) can be used as an effective tool to manage distributed applications based on legacy

software, which is not grid-aware.

6 Future Work

Future work includes integration of the resource and component directory services with the Grid

Forum standards for information services and with the emerging work on the Web Service Direc-

tory Language (WSDL) that is being advocated by industry groups. In addition, we are building

interfaces to intelligent resource brokers and building components that are capable of adapting to

available grid resources. We are working on the multiuser version of the portal, and trying to use

it for the Grid Access Portal for Physics Applications [18]. We are also working on an secure

18

implementation of SOAP, which will be built using GSI and Secure Sockets. We plan to integrate

it with a multiprotocol messaging architecture, which is capable of switching between SOAP and

binary protocols, depending upon the performance needs of the user.

7 Acknowledgements

The authors would like to thank the reviewers and the members of the Extreme Computing Labo-

ratory, Indiana University for their insightful comments. In particular, we are grateful to Kenneth

Chiu, Al Rossi and Shava Smallen, who are current staff members at the Extreme Lab, and to

Venkatesh Choppella, Rahul Indurkar, Nirmal Mukhi, Benjamin Temko and Juan Villacis, who

have been past members of the project group.

This research was supported by NSF grants 4029710 and 4029713, NCSA Alliance, and DOE2000.

19

References

[1] GNOME, visited 4-1-2001. www.gnome.org.

[2] Brian Tierney et al. White paper: A grid monitoring service architecture (draft), visited

03-10-01. http://www-didc.lbl.gov/GridPerf/papers/GMA.pdf.

[3] D. Box et al. Simple Object Access Protocol 1.1. Technical report, W3C, 2000.

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

[4] Dennis Gannon et al. Programming the Grid: Distributed Software Components, P2P and

Grid Web Services for Scienti c Applications. Journal of Cluster Computing, 2002. To

appear.

[5] Dietmar Ervin et al. The Unicore HPC Portal, visited 04-25-2001. http://www.unicore.de/.

[6] Geoffrey Fox et al. The Gateway Computational Web Portal, visited 04-27-01.

http://www.gatewayportal.org/.

[7] George Myers et al. The NASA Information Power Grid (IPG) Launch Pad Portal, visited

04-27-2001. http://www.ipg.nasa.gov/.

[8] Jack Dongarra et al. Netsolve, visited 04-27-01. http://www.cs.utk.edu/netsolve/.

[9] Jason Novotny et al. The grid portal development kit (gpdk) project, visited 04-01-01.

http://dast.nlanr.net/Features/GridPortal/.

[10] Jason Novotny et al. Myproxy, visited 04-12-01. http://dast.nlanr.net/Features/MyProxy/.

[11] Manish Parashar et al. DISCOVER, visited 04-27-01. http://www.discoverportal.org/.

20

[12] Rajkumar Buyya et al. Nimrod, A Tool for Distributed Parametric Modelling, visited 04-25-

2001. http://www.csse.monash.edu.au/ davida/nimrod.html/.

[13] Ian Foster and Carl Kesselman. The GRID: Blueprint for a New Computing Infrastructure.

Morgan-Kaufmann, 1998.

[14] Grid Forum Information Services Working Group. GGF GIS Working Group Charter, visited

06-29-01. http://www-unix.mcs.anl.gov/gridforum/gis/.

[15] Object Management Group. The Common Object Request Broker: Architecture and speci -

cation, July 1995. Revision 2.0.

[16] Pablo Group. AutoPilot : Real-Time Adaptive Resource Control, visited 04-01-2001.

http://www-pablo.cs.uiuc.edu/Project/Autopilot/AutopilotOverview.htm.

[17] IETF. WebDav, visited 8-20-01. http://www.ics.uci.edu/ ejw/authoring/.

[18] Indiana University. The grid access portal for physics applications, visited 08-14-01.

http://lexus.physics.indiana.edu/griphyn/grappa/.

[19] Albert Einstein Institute. Cactus, visited 04-27-01. http://www.cactuscode.org/.

[20] Argonne National Lab. CoG, visited 04-12-2001. http://www.globus.org/cog.

[21] Argonne National Lab. GSI, visited 04-12-2001. http://www-fp.globus.org/security/v1.1/.

[22] Argonne National Laboratory, Indiana Univeristy, The Advanced Computing Laboratory

at Los Alamos National Laboratory, Lawrence Livermore National Lab, and Univeristy

of Utah. Common Component Architectue, visited 1-10-2000. http://z.ca.sandia.gov/ cca-

forum see also http://www.extreme.indiana.edu/ccat.

21

[23] Jefferson Labs. Lattice Portal, visited 04-27-01. http://lqcd.jlab.org/.

[24] Microsoft. .NET framework, visited 02-10-01. http://www.microsoft.com/net/.

[25] Microsoft. COM, visited 4-2-2001. http://www.microsoft.com/com.

[26] Sun Microsystems. Jini, visited 3-1-2001. http://www.sun.com/jini.

[27] Sun Microsystems. EJB, visited 7-15-99. http://java.sun.com/products/ejb/index.html.

[28] Tokyo Institute of Technology. JiPang : A Jini-based Computing Portal System, visited 04-

27-01. http://matsu-www.is.titech.ac.jp/ suzumura/jipang/.

[29] Tokyo Institute of Technology. Ninf, visited 04-27-01. http://ninf.etl.go.jp.

[30] ORNL, LBNL, and PNNL. The DOE2000 Electronic Notebook, visited 04-27-01.

http://www.emsl.pnl.gov:2080/docs/collab/research/ENResearch.html.

[31] San Diego Supercomputer Center (SDSC), the University of Texas (UT), and the Univer-

sity of Michigan (UM). NPACI Hot Page, visited 04-25-2001. https://hotpage.npaci.edu/.

[32] A. Slominski, M. Govindaraju, D. Gannon, and R. Bramley. Design of an XML based Inter-

operable RMI System : SoapRMI C++/Java 1.1. In Proceedings of the International Confer-

ence on Parallel and Distributed Processing Techniques and Applications, Las Vegas, Pages

1661-1667, June 25-28 2001.

[33] Aleksander Slominski, Madhusudhan Govindaraju, Dennis Gannon, and Randall Bramley.

SoapRMI Events: Design and Implementation. Technical Report TR-549, Indiana University,

May 2001.

22

[34] Mississippi State University. The Mississippi Computational Web Portal, visited 04-27-01.

http://WWW.ERC.MsState.Edu/labs/mssl/mcwp/.

[35] Rich Wolski, Neil T. Spring, and Jim Hayes. The Network Weather Service: A Distributed

Resource Performance Forecasting Service for Metacomputing. Journal of Future Gen-

eration Computing Systems, 1999. also UCSD Technical Report Number TR-CS98-599,

September, 1998.

23

List of Figures

1. The XCAT Science Portal Architecture

2. An XML le with notebook metadata

3. The Notebook Database

4. Snapshot of XCAT SP

5. Script Page

6. XCAT Application Managers

7. Scriptability of Application Managers

8. Jython API to XCAT

9. Event visualizer showing machine utilization events

10. The Event Subsystem

11. Subscribing to an Event Channel

12. An example XML Resource Event

13. Linked Chemical Engineering Codes

14. Chemical Engineering Application Setup

15. Parameter Form

24

Workstation Environment

Web Local Viz

Browser Tools

Components

MyPortal Active Notebook Server

GSI COG Script Notebook

Authentication Grid Tools Engine Database

The Grid

Grid Soap Event

Performance Channel

Monitor

Application Application

Proxy Proxy

Wrapped Wrapped

Machine Application Application

Sensors

Figure 1: The XCAT Science Portal Architecture

25

Notebook_Intro (session)Thu Apr 19 10:54:10 EST 2001Thu Apr 19 10:54:18 EST 20011.0NotebookIntro.7444trueNotebookIntrofalseBigPicture/an/database/notebook/nNotebookIntro.7444/

pBigPicture/big_picture.htmlBigPicture1false

Figure 2: An XML le with notebook metadata

26

The Notebook Database

Notebook Server

Database Interface

Notebook 3

Notebook 2

Notebook 1

Page 1 Page 2 Script Page 1 Page 2 Page Script

Figure 3: The Notebook Database

27

Figure 4: Snapshot of XCAT SP

28

Figure 5: Script Page

29

Figure 6: XCAT Application Managers

30

Figure 7: Scriptability of Application Managers

31

def createComponent (componentInfo):

def setMachineName (componentWrapper, machineName):

def setCreationMechanism (componentWrapper, creationMechanism):

def createInstance (componentWrapper):

def connectPorts (outputPortComponent, outputPortName,

inputPortComponent, inputPortName):

def start (componentWrapper, usesPortClassName,

usesPortType, providesPortName):

def kill (componentWrapper, usesPortClassName,

usesPortType, providesPortName):

def invokeMethodOnComponent (componentWrapper, usesPortClassName,

usesPortType, providesPortName,

methodName, methodParams):

Figure 8: Jython API to XCAT

32

Figure 9: Event visualizer showing machine utilization events

33

Discovery Service

(LDAP)

subscribeLease

start/continue/

handleEvent start/continue/ endEventPull

handleEvent endEventPull

Publisher Publisher Agent Event Channels Listener Agent Listener

handleEvent array of events eventLease

handleEvent Response

Response array of events

Figure 10: The Event Subsystem

34

# A specialization of the generic EventListener

class MyEventListener(EventListener, RemoteObject,

SubscriptionRenewListener):

def __init__(self, expID):

# constructor code goes here

# Code to register with the event channel

def subscribeToListenerAgent(expID, url):

# some initialization

# create an instance of the EventListener

receiver = MyEventListener(expID)

# register with the Listener Agent

agent = Util.getLocalListenerAgent params

# Get first batch of events through agent

result = agent.startPull(timePeriod, filter)

# Consume list of events from result.events[]

while interested in more events

# Get next batch of events

result = agent.continuePull(result.cookie)

# Consume list of events from result.events[]

# Done pulling events

agent.stopPull(result.cookie)

Figure 11: Subscribing to an Event Channel

35

http://www.extreme.indiana.edu/soap/

events/resdat#MachineUtilizationEvent

resdata.machine.utilization2002-01-07T17:41:28.072Z

2002-01-07T17:41:29.151Z

rainier.extreme.indiana.eduresviz_channel0.88123988

Figure 12: An example XML Resource Event

36

Figure 13: Linked Chemical Engineering Codes

37

Science Portal

Application Application

Manager Manager

Continuum Monte Carlo

Simulation Simulation

Grid

File Management

file file

Figure 14: Chemical Engineering Application Setup

38

Figure 15: Parameter Form

Contact this candidate