Scientists believe in the concept of collective intelligence and are increasingly collaborating with their peers, sharing data and simulation techniques. These collaborations are made possible by building eScience infrastructures. eScience infrastructures build and assemble various scientific workflow and data management tools which provide rich end user functionality while abstracting the complexities of many underlying technologies. For instance, workflow systems provide a means to execute complex sequence of tasks with or without intensive user intervention and in ways that support flexible reordering and reconfiguration of the workflow. As the workflow technologies continue to emerge, the need for interoperability and standardization clamorous. The Web Services Business Process Execution Language (WS-BPEL) provides one such standard way of defining workflows. WS-BPEL specification encompasses broad range of workflow composition and description capabilities that can be applied to both abstract as well as concrete executable components.
Scientific workflows with their agile characteristics present significant challenges in embracing WS-BPEL for eScience purposes. In this paper we discuss the experiences in adopting a WS-BPEL runtime within an eScience infrastructure with reference to an early implementation of a custom eScience motivated BPEL like workflow engine. Specifically the paper focuses on replacing the early adopter research system with a widely used open source WS-BPEL runtime, Apache ODE, while retaining the interoperable design to switch to any WS-BPEL compliant workflow runtime in future. The paper discusses the challenges encountered in extending a business motivated workflow engine for scientific workflow executions. Further, the paper presents performance benchmarks for the developed system.
Experience with adapting a WS-BPEL runtime for eScience workflows
1. Experience with Adapting a WS-BPEL Runtime for eScience Workflows Thilina Gunarathne, Chathura Herath, Eran Chinthaka, Suresh Marru Pervasive Technology Institute Indiana University
2. Introduction Scientist communities are solving deeper larger problems spanning across domains Share & combine multiple applications in flexible yet planned order Orchestrate together using workflows Most of the scientific workflow systems use custom formats Interoperability challenge
3. WS-BPEL Business Process Execution Language for Web Services (WS-BPEL) De-facto standard for specifying web service based business processes and service compositions Basic activities Invoke, Receive, Assign.. Structured activities Sequence, Flow, ForEach,..
4. LEAD: an NSF funded large Information Technology Research Project
5. Linked Environments for Atmospheric Discovery LEAD – researched to better understand the atmosphere, educate more effectively about it, and forecast more accurately by adapting technologies as the weather occurs. improved mesoscale forecasts ingested more local observations to enhance the initial conditions. Used in NOAA Storm Prediction Center Hazardous Weather Testbed Spring Experiments. Used in National Collegiate Forecast Competition Used by USDA for crop planning Used as Educational Tools
6. Storms Forming Forecast Model Streaming Observations Data Mining Instrument Steering Refine forecast grid LEAD Dynamic Adaptive Infrastructure
9. GPEL Grid Process Execution Language BPEL4WS based home grown research workflow engine Supports a subset of BPEL4WS 1.1 One of the very early adaptations of BPEL efforts Specifically designed for eScience Usage Long running workflow support Decoupled client
12. Propagation of Workflow Context Information Lead Context Header (LCH) Unique identifiers End point references Configurations information Security information Lead mandates propagation of LCH with application specific SOAP messages Workflow runtime need to propagate the LCH received in input message to every service invocation message
13. Propagation of Workflow Context Information Implemented using auto-generated WS-BPEL logic Define LCH in the WSDL of the workflow, by binding a message part to a SOAP header block Allows us to access LCH as a variable inside WS-BPEL process
14.
15. Asynchronous Invocation Prohibitive to invoke LEAD services in a synchronous blocking manner Long running tasks => long running web service invocations Multi hops No standard compliant unambiguous mechanism for asynchronous req/resp web service operation invocations in WS-BPEL No integrated support for WS-Addressing
16. Asynchronous Invocation Two popular mechanisms Implement as dual one way messages Requires reply address information to be propagated using a proprietary mechanisms Requires services to be modified Make invoke inherently asynchronous Non-portability of the WS-BPEL process behavior Proposal for WS-Addressing based WS-BPEL extension
17. Notification & Monitoring Two types of monitoring Workflow engine state monitoring Service invocation state monitoring Generating Notifications from BPEL Engine Out of scope of WS-BPEL specification Almost all the popular WS-BPEL runtimes provide plug-in mechanisms for notification generation LEAD workflow tracking library based Apache ODE notification handler
18. Notification & Monitoring – Assigning Service Identifiers Fine grained monitoring Necessitates unique identifiers for each service invocation XBayagenerated identifiers Node-id Workflow time step Rely on WS-BPEL logic to copy the identifiers to LCH of service invocation messages
19. Workflow Instance Creation In GPEL, separate workflow instance creation and execution steps Workflow engine creates the identifiers In WS-BPEL, workflow instances are created implicitly when messages are received <receive> activities marked with “createinstance=true” Workflow client creates the Workflow-Instance-ID Different from Apache ODE internal process instance id Correlation between two ids in the first notification
20. Variable Initializing WS-BPEL requires complex variables to be initialized before using or copying in to them Xbaya workflow composer automatically adds WS-BPEL logic for initialization steps using its domain knowledge Some engines initialize variables automatically But cannot be done accurately for all the cases without the domain knowledge
21. Workflow Deployment No standard way of packaging and deploying WS-BPEL processes Xbaya workflow composer is designed to support many workflow engines Engine specific decoupled workflow proxy services Generic workflow description from XBaya to the proxy service Currently XBaya contains few ODE specific changes, which will be removed soon.
22. Workflow Client BPEL 1.1 BPEL 2.0 SCUFL Abstract DAG Model Composition and Monitoring Python Dynamic Enactor/ Interpreter Jython Based Enactor GPEL Engine Apache ODE Engine Taverna Python Runtime Message Bus
26. Workflow instance recovery Multi-level fault tolerance support in LEAD No need to use WS-BPEL exception handling WS-BPEL error recovery Vs Scientific workflows Only infrastructure failures are handled at the working engine level Hasthi monitoring infrastructure Performs corrective actions in the event of an infrastructure failure Recovery of infrastructure components Resurrects workflow instances by replaying input messages
27. Performance & Reliability Evaluate the workflow system with regards to LEAD performance and scalability requirements Scalable back end service TPS >4000 Same configuration as LEAD production ODE
30. Performance Comments Parallel speedup results More than factor of 4 speedup when 5 way parallelism is used with a long running service Notification overhead is smaller in complex workflows
31. Experience Currently deployed in the LEAD production & development stacks More than 1000 workflow deployments Available open source in OGCE – Xbaya & the scientific workflow extensions Minimal changes to ODEas most of the requirements were implemented using auto generated WS-BPEL logic.
33. Acknowledgement AleksanderSlominski and Satoshi Shirasuna for the foundation they laid. Prof. Dennis Gannon & Prof. Beth Plale for the mentoring SrinathPerera and LavanyaRamakrishnan for their direct and indirect constibutions. NSF funding for LEAD project and the NSF funding for OGCE
35. Service Monitoring via Events 1 2 3 4 5 6 The service output is a stream of events I am running your request I have started to move your input files. I have all the files I am running your application. The application is finished I am moving the output to you file space I am done. These are automatically generated by the service using a distributed event system(WS-Eventing / WS-Notification) Topic based pub-sub system witha well known “channel”. Application Service Instance Notification Channel Subscribe Topic=x x x publisher listener
Hinweis der Redaktion
Today I’m presenting a paper discussing our experience of adapting a WS-BPEL 2.0 run time for eScience workflows for an existing cyberinfrastructure. This work is done with my collegues C E & S and with the help of numerous others.
As we live in the era of data deluge and vast computational power. Increasingly we can notice sceientist communities are solving deeper larger problems spanning across Scientific disciplines. But solving thses interconnected problems mandates the scientists to share and combine applications in a flxebile but yet planned manner and ocrchestrate them using workflows. There exist many scientific workflow systems that allow scientists to construct, execute, manage and resuse workflows. But a problem with most of these systems is that they use custom formats to describes the workflows, giving rise to interoperability issues and hindering the sharing and reuse of workflow documents. A solution to this is to adapt a standard workflow description language.
WS-BPEL is a specification covering the composition and orchestration of business workflows using web services. BPEL supports many activities including…Scientific workflow requirements challenge WS-BPELAs I mentioned earlier in this paper we present the challenges we encountered when adapting WS-BPEL specifically for the LEAD project.
Objectives of LEAD or Linked Env… is to better understand the atmosphere, educated about it and to forecast weather as an when it happens.LEAD has been used in NOAA .. Weather challenge, USDA for crop planning and as a educational tool.
The workflow engine orchestrate the workflows and the DSC creates application services on demand using Gfac and the data stored in Xregistry. The service invocations by the workflow engine will eventualy get routed to the transient application services created by GFac., which will submit computational jobs the computational resources.
GPEL was a success with wide usage of infrastructure in educational and research efforts.But LEAD graduating form a research system to production system and to reduce the maintainanceload, to suppoirt new features, to improve performance and scalability required us to adapt a externally maintained workflow engine.
WS-BPEL 2.0 featuresensure sustainability by choosing a well supported run time with minimal custom changes;ensure portability & avoid locking in to a run time, by strictly adhering to open widely used standards as much as possible & by avoid using particular runtime specic features; minimize changes to the other legacy components of LEAD,improve the scalability & the performance.
According to soap spec, header elements can be used to pass optional information that does not belong to the application payload, which can include context information required Unique identifiers used for tracking and monitoring perposes.EPRs such as Registry, GfacDSc, etc.. Confgi information to stage data, perform comput scheduling, etc..
Earlier hard coded in to GPEL.. But we did not want to modify the workflow engines..Implemented using… WE use a often overlooked feature of WSDl, where it allows us to bind message parts to the SOAP header blocks.
CompositionOrchestrationMonitoringADAG that gets compiled in to each execution environement as necessaryDynamic enactor – provide dynamic user interaction
Interact with event streams – weather radars, telescopes, etcScientific workflows are static data input processes
4 notifications per each workflow40 threads keep invoking the workflow for given number of invocations
Chose <for-each> because parallel & seqeuntial in one
