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

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

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.

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 ● Semantic annotation/description/classification: particularly important for sharing information.

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.

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.

WS-Eventing Sequence Diagram

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.

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.

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.

NAT traversal using P2PS and Styx (By Andrew Harrison)

Thank you Questions….?