Interoperability between Scientific Workflows

1. Ahmed Alqaoud, Ian Taylor, and Andrew Jones Cardiff University 10/09/2008 Interoperability between Scientific Workflows

2. Workflow Interoperability • Workflow Interoperability is defined as: “ the ability of two or more workflow engines to communicate and interoperate in order to coordinate and execute workflow process instances across those engines” (WfMC) • Interoperability benefit: - More collaboration between scientific projects - Ability to used a bigger set of tools - Reusability

3. Workflow Interoperability Level (1) • Direct interaction: use a common API between workflow systems; • Message Passing: defining a message-passing interface between workflow systems; • Bridging Mechanism: use a bridging mechanism which provides translation or gateway technique that moves data and tasks between workflow products; and • A shared data store: moves data and tasks between workflow products.

4. Workflow Interoperability Level (2) • Open Grid Forum (OGF): three levels for interoperability were identified: • Workflow embedding: allowing workflows to run within their own environment, but invoked from another; • The development of a meta language: allowing different proprietary languages to be mapped to a single standard language; and • Semanticannotation/description/classification: particularly important for sharing information.

5. Our Approach • An API is designed to achieve workflow interoperability at direct interaction level. • Based on a WS-based notification messaging method that uses asynchronous notification (WS-Eventing) • Asynchronous communication between different workflow system reduces dependency between processes in a system, • An API that can be implemented in multiple workflow systems such as Triana, Taverna, and Kepler.

6. WS-Eventing • WS-Eventing standard: used to pass messages between workflow systems. • WS-Eventing: support asynchronous messaging to deliver notification message. • WS-Eventing: is a simple and applied by several Grid projects. • Source Web Service: generator of notifications and manages the subscription. • Subscription Manager Web service: to manage the subscription. • Sink Web Service: is consider as a consumer for notification messages • Subscriber Web service: responsible for creating subscribe, renew, get status,and unsubscribe operations.

7. WS-Eventing Sequence Diagram

8. Workflow Interoperability Scenario • Triana workflow is used as a Source Web Service generating notification messages. • In Triana, user workflows can be deployed as fully functional Web Services. • Taverna workflows act as Sink Web Service that make subscription requests. • When the event has occurred in the Triana workflow, a notification message is sent to the Taverna workflow.

9. WSPeer • WSPeer: is hosting and invocation environment for web services • WSPeer: is the default deployment environment for web services in Triana workflow • WSPeer: support several binding such as JXTA, P2PS, Styx, and WSKPeer. • Styx: is a protocol that allow resources to exposed as a namespace, such UNIX file system /root/usr/ • WSPeer: with using a combination of P2PS and Styx, allows clients behind NATs and firewalls to receive notification messages.

10. Notification Message behind NATs • Client behind a NAT joins the P2PS network • Contacts the rendezvous service and queries for resolver services • Registers its logical address with the resolver service • The resolver then creates a virtual file mapped to the logical address of the client and returns the location of this file, which has a Styx address, to the client. • The client then initiates a read on the newly created file. client then subscribes to a topic provided by another service.

11. NAT traversal using P2PS and Styx (By Andrew Harrison)

12. Thank you Questions….?