1 / 25

BPEL for Scientific Workflows

BPEL for Scientific Workflows. Shiyong Lu. What is BPEL. BPEL stands for Business Process Execution Language, a de facto specification language for business workflows mainly consisting of Web services. Is BPEL suitable/sufficient for scientific workflows?. An overview of BPEL.

eze
Télécharger la présentation

BPEL for Scientific Workflows

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BPEL for Scientific Workflows Shiyong Lu

  2. What is BPEL • BPEL stands for Business Process Execution Language, a de facto specification language for business workflows mainly consisting of Web services. • Is BPEL suitable/sufficient for scientific workflows?

  3. An overview of BPEL

  4. Invoke Activity

  5. Receive Activity

  6. Reply Activity

  7. Assign Activity

  8. Sequence Activity

  9. If Activity

  10. While Activity

  11. repeatUntil Activity

  12. forEach Activity

  13. Flow Activity

  14. Pick Activity

  15. Scope Activity

  16. BPEL is sufficient! (Akram et al) Requirements for scientific workflows: • Modular design • Exception handling • Compensation mechanism • Adaptivity to environment • Flexibility to select services dynamically • Steering and monitoring

  17. because… (Akram et al) • Modular design: (Sequence, flows, scope) • Exception handling (global, scoped, inline) • Compensation mechanism (compensation handler) • Adaptivity (XML any data type) • Flexibility to select services dynamically (exception handler, compensation handler) • Steering and monitoring (Pick, onMessage, onAlarm)

  18. despite… (Akram et al) Some limitations which are overcomable by WSIF, J2EE and WS-* specifications. • Reusability of primitive and structured activities in BPEL is limited. It is not possible to re-execute an activity that is defined earlier by referring to it later; • It is not possible to trigger an <onMessage> or <onAlarm> event within the workflow for the purposes of dynamically modifying the workflow at runtime. 3. The BPEL specification does not explicitly support user interactions resulting in different levels of support for different workflow engines.

  19. BPEL or Taverna? (A comparison done by Tan et al.) • They compare their usability in the full lifecycle of a scientific workflow, including service discovery, service composition, workflow execution, and workflow result analysis. • They determine that BPEL offers a comprehensive set of primitives for modeling processes of all flavors, while Taverna provides a more compact set of primitives and a functional programming model that eases data flow modeling.

  20. The life cycle of Scientific Workflows

  21. The challenges of Scientific Workflows • Resources are highly distributed. Scientific workflows usually use services owned by other organizations, like data storage, high-performance computing, • Dataflow oriented. Data is considered to be the first-class citizen in scientific workflows, because scientific workflows are mostly pipelines of parallel data processing. In a data flow, tasks and links represent data processing and data transport, respectively; parallel execution of independent tasks is desired to be modeled for free -- tasks can execute once their input are ready.

  22. The challenges of Scientific Workflows (con’t) • Large scale. Scientific workflows often contain many tasks, involve large data sets, and require intensive computation. The modeling tool should make it easy to model such complex workflows. • Data analysis and provenance is an important step and the workflow execution can be in an iterative manner.

  23. Comparison on service discovery (BPEL vs Taverna) • Services are often virtualizations of data storage, computation capability or other resources. • Service endpoints are not naturally known to users, either because users are not familiar with the service itself, or because the service deployment may have changed in time. • Taverna: a scavenger meta-service, Feta, and the MyGrid ontology, BPEL tools are still weak in service discovery.

  24. Comparison on workflow modeling (BPEL vs Taverna)

  25. References • Asif Akram, David Meredith, Rob Allan: Evaluation of BPEL to Scientific Workflows. CCGRID 2006:269-274 • Tan et al. “A comparison of using Taverna and BPEL in building scientific workflows: the case of caGrid”, 2009. Concurrency and Computation: Practice and Experience • Wei Tan, Paolo Missier, Ravi K. Madduri, Ian T. Foster: Building Scientific Workflow with Taverna and BPEL: A Comparative Study in caGrid. ICSOC Workshops 2008:118-129 • Aleksander Slominski, “Adapting BPEL to Scientific Workflows”, book chapter in book “Workflow for e-Science”, Eds: Ian Taylor, et al. • Wassermann et al, “Sedna: A BPEL-Based Environment for Visual Scientific Worklow Modeling”, book chapter in book “Workflow for e-Science”, Eds, Ian Taylor, et al.

More Related