Workflow Engines: Why So Many?
Presented on Wednesday, April 7, 2010 at 11:00am PST.
Workflow engines are becoming more commonly used in Earth Science data systems. But the with plethora of workflow engines to choose from and the variability of their capabilities, it may be time consuming to assess which workflow engine is best suited for a particular domain adaptation. We will explore the diverse capabilities of a few selected workflow engines and discuss some of the relevant capabilities useful for Earth Science data systems.
- Interoperability among workflow engines. Can mitigate interoperability risks by leveraging more standards-oriented constructs. For example, in distributed workflows, wrap components as simple REST/SOAP service endpoints. This maximizes the ability to swap the workflow engines without modifying the service components. The invocation essentially remains unchanged. Also, many of the workflow engines are BPEL-based so variations across implementations are not as dramatic. Currently, some workflow engines are adhering to the OASIS WS-BPEL 2.0 spec.
- How does an organization develop strategy to marshaling or streamline the rapid proliferation of workflows (into fewer/faster workflows)? One approach is to leverage more of workflow reuse through appropriate abstraction layers of nested workflows. Another approach is to take a more collaborative view and share workflows in a community. An example is myExperiment, which "makes it easy to find, use and share scientific workflows and other Research Objects, and to build communities."
- Apache ODE
- JBoss jBPM
- Workpoint: PBM with Torque
- GeoBrain BPELPower Workflow Engine
- GeoBrain Online Analysis System (GeOnAS)
- Multi-mission Automated Task Invocation System
- Taverna Workbench
- PHX ModelCenter
- BeanShell: Lightweight Scripting for Java
- Data-type and Service Ontologies
- OASIS WS-BPEL 2.0
Hook Hua 2010-04-08T23:05:00-07:00