Workflow Infrastructure for Multi-scale Science Gateways

Transcription

1 Workflow Infrastructure for Multi-scale Science Gateways 1 INTRODUCTION As the concept of Grid Computing matures, science collaborations are emerging to share research code, data and distributed computing resources. These collaborations are multi-disciplinary in nature and are building gateways to empower seamless access to nation s high-end integrated infrastructures like TeraGrid [13]. The starting point for many scientific collaborations is sharing research systems designed as computer based tools, and a major subset of these tools and simulation models are shell-command executable applications. As the computational requirements of these applications become demanding, infrastructural issues like security, remote data and compute task management incur significant time of scientists deterring them from their core science research. Typically, an end-to-end scientific simulation involves preprocessing, analysis and post processing. Since most of the science problems are inter-connected, scientists need to share applications, combine multiple application logics in flexible but planned order, and orchestrate them as workflows. These inter and intra discipline collaborative research is vital for the advancement of science. However, sharing command line applications is not a trivial process due to many technical and practical difficulties. Most legacy science applications are not easy to install, maintain and they undergo changes constantly. Some of these applications have dependencies on specialized softwares, non-conventional versions of operating systems, and some even depend on expensive hardware like a particle accelerator or a earthquake simulator. Furthermore, application authors may not be ready to share the application source as it is, but rather are willing to share executions within a trusted community and in a controlled manner. Web services [16] provide standardized interfaces, defined, described, and discovered as xml artifacts, and they facilitate secured and controlled interactions with other web services and software components, by using well known message formats. Nevertheless, redesigning all scientific applications as web services, is neither suggested nor a practical solution. Hence, the concept of wrapping applications as web services is emerging. These wrapped application services abstract functional logic and these application services could also be composed together as scientific workflows, enabling the scientists to construct, orchestrate, monitor, and share application executions. In this paper we present the architecture and usage of a workflow suite, which facilitates users to wrap command line applications as secured services and construct, share, execute and monitor workflows. The workflow suite comprises of Generic Service Toolkit (GST) [27], XRegistry and XBaya Workflow Graphical User Interface [42]. These software components are developed and widely used by a NSF funded large Information Technology Research project, Linked Environments for Atmospheric Discovery (LEAD) [20]. LEAD is building an integrated, scalable Cyberinfrastructure in which meteorological analysis tools, forecast models, and data repositories can operate as dynamically adaptive, on-demand, Grid-enabled systems. Real-time dynamically adaptive weather forecasting provides a major subset of gateway requirements and have been the driving motivation for developing the workflow infrastructure. But these tools have been well architected to cater to wider scientific domains addressing the generalized computational and data management issues. Owing to the wide range of requirements from domain centric gateways, building a general purpose science-gateway workflow infrastructure will need extensible and modular software components. These extensible tools are packaged, tested and supported through Open Grid Computing Environments (OGCE) [5] project, and can be used by small, medium or large scale science gateways as a integrated workflow infrastructure or can incorporate individual components into existing gateway infrastructures. The section 2 of this paper discusses high-level architecture of the workflow suite and briefly presents each individual component with references for further reading. In the section 3, we discuss the security model and various security usage patterns. To illustrate the domain independence and multi-scale gateway adaption, In the section 4 we present chemical informatics, atmospheric science, and genome analysis use cases. These gateways have successfully used the LEAD workflow infrastructure from a single user mode to a high end complex gateway serving hundreds of users. In following sections 5 and 6, we discuss related work, conclusion and future directions. 2 ARCHITECTURE The LEAD workflow suite addresses the gateway requirements of generating web service interfaces to shell command applications and use them to construct data flow and/or control flow graphs as workflows. To address the initial requirement of wrapping existing legacy applications we discuss the Generic Service Toolkit (GST) which not only provides web service interfaces to command line applications but also aids in creating on-demand web services. To catalog the generated application service descriptions, information about hosting environments and constructed workflows we discuss XRegistry service which is geared with sophisticated user and group support, which acts as a basis for sharing and publishing services among users. And finally we discuss a Workflow Graphical User Interface XBaya, which allows users to construct task graphs as workflows. As shown in Figure 1, we present a high-level architecture of the workflow system and interactions between the service toolkit components, registry service, and workflow GUI to be used as an integrated framework. Further in this section we discuss design details of individual components. To avoid confusion with deployment and usage of the multilayered architecture, the terminology used in further sections is listed below: Compute Hosts - the computing environment where the application will be executed, based on application needs, these can be from a simple workstation to a giant super computer. Application Services - Web Service wrappers to command line science applications Service Hosts - the servers used to run light weight application services, service factory and registry service. For small or a medium gateway the service hosts and compute hosts can be the same. Scientific Workflows - tasks graphs orchestrating executing of a combination of application services. Application Provider - Application owner managing the sharing and executions of applications.

2 Workflow Provider -Workflow user constructing application graphs and sharing them. End user - Workflow system end user who is interested on the outcome of the workflow. Based on user knowledge level, an end user can be a workflow or application provider as well. Science Gateways have the need to provide access to a large number of science applications but only a sub set of them will be used at any give time. Deploying all application services and idling them most of the time will need a large pool of gateway resources with additional tasks of managing long running services. To address this issue, we use the concept of on-demand service creation [1, 14, 28] features of the GST, application providers register the input and outputs and deployment locations of the applications but not necessarily deploys and maintains a persistent web service. The workflow infrastructure uses Generic Factory Service (GFac), a component of the service toolkit, and creates web services at workflow execution time. Even though they are created on demand by a workflow user, they are reused amongst different users ensuring security and are kept alive for a short duration in anticipation of subsequent requests. These services automatically shut down after a pre-configured time of in-activity. Thus, the resource requirements to host and support multiple applications are minimal and a large number of applications can be registered to the science gateway. The deployment and usage of the workflow infrastructure can be broadly divided into three categories: 1. Gateway Setup and Deploying persistent services - a one time installation step. 2. Register Applications and construct and share workflows - iterated until all applications are registered and necessary workflows are constructed. 3. End users executing and monitoring workflows. We discuss these three steps in detail in reference to the sequences specified in Figure 1. The initial workflow system deployment would include setting up the factory service and and a registry service. If monitoring of workflows is desired the optional web-service messaging framework [24] will be needed. Registering applications to the workflow system involves defining three deployment descriptors that define how a command line application should map to a service. These deployment and service descriptions are stored in the registry. As represented by arrow A1, application provider builds and tests the application on remote compute resources. As shown in steps A2 and A3, the deployment locations and service inputs and outputs are registered with registry service using a web form. The XRegistry service can be interfaced as a web-service and additionally a java API and command line shell scripts are provided. This facilitates gateways to programmatically generate and register application service descriptions. Typically, these steps A1 to A3 are only performed once and repeated as the application source changes. Workflow providers construct workflows as shown in steps B1 to B3. In Step B1 the XBaya workflow GUI [42] is loaded as a Java web start application and user is authenticated and authorized. As shown in steps B2, the XBaya GUI connects to a service registry and fetches the application services descriptions which are permissible by the user. User can browse the services registered in steps A to A3 or directly load an external service by its URL or can load existing workflows to construct hierarchal graphs. XBaya GUI presents an Intuitive information about the service and its inputs and outputs. User may compose task graphs or workflows by connecting multiple services together. The composer will validate input and output type compatibility, however the knowledge of application dependencies is assumed with the user. Furthermore, users may use the composer to access preconstructed workflows and execute them. User inputs are captured and the workflow is passed to an enactment engine for orchestrated execution. For smaller gateway deployment, XBaya has an embedded workflow engine implemented in Jython [3] or XBaya can serve as a client to standard workflow implementations like BPEL [10]. Arrows C1-C8 in Figure 1 illustrates the steps involved in execution of a workflow. Once the workflow is invoked, the Jython workflow enactment will search XResgitry for any application service instances (C2) and if found it would invoke the application services with user specified data and configuration parameters. If no such service instance is found, XBaya will contact service factory and requests to create a service instance (C3), and on creation the service instance will register itself with XRegistry that will be used by current workflow execution or can be used by subsequent invocations with-in the life time of the created application service. Once invoked (C4), an application service will stage any input files (C5) and submit the job to an application host (C6) using the remote file transfer and job submission protocols specified in the deployment descriptors. For large-scale gateways, Grid based remote file transfer (GridFTP) and job management (GRAM) can be used. For simpler deployments, SSH based remote transactions can be supported. However, due to security and better monitoring features grid based deployment is suggested. As the workflow is executing, the application service sends activity notifications to the event bus (C7) and XBaya GUI will be listening to it and would update the workflow progress which will be shown graphically by change of colors and displaying notification messages (C8). It is important to note that, even though we present the system as a workflow suite performing service wrapping, registration, workflow composition, execution and monitoring, it is possible to use these components individually and integrate into different compatible frameworks. The service toolkit s has an in built web interface which can be used to not only to register and share services but also to create and invoke service instances. The toolkit can also automatically generate a web interface based on service descriptions for users to input data, invoke service, and view results using a portlet-based interface. These generated web services can be used in any workflow infrastructure supporting web services composition and execution; early experiments have been made with Kepler and Taverna workflow systems [37]. The following sub-sections describe more details about individual components of the workflow infrastructure. 2.1 SERVICE TOOLKIT The goal of an application service is to wrap a command line application to provide a Web Service front end to a command line application, while handling details of file staging, Job submission, and security concerns. Furthermore, the service acts as the extensible runtime around which extensions like sharing, auditing, resource brokering and urgent computing are implemented. The service toolkit includes a generic factory service for on demand creation of applications services, and a service runtime that provides logic for application services. A user defines his applications, deployment information and mapping to the service, as a three deployment descriptors, application, host, and service description documents. The host description documents describe the environment to run a transient service, including java and toolkit installation locations, compute host descriptions defining the remote access mechanisms for file transfers and job submissions. On the other hand, the application deployments descriptions define application install location and execution information about the application itself, and finally service description documents define input, output and other application configuration information. When a user requests a new application service, the factory service

3 (A1) Compute Nodes Application Developers (A2) Service Toolkit Web UI (A3) (C6) Gram/SSH/Local Applcations Workflow Provider (B1, B3) (C1) (B2,C2) Xbaya (C3) (C8) XRegistry Service Factory (C4) Application Services (C5) (C7) Data GridFtp/SFtp/http End Users Notification Bus Figure 1: Lead Workflow System Architecture chooses a host from registered service hosts, and starts a new application service on that host. If multiple service hosts are registered, the factory service will provide load balancing in round robin fashion. The newly created service fetches deployment descriptors from the registry and configures itself according to the contract defined by service, and applications descriptions. After successful initialization, the service registers its WSDL in the Registry service so it can be used by other workflow executions, and the service self -shutdown, after a given period of inactivity. When an application service is invoked, the service parses the request, identifies the parameters that should be passed in to the underline application, As mentioned before, a typical application service invocation involves two hosts, the service host where the service instance is running, and the application host, where application is executed. Services and applications have a one to many mapping, where multiple applications correspond to different installations of the same application. After deciding the best application host to execute the application, the input data files specified by input parameters are staged to application host and the underline application is executed using a job submission mechanism (e.g. GRAM). The service monitors the status of remote application and publishes frequent activity information to the event bus. Once the invocation is complete, the application service tries to determine the results of invocations by searching the standard output of the application for standard or user-defined patterns or by listed a pre-specified location for generated data products. Apart from wrapping the command line application as a service, the application service provide number of add on facilities that are essential for a scientific workflow environment. The application service runtime is implemented using a processing pipeline based on the Chain of Responsibility pattern [49], where the pipeline can be altered by inserting interceptors. Resulting architecture is highly flexible and extensible, and provides the ideal architectural basis for a system that has wide range of applications. For an example, for the LEAD cyberinfrastructure project, we have used the interceptor pipeline to handle scenarios like supporting FORTRAN namelist preprocessing, adding security and authorization support, and integration with LEAD data sub- system. Furthermore, the design has abstracted out commons services like file transfer, registry support, notification support, and job submission, allowing different implementations to be switched dynamically or via configurations. Apart from the core application wrapping and on-demand service creation functionally, the following is a list of few additional features: 1. An extensible request-processing pipeline that enables users to dynamically change request processing by introducing interceptors. A major application of these extensions is to implement domain specific functions. 2. To handle shared execution batch queues, the service toolkit is designed to deal with multiple application deployments and the scheduling can be a simple random selection or can use sophisticated algorithms utilizing bandwidth estimates and best effort batch queue wait time predictions made by Network Weather Service and QBETS [52]. 3. Application services also support load balancing, and fault tolerance while processing requests. Every host description document may provide a list multiple file transfer and job submission endpoints, and application services would use those endpoints in round robin fashion. Furthermore, in case of a failure the application service can retry to a different endpoint if one is available.

4 4. Service toolkit supports wide verity of file transfer mechanisms (e.g. GridFTP, SFTP, HTTP, shared file system based copying, and local file transfers). 5. Service toolkit supports wide verity of job submission services (e.g. GRAM [18], WS-GRAM [9], SSH, Local and Virtual Grid Execution System [6]). IU lead CS meteorologists educators Teachers OU Students 6. Selective resource sharing based on an authorization model provided by Xregistry. 7. Support for job submission based on urgent computing facilities [11]. 8. The toolkit Supports auditing of resource utilization providing basis for accounting, and billing [32]. 2.2 REGISTRY SERVICE The Xregistry acts as the information repository for the workflow suite, and users may store documents (e.g., Service toolkit deployment files, workflow files), search and retrieve them, and services may register themselves with the registry, enabling other users and services to search and access registered services. Registry service provides extensive user and group support exposed via a Web service interface that provides the basis to sharing and access control in the gateway environment. Every document of the system has an owner, who has complete access to the resource, and users of the system may belong to groups, where groups may recursively belong to other groups. Furthermore, the registry facilitates user to define capabilities that authorize other users to perform actions on their documents. We define recursive group based authorization model formally as a tuple of users, resources, groups, group memberships, capabilities and ownerships, XREG = (U, R, G, M, C, O)., and other entities are defined as following. U is the set of users of the system. G is the set of groups of the system. R is the set of resources in the system. M (U G) G defines group memberships in the system. C (U G) R {Read, W rite} defines set of capabilities. O U R defines the resource ownership Set. For a resource r R and user u U, we define following functions. We define the transitive reflective relationship, which represent group g 1 contains g 2 as following. When g x, g y G we say g x g y n N, g 1, g 2... g n G i = 1... n 1, (g i, g i+1) M (g x, g 1), (g n, g y) M We define the set G(u) G, as the all groups a user belongs. G(u) = {g G g 1 G, (u, g 1) M, g 1 g} We define authentication function, auth : U R {T rue, F alse} as follows. auth(u, r) = ( g G, g G(u) (g, r) C) ((u, r) C) ((u, r) O) Figure 2: Sample Group Hierarchy Finally we define R(U) R, all resources accessible to a user as follows. R(u) = {r R auth(u, r) = true} According to the formal model, we define the functionality of the system as following. 1. User u has access to resource r IFF auth(u,r) = true. 2. User u can edit entry for resource r in the authorization list A, IFF (u, r) O, and he share the resource by doing so. 3. When a user lists resources based on a criteria, the resource is listed IFF r R(u) and matches the criteria. 4. Only administrators are allowed to edit, G group list, and M membership list 5. Any user can add a resource, to resource set R. For an example, as shown in Figure 2, Groups and users create a graph where edges represent relationship. Every user in a child group is considered to include in the parent groups as well. For an example, every user in the students group is a member of the parent group lead as well. Student group users can access any resource assigned to Students, Educators or LEAD groups. However, users in LEAD group do not have access to resources assigned to Students group. To enforce authorization while handling documents, the registry needs to calculate, functions R(u), and auth(u,r) and to efficiently implement the authorization model, system calculates G(u) for each user and stores it in the user object. Using G(u), both above functions can be easily implemented. Xregistry is implemented using a Web service with a MySQL back-end and group hierarchy is cached in memory to achieve better performance. Furthermore, it provides a portlet based web interface to create, share, manage and search documents. 2.3 WORKFLOW COMPOSITION AND EXECUTION ENGINE The XBaya GUI provides an interface for users to browse registries, connect registered services as directed graph workflows, execute, and monitor progress. XBaya can be integrated into a portal framework and can be launched in composition or monitoring modes. Users can access publicly accessible web services or provide security credentials to fetch X509 credentials from a MyProxy Server [36] and authenticate with the XRegistry or a secured workflow engines. XBaya allows users to access browse multiple service registries and workflows can be composed with concrete web services (the service is up and running at the time of composition) or with abstract descriptions registered with XRegistry. User may compose a workflow by dragging and dropping a service in to a worksheet, and visually defining relationships among them. Services can be connected using data dependencies or additional control dependencies can be enforced. The GUI can be a loaded by clicking a JNLP [43] URL and the interface is started on users local

5 workstation. The only pre-requisite to run XBaya is Java web start, which is installed by default with all latest versions of Java. XBaya provides a high-level workflow description and workflow engine specific execution scripts can be generated and deployed. XBaya currently supports GPEL [45] and embedded Jython script execution. XBaya can be used to monitor workflow executions by subscribing to event bus and based on event notifications; the colors on service boxes are changed to visually present execution the status. The workflow event life cycle is defined in the lead metadata schema [39]. The services created using Generic Service Toolkit produce notifications about file transfers, job submissions, batch queue status, application execution, and data transfer times among other status messages. When the events contain compute host information, XBaya dynamically displays the compute host where the application of the service box is being scheduled and executed. During the workflow composition, it is important to make sure that the correct services are wired together in a meaningful manner. One obvious technique that can be used to improve the correctness during workflow composition stage is to use type systems. In the current implementation of XBaya, we makes use of the WSDL based type system to perform some correctness test, but this method lacks any semantic correctness checking thus could lead to compositions that may appear to be properly type matched but may be semantically incorrect. As part of future work is intended to provide semantic guidelines during workflow composition, using Ontology based descriptions. Apart from the jython based embedded workflow execution support, XBaya as a workflow composer supports separation of workflow composition from actual invocation, where a BPEL Engine would do the actual invocation of the workflow. There has been effort towards extending XBaya to interact with multiple workflow engines like Taverna [25], GPEL [45] and ODE [2] and this work could be considered as a prologue for workflow interoperability. 3 SECURITY MODEL Science Gateway s are intended to ease end users from the knowledge of accessing and moving data and from compute job management. These user-friendly features come at a cost of adding middleware layers abstracting end-users from data, compute resources and scientific applications. Hence having a well-planned security model is essential to gateway infrastructure. Moreover, since application providers share their research codes, a carefully monitored controlled access mechanism is a necessity. In this section, we briefly discuss the security model for the workflow suite enforced at multiple levels. Security of the workflow suite can be broken down to four major segments: securing the invocations between services, authentication users with X509 based grid credentials, ensuring secure exchange of these credentials for secured file transfers and job submissions, and finally the authorization model for controlled access of application and service descriptions. Since all web services are web accessible, it is important to secure these services and deny any requests made by anonymous clients. The XRegistry service, Generic Factory Service, and all transiently created application services enforce SSL only authentication, thus all services have https URL s and clients have to do mutual authentication before initiating any requests. The SSL certificates are issued by the deploying gateway and only services having the gateway issued host certificates are allowed to interact. Users must authenticate with their grid credentials to XBaya interface and these credentials are used to make secure connections to interface with XRegistry Service, Factory service and secured application services. As shown in Figure 1 of the figure, Application provider (Alice) creates a Service and shares it with other users (Step A2) by issuing a capability via Service Toolkit s Web Interface and the capability is registered with XRegistry Service. Workflow Provider Bob searches for all service instances (Step B1) and Xregistry will list Alice s service since Bob has been granted access. In step C1, Bob as an end-user, invokes the service instance (composed into a workflow or via service toolkit s web interface) using his security credentials for authentication. The invoked service contacts Xregistry and verifies Bob s permissions and the invocation will proceed to completion. Any other invocations initiated by a different user will be rejected. Based on the desired security model, the workflow infrastructure can be used in three modalities. In the fist model, a single user has control over application deployments, workflow infrastructure and the same user executes workflows with credentials used for application and infrastructure deployment. The second model is most suited for a medium to large gateways with manageable number of gateway users. In this usage scenario, all applications are deployed on multiple resources using shared gateway community account (managed by gateway administrators) and workflow infrastructure is deployed using gateway community account and is configured to support multiple gateway end users. In this model, the gateway user management can be done at a higher level (like web portal using PURSE [21]) and XRegistry can leverage the portal authentication system and manage mappings between gateways users. Finally, in the third model, a medium scale community with multiple application developers and all of them deploying applications to a common gateway account is not feasible, applications can be deployed to individual application developer accounts but each application provider should also deploy a service factory. When applications are registered with XRegistry, the location of the factory service can be embedded into the service description and possibly expose it in WSDL documents. Consequently, there are multiple factories, and a single registry can be used to catalog all the services. At workflow execution time, the XBaya GUI can contact the factory service specified in the WSDL document generated during the application registration process, and use that to create a new service. Allowing users to share factories can enforce more granular security, and the service the instances created can still have fine-grained access control. This model allows set of untrusting users to share their applications in controlled manner. Another important requirement of gateway infrastructure is the ability to audit end users usage of shared community compute allocations. To this end, the service toolkit has been instrumented and integrated with GRAM auditing service and details are mentioned in LEAD Auditing Paper [32] 4 EXAMPLE USAGE SCENARIOS In this section we discuss few usage scenarios of the XBaya Workflow GUI and Generic Service Toolkit individually in other workflow frame works and we also discuss how a large science gateway is using this integrated workflow framework for scientific research,educational and outreach activities. 4.1 LEAD WORKFLOW INFRASTRUCTURE FOR DATA MINING In this use case we present how the workflow suite has been used to wrap data mining applications, and construct mining workflows to use for study of storms. At a workshop conducted as part of AMS annual

6 Figure 3: Data Mining Workflow Figure 4: Drug discovery use case conference [1] meteorology users have run workflows constructed using data mining algorithms from Algorithm Development and Mining (ADAM) [40] toolkit to understand clustering of storms. ADAM toolkit provides classification, clustering, and association rule mining methods to mine scientific data. ADAM application providers from University of Alabama at Huntsville, have used Generic Service Toolkit and created wrapper services for the storm detection algorithm (SDA), the k-means partitioning based storm cluster algorithm (SCA) and a density based clustering algorithm (DBSCAN). Using these wrapped application services a data mining storm analysis workflow is composed as shown in the following figure and shared with users for execution and analysis of outputs. The SDA service reads from workflow inputs NEXRAD radar data [4] with a user specified reflectivity threshold and filters, and detects locations of storms. The following service reads in the detected storm locations and filters for attributes needed for clustering the location of storms. The final clustering service in the workflow clusters the detected storms into groups based on spatial orientation or area coverage. Few examples on how the composed data mining workflows can be used by scientists studying the behavior of storms: Users may be interested to execute these data mining workflows to launch weather forecasts on the regions where storms are detected. Secondly, these workflows can be used by data mining experts to understand the effectiveness of clustering algorithms, and a study by UAH scientists found that DBSCAN algorithm fares better than k-means. These workflows can be used for more comprehensive analysis as well. The data mining challenge is to automatically detect the number of clusters. Although subjective, some objective criteria or indices can be applied like the Hartigan statistical index and Silhouette index. For 14 out of 20 data sets (time periods), the two methods indicate the same number of clusters. Of the remaining six data sets, three data sets differ by one, one data set differs by two and one data set differs by three. Clustering results using the Hartigan index for storm events observed by NEXRAD radar over a 25-minute period and clustering results using the Silhouette index. In the right portion of both panels, the results are essentially identical. On the left, however, the storms are grouped into three clusters by the Hartigan index and 18 clusters by the Silhouette index. Based upon these experiments it is concluded that the optimal number of clusters determined using the Hartigan index and the Silhouette index are the same. However, clustering performance using the Silhouette index is more sensitive to storm event distributions. As a result the combination of DBSCAN algorithm with Hartigan index can be used to measure for automatic storm event clustering. On a typical scenario, performing this kind of analysis will require computing power and only the owner of algorithm can perform this study. But by use of workflow suite and wrapping this algorithms and composing workflows relieves the scientists from dealing with computations job management and data transfers and job scheduling issues. Multiple users can now use these workflows in a secured, controlled manner with the information needed to audit their usage. 4.2 DRUG DISCOVERY USE CASE The field of chemical informatics is highly multi-disciplinary having intersection with both biology and chemistry. Researchers in this field have to deal with tools and applications from multiple domains, that are developed by various environments. The paper [19] elaborates various research efforts in chemical informatics, and in nutshell, chemical informatics is developing a infrastructure to integrate different tools, methods, and personalize them to cater far individual problems. In this use case we discuss the usage of LEAD Workflow Infrastructure by a chemical informatics research group in Indiana University, who developed workflows for drug discovery in order to better understanding the effect of drugs in inhibiting tumors. As shown in the figure 4, the workflow composed in XBaya reads in protein information pdb ligands, smiles, and similarity co-efficient, and generates docking scores and a 3 dimensional display using JMol, a chemical informatics visualization tool. A conventional chemical informatics scientists searching for newly published compounds and studying the effects of drugs, need to understand the internals of the workflow. Using the workflow infrastructure one person can compose the workflow with their knowledge about how an initial ligand with good binding properties should be selected, and then extract similar compound from a database and run it against the protein to observe the docked effect. The composed workflow can be shared with other users, who need not understand the internal logic, and focus the main research problem of iterating through multiple ligands with changing tanimoto coefficients, and see the effects in 3D visualizations of proteins complexes and potential drugs. This model of constructing workflows and sharing the workflows in a secured controlled manner is a major science requirement of a research professor delegating the analysis task to graduate students who need not focus on the internals, but on the problem at hand. Similarly scientists collaborating together can make tremendous progress on the science problem which otherwise would have deterred towards computational issues and learning new systems both of which are irrelevant to their research goals. 4.3 GENOME WIDE DOMAIN ANALYSIS USING GENERIC SERVICE TOOLKIT Evolutionary and functional relationships among biological molecules are typically expressed as relationships among genes. Motifs/Domains can domain swap between genes. Motif Network is a collaborative effort between Renaissance Computing Institute, Center for Bio Physics and Computational Biology, and National Center for Supercomputing applications looking at comprehensive transformation of sequenced genomes into domain space. MotifNetwork is building a suite of biologically oriented and grid enabled workflows for high throughput domain analysis of protein sequences. MotifNetwork workflows are orchestrated using Taverna Workflow system and Generic Service Toolkit

7 Atmospheric Administration (NOAA) Hazardous Weather Test Bed (HWT) [51] Spring 2007 experiments [50]. 5 RELATED WORK Figure 5: LEAD Usecase is used to wrap computational applications to create grid-enabled services. More information of GST usage can be found in [47]. 4.4 A LARGE SCALE SCIENCE GATEWAY LEAD USE OF WORKFLOW INFRASTRUCTURE The LEAD project goals can be summarized into two broad categories: Firstly, democratizing the availability of advanced weather technologies for research and education by building a user-friendly and easy to use interface abstracting science applications, real-time data streaming, management, and computational technologies. Secondly, LEAD Cyber infrastructure has to be flexible enough to build a dynamically adaptive system with ability to detect, analyze and predict atmospheric phenomena. By lowering the entry barrier the rapid understanding experiment design and execution of complex science applications is made possible. To this extent the LEAD workflow infrastructure is applied to weather simulation codes, and forecasting workflows have been constructed and shared across 100s of users spanning from research scientists to under-graduate students. In this use case we discuss how a community of application developers can build, deploy, and manage, access to application services and workflows. The LEAD gateway developers have deployed the weather forecasting components on TeraGrid gateway account computing resources. These applications are written in FORTRAN and are widely used in atmospheric science community. The initial preprocessing and data assimilation is done using components from ARPS Data Assimilation System [54] and the forecasting is performed by Weather Research and Forecasting (WRF) [35] model. Once these applications are deployed on multiple TeraGrid clusters represented by Step A1 in Figure 1, service and application descriptions are registered with XRegistry Service represented by steps A2 and A3. Typically these components are orchestrated by a complex Perl script, which can only be understood and maintained by few experts. But using workflow infrastructure users who understand the data flow paths can compose workflows and share them with the community of users. As shown in the figure 5 the services are wired together as per their data dependencies, they will perform weather analysis using radar data. Advance users can substitute these services with their own versions of individual service implementations without having the need to understand the implementation details of other components in the workflow. LEAD has successfully used these workflow tools in various community engagement workshops with great appreciation from end-user communities [48]. Graduate and undergraduate students have used LEAD forecasting workflow results and participated in national collegiate forecasting competition [15]. Scientists have used LEAD workflows to improvise weather forecasting during National Oceanic and As discussed in the surveys by Yu, J et al [55] and Slominski et al [46], there have been many efforts to build workflow tools for e-science, and prominent among them are Kepler [31], Taverna [25], and Triana [14]. The fundamental requirement to any e-science workflow system is to enable workflow construction and execution tools and minimize the requirements about understanding the underlying applications and technologies. The requirements of the workflow systems range from the ability to run long running applications, orchestrate them in workflows, supporting launch now and visualize later interactions. The workflows should be easy to use and most importantly developed against standard specifications to facilitate the interoperability with other workflow systems. Most of the existing workflow systems provide support for Web Services; however, the workflow systems define their own proprietary descriptions like Kepler actor language, Sculf language [14], and industry standards like WS-BPEL. We try to address this problem by decoupling the workflow composition and execution, and the higher-level workflow composition can generate multiple enactment scripts like BPEL and Jython. Another significant difference LEAD workflow system offers is the ability to create services on-demand and thereby huge number of applications can be supported, and a service may scale to many requests as workflow tools can do late service binding by automatically creating services as needed and dynamically invoking them at execution time. Furthermore, the workflow system not-only support services created using toolkits outside the infrastructure but also the services created in this infrastructure can be used in other infrastructures. Apart from the Jython and GBPEL, we are working towards supporting Taverna and Apache ODE based workflow execution systems. Detailed comparison is available in [42]. In the context of exposing legacy scientific applications as web services, there are many service toolkits that provide varying features. Among them, SOAP lab [44], OPAL [30], VAP [33], and Matsunaga et al [34] provide mechanisms to configure application description in a text file and use it to create a wrapping Web service. These Web services are developed using a Web Service toolkit and then are deployed to a tomcat container. Remote job submissions may be done through Globus Job management system GRAM. Among other systems GridDeploy [22] and GEMLCA [26] toolkits provide Grid Service interface to an application executing on the same host. A factory receives a request, spans a new Grid service in the same environment, and forwarded the request. GAP [41] provides a Web service interface that enables application executions and when a user sends a request with details about the application, GAP invokes the application in the given host on behalf of the user. However, it is important to note that, GAP does not expose the application as a Web service, rather provide an interface to the shell, therefore not intuitive with the workflows. Pierce et al [38] expose legacy code as services via a Service Manager, which create new service instance as a resource. The service instance is lightweight front end and it directs the requests to the worker backend via a resource manager. These services are stateful, and they support migration and check pointing based recovery. Furthermore, Otho Toolkit [23] presents another system that wraps legacy code as services, and services support multiple service platforms, parameter sweeping, iterative and parallel programs, progress reporting, and file staging. The Generic Service Toolkit stands out because of the flexible architecture implements an interceptor pipeline. Consequently, the toolkit is generic and all domain specific details have been implemented as plug-ins, which can be dynamically coupled as per the request. These

8 features have been tested extensively with meteorological specific requirements. The current second generation version of this toolkit is a redesign of the earlier version [28] and provides many additional features like Auditing, batch queue scheduling, urgent computing. Furthermore, with the OGCE [5] initiative we have packaged it for generic grid deployment, making it usable by small and medium scale applications along with already supported large-scale complex use cases. The concept of a service registry has been proposed by Web Services architectures in the forms of UDDI; there have been many implementations of service registries from industry (e.g. WebSphere Service Registry [7]) and research community (e.g. [29]). Among Grid specific service registries, GIS [17] facilitates users to register and discover resources in the Grid environment via a directory service interface. On the other hand, Taverna workflow suite includes Grimoires [53] service registry that allows users to search for services using semantics, which also supports Access Control mechanism. However, the referred publications do not provide more details. GAT [8] provides a service toolkit, registry that allows users to search for services with some functionality, and Triana workflow composer to compose and run workflows. Bubaka et al [12] presents a P2P network based service registry, where domains and tasks are distributed among the nodes. Furthermore, the system includes a workflow composer that uses the registry for semantic based search for service and data in the system. The XRegistry service provides support for sharing resources via recursive groups based on hierarchies and this functionality is not yet common in registry services for scientific workflow environments. However, we believe our main contribution from the registry is its well-suited adoption to collaborations and science gateway environments. The LEAD workflow architecture is an integrated framework of 3 different software components. And these components can be used as individual components or a cohesive system. And more over the workflow components are designed as high-level tools flexible to interoperate with multiple low level systems and the implementations have been embedded and well tested. We believe, the LEAD Workflow Infrastructure work out of the box for many use cases, and it is designed to be applicable to multiple science domains with minimal or no effort. 6 CONCLUSION Collaborations among scientists have been a major focus in today s research world, and an initial step towards such collaborations is sharing of scientific models and applications across a wider community. However, without tools to facilities such collaborations, the controlled sharing and collective execution of applications is hard and time consuming if not impossible. In related work we discussed various tools which address scientific workflows requirements at different levels and some of them are catered to address domain centric issues. Among such tools are the ones developed as a part of Linked Environments for Atmospheric Discovery project which is building an integrated, scalable dynamically adaptive Cyberinfrastructure. The software tools have been designed as an extensible framework with pluggable domain specific modules. In this paper we presented the LEAD workflow infrastructure and its usage by multiple science gateways. We discussed the architecture of the workflow suite comprising of a service toolkit, a registry and a workflow GUI which facilitates users to wrap command line applications as Web services, compose them as workflows, and share, execute and monitor those service and workflows. Furthermore, we demonstrated how the software components are flexible and extensible. The use cases presented represent they can be used alike by small and large science gateways. Various usage scenarios derived from real-world collaborations have been presented justifying the generality of the components. In conclusion, we argue that this generic and extensible architecture can be adopted by wide range of communities with minimal or no work, so they shall be benefited the same way as the broad range of users and their requirements in the LEAD project. Therefore, we believe the presented workflow infrastructure will be of immense interest to TeraGrid user community and the software is released and supported through OGCE project and further details and contact information can be found at ACKNOWLEDGEMENTS The development of the infrastructure is funded through LEAD project supported by National Science Foundation (NSF) Cooperative Agreements ATM , ATM , ATM , ATM , ATM , ATM , ATM , and ATM The workflow infrastructure is being packaged, tested and supported through NSF Award number , SDCI NMI Improvement: Open Grid Computing Environments Software for Science Gateways. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect those of the National Science Foundation. The Generic Service Toolkit and XBaya GUI are the research outcomes from PhD thesis of Gopi kandaswamy and Satoshi Shirasuna and the authors would like to deeply acknowledge their contributions. Furthermore, the authors would like to thank LEAD users and members of the LEAD Team from Indiana University, University of Oklahoma, Millersville University, Howard University, UCAR Unidata Program, University of Alabama in Huntsville and National Center for Supercomputing Applications who have been an integral part of the presented infrastructure. REFERENCES [1] American meteorology society. [2] Apache ode project. [3] Jython project. [4] National doppler radar sites. [5] Open Grid Computing Environments. Page. [6] Vges project. system/vgesoverview. [7] [8] G. Allen, T. Goodale, T. Radke, M. Russell, E. Seidel, K. Davis, K.N. Dolkas, N.D. Doulamis, T. Kielmann, A. Merzky, et al. Enabling Applications on the Grid: A Gridlab Overview. International Journal of High Performance Computing Applications, 17(4):449, [9] G. Alliance. Globus toolkit documentation, WS-GRAM. [10] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, et al. Business Process Execution Language for Web Services, Version 1.1. Specification, BEA Systems, IBM Corp., Microsoft Corp., SAP AG, Siebel Systems, [11] Pete Beckman, Ivan Beschastnikh, Suman Nadella,, and Nick Trebon. Building an ifrastructure for urgent computing, in high performance computing and grids in action. IOS Press, Amsterdam, [12] M. Bubak, T. Gubała, M. Kapałka, M. Malawski, and K. Rycerz. Workflow composer and service registry for grid applications. Future Generation Computer Systems, 21(1):79 86, 2005.

9 [13] C. Catlett. The philosophy of TeraGrid: building an open, extensible, distributed TeraScale facility. Cluster Computing and the Grid 2nd IEEE/ACM International Symposium CCGRID2002, pages 5 5, [14] D. Churches, G. Gombas, A. Harrison, J. Maassen, C. Robinson, M. Shields, I. Taylor, and I. Wang. Programming Scientific and Distributed Workflow with Triana Services. Grid Workflow, [15] R.D. Clark. The LEAD-WxChallenge pilot project: enabling the community. 24th Conference on IIPS, [16] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unraveling the Web services web: an introduction to SOAP, WSDL, anduddi. Internet Computing, IEEE, 6(2):86 93, [17] K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman. Grid Information Services for Distributed Resource Sharing. 10th IEEE International Symposium on High Performance Distributed Computing, 184, [18] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, and S. Tuecke. A Resource Management Architecture for Metacomputing Systems. Job Scheduling Strategies for Parallel Processing: IPPS/SPDP 98 Workshop, Orlando, Florida, USA, March 30, 1998: Proceedings, [19] X. Dong, K.E. Gilbert, R. Guha, R. Heiland, J. Kim, M.E. Pierce, G.C. Fox, and D.J. Wild. Web Service Infrastructure for Chemoinformatics. J. Chem. Inf. Model, 47(4): , [20] K.K. Droegemeier, V. Chandrasekar, R. Clark, D. Gannon, S. Graves, E. Joseph, M. Ramamurthy, R. Wilhelmson, K. Brewster, B. Domenico, et al. Linked environments for atmospheric discovery (LEAD): A cyberinfrastructure for mesoscale meteorology research and education. 20th Conf. on Interactive Information Processing Systems for Meteorology, Oceanography, and Hydrology, [21] N. GridCenter. A Portal-based User Registration Service for Grids, [22] Z. Guan, V. Velusamy, and P. Bangalore. GridDeploy: A Toolkit for Deploying Applications as Grid Services. Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC 05)-Volume II-Volume 02, pages , [23] J. Hofer and T. Fahringer. Presenting Scientific Legacy Programs as Grid Services via Program Synthesis. Proceedings of the Second IEEE International Conference on e-science and Grid Computing, [24] Y. Huang, A. Slominski, C. Herath, and D. Gannon. WS-Messenger: A Web Services based Messaging System for Service-Oriented Grid Computing. 6th IEEE International Symposium on Cluster Computing and the Grid (CCGrid06), [25] D. Hull, K. Wolstencroft, R. Stevens, C. Goble, M.R. Pocock, P. Li, and T. Oinn. Taverna: a tool for building and running workflows of services. Nucleic Acids Research, 34(Web Server issue):w729, [26] P. Kacsuk, A. Goyeneche, T. Delaitre, T. Kiss, Z. Farkas, and T. Boczko. High-level Grid Application Environment to Use Legacy Codes as OGSA Grid Services. Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, [27] G. Kandaswamy, L. Fang, Y. Huang, S. Shirasuna, S. Marru, and D. Gannon. Building web services for scientific grid applications. IBM Journal of Research and Development, 50(2/3): , [28] G. Kandaswamy and D. Gannon. A Mechanism for Creating Scientific Application Services On-demand from Workflows. Proceedings of the 2006 International Conference Workshops on Parallel Processing, pages 25 32, [29] M. Kasztelnik, M. Bubak, C. Gorka, M. Malawski, and T. Gubala. FAULT TOLERANT GRID REGISTRY. [30] S. Krishnan, B. Stearn, K. Bhatia, K.K. Baldridge, W.W. Li, and P. Arzberger. Opal: Simple Web Services Wrappers for Scientific Applications. International Conference for Web Services, [31] B. Ludäscher, I. Altintas, C. Berkley, D. Higgins, E. Jaeger-Frank, M. Jones, E. Lee, J. Tao, and Y. Zhao. Scientific Workflow Management and the Kepler System. Concurrency and Computation: Practice & Experience, [32] S. Martin, P. Lane, I. Foster, and M. Christie. TeraGrids GRAM Auditing & Accounting, & its Integration with the LEAD Science Gateway. Teragrid 2007 Conference, Madison. [33] A. Matsunaga, M. Tsugawa, S. Adabala, R. Figueiredo, H. Lam, and J. Fortes. Science gateways made easy: the In-VIGO approach. Concurrency and Computation: Practice and Experience. [34] A. Matsunaga, M. Tsugawa, and J.A.B. Fortes. Integration of text-based applications into service-oriented architectures for transnational digital government. Proceedings of the 8th annual international conference on Digital government research: bridging disciplines & domains, pages , [35] J. Michalakes, S. Chen, J. Dudhia, L. Hart, J. Klemp, J. Middlecoff, and W. Skamarock. Development of a next-generation regional weather research and forecast model [36] J. Novotny, S. Tuecke, and V. Welch. An Online Credential Repository for the Grid: MyProxy. Proceedings of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), pages , [37] S. Perera and D. Gannon. Enabling Web Service Extensions for Scientific Workflows. Workshop on Workflows in Support of Large-Scale Science (works06). In conjunction with HPDC06, Paris, France, [38] M. Pierce and G. Fox. Making scientific applications as Web services. Computing in Science and Engineering, 6(1):93 96, [39] R. Ramachandran et al. LEAD Metadata Schema for Geospatial Data Sets Based on FGDC Standard [40] J. Rushing, R. Ramachandran, U. Nair, S. Graves, R. Welch, and H. Lin. ADaM: a data mining toolkit for scientists and engineers. Computers and Geosciences, 31(5): , [41] V. Sanjeepan, A. Matsunaga, L. Zhu, H. Lam, and J.A.B. Fortes. A Service-Oriented, Scalable Approach to Grid-Enabling of Legacy Scientific Applications. Proc. of the International Conference on Web services 2005, [42] Shirasuna Satoshi, Ph.D. Thesis.: Department of Computer Science, Indiana University. [43] R. Schmidt. Java Network Launching Protocol (JNLP) Specification [44] M. Senger, P. Rice, and T. Oinn. Soaplab-a unified Sesame door to analysis tools. Proc UK e-science programme All Hands Conference, pages 2 4, [45] A. Slominski. Adapting BPEL to Scientific Workflows. Workflows for e-science, pages [46] A. Slominski and G. von Laszewski. Scientific Workflows Survey. See website at extreme. indiana. edu/swf-survey.

10 [47] J.L. Tilson, G. Rendon, M.F. Ger, and E. Jakobsson. MotifNetwork: A Grid-enabled Workflow for High-throughput Domain Analysis of Biological Sequences: Implications for annotation and study of phylogeny, protein interactions, and intraspecies variation. Bioinformatics and Bioengineering, BIBE Proceedings of the 7th IEEE International Conference on, pages , [48] U. Tom Baltzer. LEAD at the Unidata workshop: demonstrating democratization of NWP capabilities. 23rd Conference on IIPS, [49] S. Vinoski. Chain of responsibility. Internet Computing, IEEE, 6(6):80 83, [50] D. Weber. Use of the LEAD Portal for On-Demand Severe Weather Prediction. 24th Conference on IIPS, [51] SJ Weiss, JS Kain, DR Bright, JJ Levit, GW Carbin, ME Pyle, ZI Janjic, BS Ferrier, J. Du, ML Weisman, et al. The NOAA Hazardous Weather Testbed: Collaborative testing of ensemble and convectionallowing WRF models and subsequent transfer to operations at the Storm Prediction Center. 22nd Conf. Wea. Anal. Forecasting/18th Conf. Num. Wea. Pred., Salt Lake City, Utah, Amer. Meteor. Soc., CDROM 6B, 4, [52] R. Wolski, N. Spring, and J. Hayes. The Network Weather Service: A Distributed Resource Performance Forecasting Service for Metacomputing. Journal of Future Generation Computing Systems, 15(5-6): , [53] SC Wong, V. Tan, W. Fang, S. Miles, and L. Moreau. Grimoires: Grid Registry with Metadata Oriented Interface: Robustness, Efficiency, Security Work-in-Progress [54] M. Xue, D. Wang, J. Gao, K. Brewster, and K.K. Droegemeier. The Advanced Regional Prediction System (ARPS), storm-scale numerical weather prediction and data assimilation. Meteorology and Atmospheric Physics, 82(1): , [55] J. Yu and R. Buyya. A taxonomy of scientific workflow systems for grid computing. SIGMOD Record, 34(3):44 49, 2005.