A Science Portal is problem solving environment that allows scientists the ability to program, access and execute distributed application using "Grid" resources which are launched and managed 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. By moving beyond the simple web browser model used in most portal efforts, we will deliver a system that allows users to integrate their favorite productivity tools (spreadsheets, Matlab, document authoring) into an open, collaborative framework. When a user goes off-line a system of active registries and user agents continue to monitor the user’s Grid state. When reconnected, the user’s environment is updated to the current state of his or her remote computations by means of event histories maintained in the Grid registry.

This project will move the concept of the science portal away from its historical ties to web browsers and a remote server to a model that is based upon peer-to-peer (P2P) and web service concepts. In this model Grid computations will be based on the concept of an "active document" which is a desktop object capable of orchestrating complex, remote grid computations. We will integrate the best collaboration and P2P technology available into the portal framework so that multiple users will be able to share views and control over the execution of Grid applications. By exploring code mobility concepts we will allow users to come and go from the Grid while a Grid-agent acts on their behalf. The same technology will also enable Grid applications to adaptively select the best executing environment to run on.

There are four emerging technologies that must be integrated to realize this vision. The first of these is the integration of DOE supported Grid technology with the emerging Web Services standards such as the Web Services Description Language (WSDL) and the web services discovery tools (UDDI). This effort will involve many groups from the Grid Forum and the Globus team. Our work will focus on those aspects that directly relate to the role of web services in the design of grid applications. The second challenge is integration of web services and Grid technology with the CCA software component work of the CCTTSS Scidac group. A CCA component is an object defined by public interfaces. In the Grid context this is process running on a computational resource which is known to the Grid middleware. In the Web Services view this is a service that is invoked by the other parts of a grid application. Part of the challenge is using WSDL to define CCA component interfaces so that they may be discovered by web services tools. This will allow them to be used by web services aware frameworks like Microsoft's .NET.

The third emerging technology is Peer-to-Peer frameworks that allow rapid deployment of collaborative applications. P2P systems like Sun's JXTA provide for group definition, resolution and discovery protocols. However these mechanisms do not use current Grid technology. Part of our task is to integrate Grid security and information services with these peer group protocols to allow users the ability to easily build collaborative Grid applications. The fourth technical area is in the design of a framework that allows us to encapsulate a grid application as an "active document" which can be easily shared with and deployed by collaborators. An active document contains three types of entities.

• "Grid Scripts" which are interpreted programs based on the Python language that launch and orchestrate the actions of a distributed computation. The scripts interact with Globus and Web services to authenticate the user and launch link together remote CCA components (which may wrap legacy applications.)
• HTML pages that describe each of the parts of the grid application and also record for the user the history of previous executions of the applications. The pages also contain forms that allow the user to pass parameters to the grid script. These parameters are used to configure the various remote components as needed by the application.
• Local components which are launched by the grid script and provide application control graphical user interfaces to the user. The local components also provide "event listeners" which can be used to monitor the execution of the grid application.

Each active document is a package that can be deployed in the users desktop portal tool which is also his or her agent in a peer-to-peer network with the rest of the collaborating team. The final technical challenge is to make it easy to build fault tolerant Grid applications. Our approach to this is to explore code mobility in frameworks like Condor and see how that can be applied to networks of communicating distributed software components.

Web-Services/Grid Integration

Collaboration

• Year 1. Asynchronous collaboration will be initially based on document sharing using the Web-DAV (Distributed Authoring and Versioning) protocol and by an XML based asynchronous messaging service. By the end of year one we will have a collaboration server in place.
• Year 2. Collaboration based on P2P frameworks will be complete by the end of year 2.
• Year 2. Synchronous collaboration will be the focus of the year three. However, we will not develop the technology for synchronous collaboration. We will adopt the prevailing standard, which we expect to be access grid technology.

Research on Grid-Portal Code Mobility

• Year 1. In the first year of the project we will survey existing code mobility technologies. For example, Condor has a limited form of code mobility. Other work on this problem has been done for mobility based on the Java virtual machine. We will need to select a technology that consistent with our use of scripting and remote objects.
• Year 2. By the end of the second year we expect to be able to move an executing active document from one platform to another without disrupting the associated Grid computations.
• Year 3. By year three we will be able to apply code mobility to adaptive Grid applications

• "DOE Science Grid: Enabling and Deploying the SciDAC Collaboratory Software Environment"-- ANL, LBNL, PNNL, ORNL, (Bill Johnston, LBNL)
• "Particle Physics Data Grid Collaborative Pilot" -- Univ of Wisc., UCSD, Cal Tech, BNL, FNAL, JLab, ANL, LBNL, SLAC (Miron Livny, UW) (jointly funded with HENP)
• "A High Performance Data Grid Toolkit: Enabling Technology for Wide Area Data-Intensive Applications," -- ANL, Univ. of Wisc., USC (Ian Foster, ANL)
• "CoG Kits: Enabling Middleware for Designing Science Applications, Web Portals and Problem Solving Environments"—ANL, LBNL (G. von Laszewski)