1. Alliance Chemical Engineering Portal
Jay Alameda
Alliance Chemical Engineering
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
Alameda – EHAT Team Meeting – 02 November 2000

2. Essence of the Science Portal
Share code, data, and expertise to allow experts and non-experts access to advanced tools to address substantial projects through collaborative efforts
Link data and simulations, over broad range of scales, across discipline boundaries
Alameda – EHAT Team Meeting – 02 November 2000

3. Chemical Engineering Portal Technical Plan
Protocols for sharing experimental data and codes
Mechanisms for including protected materials
Specifications for interoperability in the portal environment
Data repository with links to analysis tools
Links to thermophysical property databases
Linking codes
continuum with non-continuum
simulations with process control tools
Alameda – EHAT Team Meeting – 02 November 2000

4. Application Area Portals
Objective
To provide a web-based environment for users of a class of related applications to
Execute the apps by filling in web form information such as
application parameter values
path to input files
User doesn’t care where it runs. Just wants it run fast.
The ability to compose apps or to script parameter studies
A Repository for managing experimental sessions.
Both collaborative version and MyServer version
Alameda – EHAT Team Meeting – 02 November 2000

5. Assumptions about Portal Users/Developers
Three types of Users/Developers
Users that want to run an application from their desktop.
Don’t care if app is local or running on a remote resource
Care only about access to capability
Developers of application portal
Want to develop portal capabilities for user of a class of applications.
Want easy tools to build portal sites and integrate applications
Developers of the application “components”
want to focus on building application.
Don’t want to fuss with grid details.
Alameda – EHAT Team Meeting – 02 November 2000

6. Scientific Problem Interface
Alameda – EHAT Team Meeting – 02 November 2000

7. Alameda – EHAT Team Meeting – 02 November 2000
Scientific Problem – 2
Alameda – EHAT Team Meeting – 02 November 2000

8. Alameda – EHAT Team Meeting – 02 November 2000
Scientific Problem - 3
Alameda – EHAT Team Meeting – 02 November 2000

9. Alameda – EHAT Team Meeting – 02 November 2000
Scientific Problem 4
Alameda – EHAT Team Meeting – 02 November 2000

10. Alameda – EHAT Team Meeting – 02 November 2000
Scientific Problem 5
Alameda – EHAT Team Meeting – 02 November 2000

11. Technology Development for the Alliance Science Portal
Architecture
Dennis Gannon, Geoffrey Fox, Gregor von Laszewski, Jay Alameda
Browser Rendering Service (layoutportalML)
Visualization Service
Security
Proxy Delegation
Authorization
Event Services
Portal Information Service
Technical Content for portal
Architecutre. Gannon and Fox are doing this. See VII:96 plus next slide
Broswer Rendering: representing the Portal in a variety of browsers. The next generation will use XML (layoutportalML) to represent active components on the browser that are executing back on the server.
Visualization: A set of tools. Baker and Hibbard
Security: see notes below. Proxy is easy, authorization is harder, wiping out fingerprints is even more difficult
Events Services: Necessary for coordinating multi-scale calculations and for building collaborative Portals.
Portal Information Service: used for finding portal components. This is like a Windows NT Registry or CORBA’s component information service.
Alameda – EHAT Team Meeting – 02 November 2000

12. Technology Development, continued
Component Architecture
Composition Service
Authoring Service
Science Wrapper Team
Shared Portal in the Web
betterportalML
Collaboration Services
Data Strategy
Globus Data Grid
NPACI SRB/MCAT
Technical Content for portal
Component Architecture: Composition service is necessary to build multi-scale calculations. Authoring service allows scientists and engineers to build their own content (the ability to lay out a scientific problem so that others in front of the screen can interact with it. It is the task of creating an interactive electronic site. The expert identifies the important parameters and other interesting characteristic and provides linkages to the code that appear on the web page so that users “in front of the screen” can interact with the problem. Here is the expert behind the screen making code accessible to less expert users who want to use the code to check their data or other interests.) Science Wrapping allows code developers to easily incorporate their codes into the Portal (for starters this is the generic proxy modified by XML, and we are shooting for a wizard that does this).
Shared Portal: Allows synchronous collaboration on different Portal tools between geographically distributed collaborators.
Data Strategy: (a) Code interoperability so that data are understood across codes. (b) Finding data and recognizing what it is. Metadata about your data. Data can be on desktop, mass storage, HPC platfoms and these need to be seamlessly accessed. (c) Database interoperability involves making one query on multiple databases, preferably from within a simulation code, that returns the correct result. You don’t want to be opening ten different web sites and manually querying them and retrieving the answer and plugging it into your code.
Alameda – EHAT Team Meeting – 02 November 2000

13. The Big Picture Three Levels Top Level Middle Level Back End
Browser and Other Client Tools
Middle Level
Secure Web Server
Script execution engine
Servlets/Beans
Proxies for Grid Services
MyProxy Authentication
Derived from GSI
Uses Globus COG to talk to Grid.
Back End
Application components
Specified by XML
Communicate directly or by files
Client side
Vis Tools
Browser
Journal
Tool
HTTP/SOAP calls
Server side
Secure web server
Servlet Engine &
JPython Script Interpreter
MyProxy
Auth.
Job Mgmt
File Mgmt
Info & Event
Services
The Big Picture for the Portal: Three levels of running codes. Client: allows you to run applications (viz tools etc) or web browsers, and keep track of your activities in a journal. Server: here is where the Portal components run. All the events get routed through server. The Portal can find important components (via JAVA servlets/beans, C++) at the server level, and run scripts (PYTHON scripts or short code that tell the Portal how to run an application) that run in the web server. Also, the users grid credentials get established on a temporary basis on the web server (MyProxy). Globus COG (Commodity Grid) bridges between web server and Grid (job submission, file management, communication, security) Grid: We have access to diverse set of HPC platforms (SGI, Linux Cluster, NT Cluster, Condor) running codes encapsulated with a component proxy (gives the code an interface to make it interoperable with the components at the server level). Generic proxy is modified with XML metadata describing the application-specific input/output files (these are at the simplest level: ASCII or binary, input or output, required or optional, etc.) so that the proxy becomes specific to the application.
Example: User directs the browser to link a MC and FEM code at the application level
Security architecture now: user keeps their credentials to themselves, and delegate a temporary credential to a secure (MyProxy) server that runs at a high level of security. From the Portal, a user can grab temporary credentials and use them to do calculations. The full bore credentials are always kept with the user so that if any machines are compromised, the credentials will expire. Users can run secure Portal sessions from any machine. This handles authentication: knowing who every user is.
Next generation security: Full authorization from top to bottom (controlling access to codes and data). You want to know with a single knob who has access to what. Some codes are controlled by licensing. Some files are confidential information.
After that: Leaving no fingerprints: a still higher level that enables a user to set up work and then retrieve all results back behind firewalls and wipe the slate clean.
Globus Cog calls
Grid side
Application
Application
XML/SOAP
communication
Application
Alameda – EHAT Team Meeting – 02 November 2000

14. The Back End in Greater Detail
For Application Components
Each is described by an XML description
Descriptions stored in Information Service.
Used to generate a “proxy” which launches and listens for application events such as file reads/writes.
Component apps typically read and write files.
File types described by another XML schema which is used to generate intermediate communication adaptors which allow the output of one component to be used as the input to another.
Server-managed scripts can be used to manage computations involving large numbers of apps and files.
Alameda – EHAT Team Meeting – 02 November 2000

15. Alliance - IU App Portal Notebook
An extension of User Grid Portal
A Script Engine
Jpython based script pages
Scripts can access COG/GPDK to launch jobs, etc.
A Database of user experiments
Each session/experiment is saved as a directory containing
Scripts used and parameters
output pages
user annotations
Event log
Simple Grid Event model based on SOAP.
Standard
Browser
Specialized
client tool
http
request
reply
SOAP
RMI
Portal Server
Notebook
Database
Servlets
Authentication
Servlets
Grid Access
Servlets
Script Interpreter
Remote distributed resources
globus grids, legion
condor, entropia
Alameda – EHAT Team Meeting – 02 November 2000

16. Alameda – EHAT Team Meeting – 02 November 2000
Portal Notebook
Notebook is a hierarchical directory of
ordinary web pages
pages with input forms (java script)
execution scripts (driven by forms pages.)
Users of a notebook create “sessions”: an application execution/experiment.
Including parameter settings and results and event log
A session can be revisited, modified and run as a new session.
Start running session. Leave and come back later.
portal server
Notebook
servlets
Portal
services
Electo-chem
Configure &
launch scripts
User Sessions
User 1
experiment
User 2
Parameters
(xml)
Output
files
Event
logs
Alameda – EHAT Team Meeting – 02 November 2000

17. Application Scripting
execution
Proxy
Script
1. stage
1. Configure
2. Launch
3. Monitor
4. signal
Portal Server
application
configuration &
launch proxy
scrpts
Events
Application 2
Some Apps require linking together several sub-apps.
Chem-Eng: monte carlo + Finite Diff codes
Requires two levels of scripts
configuration and launch scripts running in server
application proxy scripts
monitor sub-app
send events
stage files
event handler scripts
Alameda – EHAT Team Meeting – 02 November 2000

18. I could end in the last one minutes by describing how this project
represents but one example of many that are likely to emerge out of
chemical engineering. I will comment briefly on the need for similar tools
in order to address processing issues in biotechnology and nanotechnology,
the re-inventing of the chemical process industry from an environmental
quality point of view, and the implications associated with run out of
petroleum as the limitless feed stock.