Web Services Mediation

Robust, Scalable, Highly-available Web Services Mediation

While Web services standards define service interaction semantics and on-the-wire protocols, they are silent on matters of implementation. The qualities of an implementation of the advanced Web services in SOA infrastructure used for mediation — including, but not limited to enterprise service buses — will determine the robustness, performance and scalability the mediating infrastructure. These aspects will vary from vendor to vendor, and should be examined closely to determine their suitability for broad-scale deployment.

The figure below illustrates the WS-ReliableMessaging model by depicting the relationship of four entities: the source and destination applications and the reliable messaging source and destination endpoints. In the "transmit/acknowledge" communications protocols, WS-RM delivery semantics are ensured through the use of acknowledgements and message sequence numbering. Message order can be preserved, duplicates can be detected, and gaps caused by lost messages can be recovered through request for redelivery.

WS-RM defines an on-the-wire protocol that guarantees qualities of service of interactions between a WS-RM Source and WS-RM Destination.

While the WS-ReliableMessaging protocol can assure message delivery upon recovery from network failures, it does not specify how an implementation of the RM Source or Destination itself should be robust should either side fail. Recovery from failure at either end requires recovery of state related to the sequence in transmission and how much has been acknowledged.

As in any reliable message delivery system, to fulfill the "exactly once" quality of service, an implementation will typically depend on local persistent storage, which will be accessed in case of failure by the RM Source/Destination to determine which message sequence, if any, is still being processed, and which message in that sequence was last acknowledged and therefore should not be processed a second time.

The diagram below illustrates the architectural elements of an implementation that can guarantee exactly-once delivery between two WS-RM Web services. The brace represents the Web service interface, and the circle represents the WS-RM implementation as part of that Web service. Persistent storage is made available to the WS-RM Source and Destination, so both sides are capable of recovery not only from network failure, but from failure of the hardware on which the WS-RM implementation itself is running.

A WS-RM broker is an intermediary that provides loose coupling between the Web service producer and consumer. By supporting WS-RM protocols, the intermediary can recover from network failures on either side. For the broker to recover from hardware failure without losing information it has accepted from one Web service on behalf of another, it must persistently store messages for which it has acknowledged receipt up until the time that it has received acknowledgement of receipt from the destination. So, not only is this store important to preserve the state of pending WS-RM interactions with the sender and receiver, it must also be used to store messages accepted on behalf of a WS-RM destination but not yet delivered. This allows buffering of yet undelivered or unacknowledged messages to exceed the system memory available to the broker.

A WS-RM broker stores and forwards messages to and from WS-RM sources and destinations. To allow recovery from broker failure while minimizing communication latency, the broker must efficiently store messages for which it has acknowledged receipt but has not yet forwarded or received acknowledgement of receipt.

While it is certainly possible to implement WS-ReliableMessaging brokers by using a relational database for its persistent store, such an approach will typically yield very poor throughput performance. Relational databases in general are not optimized for the workload presented by persistent queues. By contrast, purpose-built messaging broker technologies offer significantly superior throughput for a given hardware specification.

Scalability for additional throughput demands and high-availability of WS-RM brokering requires the use of multiple WS-RM brokers to share processing load. Each broker must be independently capable of recovery. To do this efficiently, while taking into account all possible failure modes requires sophisticated clustering and high-availability technologies to ensure that any broker in the cluster can carry on the work of a failed broker, and do so without losing messages accepted by the failed broker. Only the most advanced, high-availability implementations can perform this function in a manner completely transparent to the producing and consuming services.

A WS-RM broker cluster provides the same function as a WS-RM broker, but can scale and provide high availability by sharing load across many brokers in the cluster. Advanced implementation techniques are required to make this perform efficiently while fulfilling all qualities of service guaranteed by the WS-RM protocol.

Related Topics

• Web Services
• Web Services and an ESB
• Enterprise Service Bus
• Application Integration Patterns with SOA
• SOA Infrastructure
• Web Services Management
• Semantic Integration

You may also be interested in:

• Sonic ESB
• ESB Resource Center
• Industry Solutions
• Industry Events
• Partner Programs