Interoperability between Scientific Workflows Ahmed Alqaoud, Ian Taylor, and Andrew Jones Cardiff...
-
Upload
hollie-george -
Category
Documents
-
view
212 -
download
0
Transcript of Interoperability between Scientific Workflows Ahmed Alqaoud, Ian Taylor, and Andrew Jones Cardiff...
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….?