Application Web Service Toolkit Allow users to quickly add new applications GGF5 Edinburgh Geoffrey Fox, Marlon Pierce, Ozgur Balsoy Indiana University July

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 “User Portal” Computer1 Web Service Appl2 Appl3 Appl1 Service1 Appl1 Service2 e.g. viz PSE “abstract” or factory Computer2 Web Service ApplInstance1 ApplInstance1 Service1 ApplInstance1 Service2 Computer3 Web Service These Application Web 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 Service Interface Job Submit Application Description File Transfer Batch Script Generation “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

Application Schema I

Application Schema II

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.

Schema wizard generates JSP that delivers the form That enables one to create instance of Schema

XML Schema Processor Castor SourceGenerator Castor SOM Javabeans Velocity Templates Velocity Templates Velocity Templates Velocity Templates Velocity Templates JSP and HTML forms 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 ). 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 search/gateway/AWS/AWS.doc for a short report and lots of XML Spy generated schema documentation. search/gateway/AWS/AWS.doc –Draft of “How to build an Application Web Service” for the Application scientist See dex.html for the schemas. dex.html