Language Hierarchy Grid Services Flow Language Patrick Wagstrom 1,2, Sriram Krishnan 1,3, Gregor von Laszewski 1 1 Mathematics and Computer Science Division, Argonne National Laboratory, 2 Department of Computer Science, Illinois Institute of Technology, 3 Computer Science Department, Indiana University Service Providers The serviceProvider elements provide a list of services that are components of the workflow. Each element has a name that is used to identify the provider within the document; a type that is the type of the service as specified in the WSDL for the service; and a locator that provides information needed to locate the service. The locator can be one of three types: static for services that are assumed to be running all the time, in which case the handle is a GSH directly to the service; a handle to the factory where the service can be created; or a handle to a registry where the actual GSH of the service may be found. Introduction The Web services approach is rapidly gaining momentum in industry, as well as in academia. It has been recently embraced by the Grid community, resulting in the development of the Open Grid Services Architecture (OGSA). To realize the full potential of this approach, there needs to be a mechanism to dynamically compose new services out of existing ones, and to describe the interactions between various services in the form of a workflow specification. The Grid Services Flow Language (GSFL) addresses these issues in the context of the Grid. GSFL is inspired by various Web service technologies like WSFL, XLANG and WSCL. Like the aforementioned technologies, GSFL is an XML based language for the specification of workflow, but GSFL is the only workflow language designed for and directly applicable to Grid services within the OGSA framework. The major components of GSFL are: Activity Model The activityModel is used to map names activities within the GSFL document to serivces, ports, and operations. Each element has a name that is used to reference the activity in the rest of the document and a source that contains a service, port, and operation where the activity can be found. Sample GSFL Document Composition Model The compositionModel describes how individual Grid services combine to form a single, new, Grid Service. It is able to model both the data and control flow between activities in the composite service and also describes the direct communication between activities in a peer-to-peer fashion. Within the compositionModel are an exportModel and notificationModel. Export Model The exportModel describes the activities that are exported from the composite workflow process. Each exported activity, in turn, triggers a set of individual services within the workflow. Each exportedActivity has both a controlModel to describe the flow of control between activities of the workflow and a dataModel that defines the flow of data between individual activities. Implementation Details The current implementation of GSFL is built on top of the OGSI technology preview, which in turn implements the Grid Service Specification by utilizing portions of Apache Axis, Apache Jakarta Tomcat, Microsoft.NET, IBM WSDL4J and the SciDAC Java CoG Kit. The major components are the utilization of GSFL for data binding, automatic WSDL generation for workflows and a generic GSFL coordinator service for back-end processing. GSFL DEFINITION Name, Target Namespace, Scope IMPORTS List of Imports : Namespace, Location SERVICE PROVIDERS ACTIVITY MODEL List of Providers : Name, Type, Locator List of Activities : Name, Source COMPOSITION MODEL NOTIFICATION MODEL Notification Links Exported Activities Activity Info CONTROL MODELDATA MODEL Control In Control Links Data In, Data Out Data Links EXPORT MODEL LIFECYCLE MODEL Service Lifecycle Precedence Links Activity Lifecycle Precedence Links Notification Model The notificationModel is used to describe direct, peer-to-peer communication between services. A notificationLink is used to connect the notificationSource of a particular service to the notificationSink of another, for a particular topic. The services can, thus, communicate large amounts of data between each other, without having the need to go through the central workflow engine, thus reducing the burden on the engine. Lifecycle Model Because not all services may be running at the same time, a lifecycleModel is used to model both the serviceLifecycle and the activityLifecycle. The serviceLifecycle models services a directed acyclic graph utilizing precendenceLinks to show the interdependencies. In this method, a child need not be started until the parent is almost finished. The activityLifecycle provides for ordering of exported activities via precendenceLinks and provides additional semantics similar to those in WSCL. GSFL Parsing and Data Binding Data binding in GSFL is quick and painless thanks to the use of Castor to auto-generate Java source from the XML schema. Each element in the schema has a bean and where appropriate additional classes were written. WSDL Auto Generation When a proper GSFL document is created, the workflow coordinator can create a WSDL document on the fly as all the necessary information is either in the GSFL document, or component WSDL documents. This capability makes it possible to expose every workflow instance as a Grid service, and hence their recursive composition. GSFL Coordinator Each workflow in an OGSI environment is an instance of the generic GSFLCoordinator. A specialized GSFLProvider is implemented as an extension of the standard RPCURIProvider to intercept all calls to the GSFLCoordinator and dispatch them to the generic Marshaller operation. The Marshaller then utilizes the information in the GSFL document and routes the service call to the appropriate member service. Contributions. Thus, GSFL provides an XML-based mechanism to specify workflow for Grid services. Its primary contributions are that it allows: Recursive composition of Grid services Effective peer-to-peer communication between the services Description of complicated lifecycle of Grid services Acknowledgements This work was performed under the auspices of the U.S. Department of Energy, Office of Advanced Scientific Computing, SciDAC program, under contract no. FWP # Client Servlet Hosting Environment OGSA/Axis WebApp GSFL Provider/Intercepter GSFL Coordinator Target Service Target Service Target Service Target Service Target Service Target Service Client sends request for dynamically exported method Hosting environment receives request WebApp determines processing service by URL GSFL Provider maps call to generic coordinator function GSFL coordinator issues request to target service(s) Target service(s) perform(s) action Exported Port Service A Service B Notification Source Notification Sink Control Link Notification Link Data Link P R Q This diagram shows how the various links are connected in a GSFL flow document. Service Providers: The list of services that participate in the workflow Activity Model: The list of important activities in the workflow Composition Model: The description of the interactions between the services Lifecycle Model: The lifecycle for various activities and services that are part of the workflow. Reference GSFL: A Workflow Framework for Grid Services. Sriram Krishnan, Patrick Wagstrom, and Gregor von Laszewski. Argonne National Laboratory, Preprint ANL/MCS-P , Aug 2002.