Application Web Service Toolkit Allow users to quickly add new applications

1. Application Web Service ToolkitAllow users to quickly add new applications GGF5 Edinburgh Geoffrey Fox, Marlon Pierce, Ozgur Balsoy Indiana University July 23 2002

2. 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

3. Model for Application Web services PSE Computer1Web Service Appl2 “abstract”or factory These ApplicationWeb services are“just” metadata e.g. viz ApplInstance1Service1 Appl1Service1 Computer2Web Service Appl1 “UserPortal” ApplInstance1 Appl1Service2 ApplInstance1Service2 Computer3Web Service Appl3

4. 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.

5. 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 “GCE shell” Job Submit Batch Script Generation File Transfer Application Description

6. 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

7. 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

8. 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

9. Application Schema I

10. Application Schema II

12. 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.

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

14. Velocity Templates Velocity Templates Velocity Templates Velocity Templates Velocity Templates JSP and HTML forms Castor SOM Schema Processor XML Schema Castor SourceGenerator Javabeans Javabeans Javabeans Schema Wizard Architecture

15. 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

16. 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.

17. 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.