Transcript Interoperability between Scientific Workflows

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