Airavata WS-Messenger is a Web Services-based Messaging System for Service-Oriented Computing and is an implementation of WS-Notification and WS-Eventing specifications. The message format can be automatically converted between the two specifications. The subscription request type (Ws-Notification or WS-Eventing) for a listener determines the message format that the notification consumer will receive. If WS-Notification subscription request is received by the broker, it will send WS-Notification messages to the listener. Similarly, if WS-Eventing subscription is received by the broker, the broker will produce WS-Eventing messages for that listener. The publisher can publish messages in either format. The consumers will recieve messages in the format they subscribed irrespective of the format the message is published.

The WS-Messenger guarantees scalable, reliable and efficient message delivery. WS-Messenger contains sub-components of Message broker, Message box and WS-Messenger client libraries. WS-Messenger acts like the nervous system within Airavata infrastructure but can very well be integrated into any WS-Eventing/WS-Notification standard compliant infrastructures. The Messenger is deployed as a Axis2 service providing inherent support for different transports including HTTP 1.0, HTTP 1.1 and JMS. Custom transport protocols can be plugged in using the Axis2 framework's transport plug-ins. WS-Messenger is integrated with Mysql and Apache Derby database implementations. The embedded Derby database is deployed within the same Java process. The system also supports persistent subscriptions and notifications which will tolerate failures and restarts of the application server.

The following figure illustrates the high level overview of the WS-Messenger

WS-Messenger Modules¶

1. Message Broker: The broker handles filtering/delivering messages to even sinks and subscription management. WS-Messenger support filtering messages based on XPath expression and topic expression. Message broker is implemented on Web services specifications and provide the mediation between WS-Eventing Specification and WS-Notification Specifications. WS-Eventing and WS-Notification specifications are two competing specifications defining the interfaces for Web services-based publish/subscribe systems. The Web Services interfaces and the notification message formats defined in these two specifications are fundamentally different. WS-Messenger provides a mediation approach facilitating interoperability with supported services. WS-Messenger can automatically convert the notification message formats to makes sure that the message “on the wire” can be understood by the event consumers. For example, a WS-Notification consumer can receive notification messages published by a WS-Eventing publisher and vice versa. The event consumer type is determined by the subscription request message type. Here we assume that the subscribers and the event consumers use the same specification. This is a valid assumption for most cases since the subscribers needs to know the location of the event consumers. The message delivering schema is implemented by consumer blacklisting to minimize the overhead of message delivering failures. Message delivering performance has been implemented with a parallel message delivering sub system. The blocking I/O overhead is reduced configuring the NIO transport. WS-Messenger uses the NIO transport provided by Apache Synapse project to enable non-blocking I/O in Axis2.
2. Message Box: WS-Messenger decouples the consumer tolerating network failures and firewalls. The Message box acts like an intermediate notification storage between broker and the event sink. Users can simply create a message box and provide the message box URL as the event sink URL during the subscription. When messages are publishing to message broker notifications will send to the message box and it stores the incoming messages in to database or keep them in memory based on the WS-Messenger configuration. Message box Service has operations to pull the messages from the message box so whenever actual event sink is ready to pull the messages out from message box they simply have to invoke the message Pulling API and take the notifications. When the message box is no longer needed, the subscriber can send another web service request to destroy the message box.This is a useful feature in a scenario where event source cannot send notifications directly to even sink running behind the firewall. This deployment is a very common firewall configuration between DMZ and green zone in an enterprise deployment.provide a web service interface for subscribers behind the firewalls.

Airavata Usage of the WS-Messenger¶

Within Airavata, the WS-Messenger is used for user and system communications between GFac, XBaya and Workflow Intepreter. XBaya in monitoring mode subscribes to a pre-specified topic to which Workflow Engine and GFac are publishing status notifications. XBaya is instrumented to react to the messages to illustrate workflow progress by means of color coding of tasks being executed.

The following steps illustrates the usage in detail: XBaya creates a message Box, subscribes to it and then invokes a workflow, with the created message box EPR passed in context.
Then XBaya sends a subscription request to WS-Messenger with a particular topic and message box URL received as the event sink. Then workflow notifiers in XBaya send the notifications using the same topic to the message broker. Individual application services created by GFac are instrumented to publish detailed status and send progress to the EPR received in workflow execution context. * XBaya translates the messages into graphical colors and input and output extractions.