Upload
byron-harper
View
32
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Application Web Service Toolkit Allow users to quickly add new applications. GGF5 Edinburgh Geoffrey Fox, Marlon Pierce, Ozgur Balsoy Indiana University July 23 2002. Application Portal Architecture. - PowerPoint PPT Presentation
Citation preview
Application Web Service ToolkitAllow users to quickly add new applications
GGF5 EdinburghGeoffrey Fox, Marlon Pierce, Ozgur Balsoy
Indiana UniversityJuly 23 2002
Application Portal Architecture• Systems like Unicore, GPDK, Gridport (HotPage),
Gateway (WebFlow), Mississippi Portal, Legion provide “Grid or GCE Shell” interfaces to users (user portals)– Run a job; find its status; manipulate files– Basic UNIX Shell-like capabilities
• Application Portals (Problem Solving Environments) are often built on top of “Shell Portals” but this can be quite time confusing– Application Portal = Shell Portal Web Service +
Application (factory) Web service
Model for Application Web services
Appl1 “UserPortal”
Computer1Web ServiceAppl2
Appl3
Appl1Service1
Appl1Service2
e.g. viz
PSE
“abstract”or factory
Computer2Web Service
ApplInstance1
ApplInstance1Service1
ApplInstance1Service2
Computer3Web Service
These ApplicationWeb services are“just” metadata
Application Lifecycles
• Abstract State: describes potential uses of the application.– Analogous to a.out on a file system
• Ready State: a specific application instance has been set up but not run
• Submitted State: Application instance is running– Analogy: sh a.out
• Archived State: The job is completed and metadata about the instance is stored.– Metadata can be queried later as a service– Archived instances can be used to create new instances.
• We need ways of describing all of these states.
Application Web Service Bundles• An application is composed of
several shell services.– Application description, batch script
generation, job submission, job monitoring, file transfer.
• These should be deployable on a specific compute resource.
• These become services on a host resource.
• The application should have two parts:– Describe how to invoke– Describe ‘workflow’ of how the core
services interact
• Multidisciplinary applications are composed from multiple core applications
Application Web ServiceInterface
Job Submit
ApplicationDescription
File Transfer
Batch ScriptGeneration
“GCE shell”
Application Web Service Schemas• From the proceeding, we have two sets of schema:
– First set defines the abstract state of the application• What are my options for invoking disloc?• Dub these to be “abstract descriptors”
– Second set defines a specific instance of the application• I want to use disloc with input1.dat on solar.uits.indiana.edu.• Dub these to be “instance descriptors”.
• Each descriptor group consists of– Application descriptor schema– Host (resource) descriptor schema– Execution environment (queue or shell) descriptor schema
• There is a third Schema to define user definable options (standard input as a GUI) for application
Application Schema Elements
• The host and environment descriptors are the usual stuff, so we won’t go over that here.
• Abstract descriptors describe possible invocations of the application.– Edited by application deployers, used to generate
user interfaces
• Instance descriptors describe particular invocations of the application.– Created from user interaction with portal interface,
stored as application archive
Abstract Application Schema• 1. BaseInfoType: collects things like application
name, version, option flag info, etc. • 2. InternalCommType: How the application does
internal communication: input, output, error fields are here.
• 3. ExecBundleType: a bundle of services the application needs to actually execute (batch script generation, job submission, but NOT file transfer).
• 4. ExternalCommType: How the application communicates with its environment. This is not implemented but is put as a placeholder
• Communication and Execution bundle refer to host descriptions
Automatic Interface Generations with Schema Wizards
• Gateway schema pages are currently one shot development efforts.– We map HTML forms to a specific schema.– Form actions update schema instances through
Castor generated classes.
• More generally, we want to be able to automatically map general purpose schema elements to GUI widgets (HTML or otherwise).– We call this sort of thing a schema wizard.
XMLSchema
SchemaProcessor
Castor SourceGenerator
Castor SOM
JavabeansJavabeans
Javabeans
VelocityTemplatesVelocity
TemplatesVelocity
Templates
VelocityTemplatesVelocity
TemplatesJSPand
HTMLforms
Schema Wizard Architecture
Schema Wizard Explanation• A schema is read in to create an in-memory
representation (SOM) and also to create Java files.– SOM=Castor’s Schema Object Model
• Each schema element is mapped to a self-contained JSP nugget.
• JSP nuggets are generated from templates.– One template for each element type (simple, complex,
enumerated, unbounded,….).– Velocity is used for convenient scripting of JSP.
• The final JSP page is an aggregate of the JSP nuggets files (using <%@:include>).
• Complex schema elements are mapped to JavaBeans generated from the schema with Castor.– Scripting templates set up the imports
Where Are We Really?• Many GCE shell Web service implementations
developed.• Application schema are available and have been
implemented in a demo portal.• Schema wizard is still in development.• Maybe need AntiSchema wizard: given an HTML
form, creates a Schema– Captures input parameters of application
• Lots of work on remote portlets for Jetspeed– Navigable, session maintaining, form parameter passing
portlets developed.– Still need to work out security.– Still need to incorporate schema wizard as a portlet.
References• See
http://grids.ucs.indiana.edu:9000/slide/ptliu/research/gateway/AWS/AWS.doc for a short report and lots of XML Spy generated schema documentation.– Draft of “How to build an Application Web
Service” for the Application scientist
• See http://grids.ucs.indiana.edu:8045/GCWS/Schema/index.html for the schemas.