Building Science Gateways
Concept #1: Web Portal
Web container that
aggregates content
from multiple sources
into a single display.
o “Start Pages”
Typically consume
RSS/Atom news feeds.
More powerful
versions these days
support Flickr,
calendars, games, etc.
o Gadgets, widgets
Examples: iGoogle,
Gadget
Concept #2: Grid Computing
Grid computing software is designed to integrate
large supercomputing facilities.
TeraGrid, Open Science Grid, EGEE, etc.
This is done via network services
Key Service Components
Authentication and authorization framework (MyProxy)
Remote process access and control (GRAM, Condor)
Remote file, I/O access (GridFTP, SRB, RFT)
Additional Services
Information services, replica management, database federation, storage management, schedulers, etc.
Science Portals and Gateways
Science Gateways adapt Web portal
technology to build user interfaces to the
Grid.
Science portals resemble standard portals, but
must also
o Support access to computing and storage resources.
o Allow users remote, Unix-like access to these resources.
o Provide access to science applications and data sets.
Example Science Gateways
Many listed here:
o http://www.teragrid.org/programs/sci_gateways/
Co
ver many different scientific fields:
o Atmospheric science, geophysics, computational chemistry, bioinformatics, etc
See also GCE07 and earlier proceedings
o http:
//www.collab-ogce.org/gce07/index.php/Main_Page
Portlets + Client Stubs DB Service JDBC DB Job Sub/Mon And File Services Operating and Queuing Systems WSDL Browser Interface WSD L WSDL WSD L WSD L WSDL Visualizatio n Service DB WSDL
Host 1 Host 2 Host 3
Terminology
Portlet
: this is a standard Java component that
generates HTML and can also act as a client to
a remote service.
o Lives in a portal container.
o I will also use this term generically.
Web Service
: a remotely invokeable function
on the Internet.
o SOAP: the XML message envelop for carrying commands over HTTP.
o WSDL: describes the service’s API in XML.
o REST: A variation of this approach.
Lots more info:
But Why?
Three-tiered Service Oriented Architecture is the network equivalent of the the famous Model-View-Controller design pattern.
o View: the user interface components.
o Controller: Web service middleware
o Model: the backend resources.
Independence of tiers gives flexibility
o Services can be reused with alternative user interfaces
§ Workflow composers like Taverna, Xbaya, Kepler
o User interfaces can work with different service implementations.
Two Approaches to the Middle Tier
Grid Service Grid Service Backend Resource Web Service Portal Comp. Portal Comp. Grid Client Backend Resource
Fat Client Thin Client
Grid Protocol
(SOAP) Grid Client
HTTP + SOAP
Disloc output converted to KML and
GeoFEST Finite
What’s In the Screenshots?
GeoFEST and Disloc Portlets
o Live on gf7.ucs.indiana.eduo Manage the user’s display: Web forms, links to output, graphics.
o Save user session state persistently.
QuakeTables Fault DB Web Service
o Lives on gf2.ucs.indiana.eduo Contains geometric fault models.
GeoFEST and Disloc Execution Web Services
o Lives on gf19.ucs.indiana.eduo Generates input files from fault models.
Best Practice for Scientific Web Services
There
are many tools to choose from.
o .NET, Apache Axis, Sun WS, Ruby on Rails, etc.
Make them self-contained.
o If possible, generate input files within the service.
o Or have an input file generating service.
o Remember that they may be used by other people with other client tools.
Communicate data files with URLs.
Be very careful about exposing the state of the
service.
Components for Portals
Components for Science Portals
OGCE is founded on the principal that portals
should be built out of reusable parts.
Key standard in our first phase: the JSR 168 portlet
specification.
Portlets can run in multiple containers
o uPortal, Sakai, GridSphere, LifeRay, etc.
Allows us to build Grid specific components and
deploy along side other goodies: Sakai
collaboration tools, contributed portlets, etc.
OGCE GPIR portlet can interoperate
with TeraGrid and your own GPIR
Manage TeraGrid MyProxy
credentials with the OGCE
OGCE file management client
portlets interact with TeraGrid
Dashboard Portlet
23
OGCE IFrame Portlet can be
used to integrate external
Two Major Grid Client Efforts
The Java COG Kit
o Supports several versions of Globus and SSH.
Condor-G
o Has a Web Service interface (BirdBath) and Java client libraries.
o Supports Globus (v2 and v4) and several other Grid middleware systems.
You can build either portlets or Web services with either of these.
OGCE portlets use primarily COG
CoG Abstraction Layer
CoG CoG CoG CoG CoG
CoG Data and Task Management Layer CoG Gridfaces Layer
CoG CoG
CoG
G
ridI
DE
GT2 GT3(X) WS-RFGT4 Condor Unicore
Applications
SSH Others
Nano
materials Informatics
Bio-Disaster Managemen
t Portals
CoG Abstraction Layer
CoG CoG CoG CoG CoG
CoG Data and Task Management Layer CoG Gridfaces Layer
CoG CoG CoG G ridI DE Development Support
Task Task Handler Service Task Specificatio n Security Context Service Contact
The class diagram is the
same for all grid tasks (running jobs, modifying files,
moving data).
Coupling CoG Tasks
The COG abstractions
also simplify creating
coupled tasks.
Tasks can be
assembled into task
graphs with
dependencies.
o “Do Task B after successful Task A”
Grid Client Development Problems
Grid portlets typically wrap each single Grid
capability in a separate portlet
Problem is that Grid portlets need to combine
these operations
o Portlets are entire web applications, so we need a component model for portlets: reusable portlet parts
Even with the COG Abstraction Layer, we must
still do a lot of coding to build new applications.
To address these problems we have adopted Java
Server Faces
o Provides several nice Model-View-Controller features
o JSF provides an extensible framework (tag libraries) for making reusable components.
o Apache JSF portlet bridge allows you to convert standalone JSF
GTLAB JSF Example
<html> <body>
<f:form> ….
Grid Tags Associated Grid Beans Features
<submit/> ComponentBuilderBean Creating components, job handlers, submitting jobs
<handler/> MonitorBean Handling monitoring page actions
<multitask/> MultitaskBean Constructing simple workflow
<dependency/> MultitaskBean Defining dependencies among sub jobs
<myproxy/> MyproxyBean Retrieving myproxy credential
<fileoperation/> FileOprationBean Providing Gridftp operations
<jobsubmission/> JobSubmitBean Providing GRAM job submissions
<filetransfer/> FileTransferBean Providing Gridftp file transfer
ResourceBean Describes common properties
Scientific Workflows
Portal interfaces encode scientific use cases.
If you have a rich set of services, it is a lot of
work to make portlets for all possible use cases.
§
And power users will have always want
something more.
Example: our CICC project has dozens of
chemical informatics Web services.
http://www.chembiogrid.org.wiki
Workf
low composers can simplify this.
Web Services and Workflows
Perform a similarity search on the NIH DTP Human Tumor data.
Filter the results based on Pharmacokinetic
properties (FILTER)
Convert to 3D (OMEGA)
Docking into a
pre-defined protein (FRED)
Visualize (JMOL).
OGCE’s XBaya
Future of Science
Gateways
Social Gadgets+AJAX DB Service JDBC DB Job Sub/Mon And File Services Operating and Queuing Systems REST Browser Interface REST WSDL REST REST REST Visualizatio n Service DB REST
Host 1 Host 2 Host 3
Updating the Octopus
RSS,JSON/HTTP
HTTP(S)
Enterprise Approach Web 2.0 Approach
JSR 168 Portlets Gadgets, Widgets Server-side integration and
processing AJAX, client-side integration andprocessing, JavaScript
SOAP RSS, Atom, JSON
WSDL REST (GET, PUT, DELETE, POST) Portlet Containers Open Social Containers (Orkut,
LinkedIn, Shindig); Facebook; StartPages
User Centric Gateways Social Networking Portals Workflow managers (Taverna,
Kepler, etc) Mash-ups
Grid computing: Globus, condor, etc Cloud computing: Amazon WS Suite, Xen Virtualization
Semantic Web: RDF, OWL,
Microformats,
KML, and GeoRSS feeds used to
