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….?