This article questions whether the new web-services standards will render Enterprise Service Bus (ESB) messaging standards such as Java Message Service (JMS) redundant.
The Enterprise Service Bus (ESB) has been at the forefront of Service Oriented Architecture (SOA) implementation in recent years. The use of a central message bus is a pre-SOA concept used in legacy Enterprise Application Integration (EAI) implementations. The message bus decouples the applications, and enables business critical messages to be sent with guaranteed delivery. SOA vendors have repositioned the message bus platforms as the underlying message infrastructure for their ever expanding SOA product stacks. Existing messaging platforms are typically based on the Java Message Service (JMS) standard, or similar.
These same vendors are also driving the ever-expanding web-services standards - A growing number of integration standards for application integration over web technologies.
This article aims to demonstrate that one particular web-services standard is now reaching the level of maturity where it threatens to supersede existing messaging infrastructure. A dedicated message platform based on existing message technology is no longer required to achieve the required QoS (Quality of Service) within an SOA environment.
SOA
A typical Service Oriented Architecture (SOA) implementation is comprised of different layers of services connected using a message bus.
According to the majority of SOA blueprints, the Basic Services layer includes the core applications. The Mediation Services provide technical message translation, transformation, routing and mappings typically built on an Enterprise Service Bus (ESB) platform.
The business Orchestration Services are typically built using a Business Process Management (BPM) platform.
Note: The term ESB often refers to a combination of the Message Bus and Mediation Services.
This article focuses on the message bus component.
Reliable Message Delivery
This quality of service measure ensures that business critical messages are not lost in transit. An example is the delivery of a new customer message from a sales system to a back-end billing system. If the message is not delivered due to technical issues, for example, the customer will not be billed. Platforms that support reliable message delivery include a series of acknowledgements, and a message resend capability guaranteeing that the message will eventually reach its destination.
SOAP over HTTP
SOAP provides an envelope for web-services messages. HTTP is the underlying internet messaging protocol. The great benefit of this combination of standards, and the reason for its wide adoption, is that it is interoperable across different platforms (and organizations). However, its Achilles’ heal is the lack of guaranteed message delivery.
JMS
The Java Message Service is today the most widely adopted enterprise messaging standard. The majority of ESB products in the market today expose a JMS interface. The java message service does provide guaranteed delivery of messages through a protocol of message acknowledgements, and resend capability.
SOAP over JMS
More recently platforms have began to support web-services implemented as SOAP over JMS. This solves the issue of unreliable HTTP message delivery by using a reliable message platform for transporting the SOAP messages. The disadvantage of this approach is that the JMS interface is specific to the java platform, and is not interoperable. A number of JMS vendors offer adapters for different development platforms (including Microsoft .net), although these adapters are non-standard. Another disadvantage of this approach is that JMS is not a common transport across organizations. It is a hub-based messaging architecture, rather than
distributed, does not use standard firewall ports, nor is it a wire standard.
The key reason for implementing SOAP over JMS in place of SOAP over HTTP is that the latter did not support reliable message delivery - until now.
Unreliable Web-Services
Solution Architects design their applications to expose web-services, in an attempt to provide the most standard, interoperable and flexible interface.
However, Integration Architects struggle to reach the QoS required within the enterprise using SOAP over HTTP web-services alone, and therefore opt to use a messaging backbone (typically JMS-based) for internal messaging.
This article proposes that the new web-service standard WS-ReliableMessaging could be used as the enterprise message bus standard in place of proprietary messaging platforms.
One of the dilemmas for Integration Architects is how to bridge SOAP over HTTP web-services to proprietary messaging platforms without compromising the QoS. The solution in the majority of cases is to build an adapter from the application to the message platform bypassing the web-services interface. If the SOAP over HTTP web-services interface is connected directly to the messaging platform, reliable messaging will be compromised.
Applications expose their basic services using SOAP over HTTP web-services. However, most SOA/ESB solutions use a reliable messaging platform such as JMS. A technical transformation is required.
The important point to note here is that because the SOAP over HTTP web-service is unreliable, connecting this web-service directly to an ESB compromises reliable message delivery.
One way to resolve this shortcoming is to connect the application directly to the reliable messaging platform. This may be achieved by either modifying the application to include an interface to the message bus (see J2EE application to the right of the diagram, connecting directly to JMS), or by building (or purchasing) an adapter. The former solution leads to a tights coupling of the application to the message bus technology.
It should also be noted that the SOAP over HTTP interface exposed by .net application is suitable for exposing over the internet.
Wouldn’t it be great if the inter and intra enterprise messaging standards were the same? The Integration Architect would only need to expose a service using one method for it to be available both internally and externally (security considerations would also have to be accommodated of course).
This article proposes a method for achieving this using a web-service standard that is gaining momentum in the industry: WS-ReliableMessaging.
WS-Reliable Messaging
This specification driven by Microsoft, IBM, TIBCO, BEA and others defines a standard way of sending messages in a predefined sequence, and receiving an acknowledgement for receipt of those messages.
Like all WS-* standards, WS-ReliableMessaging is implemented by extending the SOAP header to provide additional information, in this case regarding the sequence and delivery of messages.
The specification states that the sender adds a sequence to each message, and decides, based on acknowledgement from the destination whether a message should be resent or not. The destination acknowledges receipt of messages in a message sequence.
Quality of service is determined using four delivery assurances: AtMostOnce (no duplication, an error raised on duplication), AtLeastOnce (an error is raised if a message is not delivered), ExactlyOnce (no duplication, an error is raised on duplication, or if a message is not delivered) and InOrder (can be used in addition to one of the previous assurances).
Attached to the sending application is a Reliable Messaging (RM) source component, and attached to the receiver is an RM destination component. These components include persistence, thereby ensuring that messages are saved in a transactional manner, even if one or more components fail.
This new web-service standard is driven by the major application server and integration platform vendors, and is now incorporated into a number of mainstream products, including the most widely used application servers. This places the standard one step ahead of a large number of WS standards, many of which may not become widely adopted.
The diagram below illustrates the WS-RM based solution to the problem of connecting unreliable SOAP over HTTP web-services to a reliable message bus. With WS-RM, the web-services become reliable, and can therefore be connected to a message bus without
compromising reliable delivery of messages.
The messaging platform could remain a proprietary message bus, connected to application endpoints using reliable web-services (WS-RM).
If the WS-RM protocol provides reliable message delivery, is there really a need for a proprietary message bus? Would it not be simpler to use WS-RM as the preferred method for all reliable messaging?
A WS-RM Enterprise Service Bus
While WS-RM provides reliable delivery of messages, its architecture is very different to that of proprietary messaging platforms (including JMS).
Hub versus Distributed Message Platform
The JMS architecture is hub-based, while WS-RM is based on a distributed architecture.
The hub-based messaging platforms include a central messaging server where messages are published and received. The advantage of a hub-based message server is that all of the messages travel through a central point, enabling simpler management of messages and the messaging platform.
WS–ReliableMessaging is a distributed messaging architecture. It is designed to be used across enterprise boundaries such as firewalls, and allows messages to be sent using the SOAP over HTTP wire standard. This implies that different vendor implementations of WS-RM (potentially within different organizations) can act as the different WS-RM endpoints within a messaging topology (in the same way as is done today with standard SOAP over HTTP web-services). Responsibility for reliable message delivery is distributed between the various WS-RM endpoints, thereby eliminating the requirements for a central message broker.
However, a distributed message platform does require more complex management, as there will a larger number of message management points (in the case of WS-RM these are the endpoint RM-Source and RM-Destination), and this will inevitably lead to a higher cost of ownership. Savings will be achievable by the reduction in license costs (no requirement for a central message platform), and removal of support costs associated with the central message platform.
Other Web Service Standards
WS-ReliableMessaging is complemented by the benefits of the many other emerging web-services standards. For example, service discovery of web-services is available through the UDDI standard. WS-Transactions and WS-Eventing will add transaction management and publish-subscribe capability to web-service messaging. As these standards become more widely adopted by vendors, they will strengthen the web-services platform on which WS-ReliableMessaaging resides.
Is WS-ReliableMessaging the new Enterprise Service Bus?
The question is not so much whether the WS-RM will be used between enterprises. This is more or less a given. The question is whether WS-RM will be used within the enterprise, and will eventually replace the current wave of ESB offerings, most of which are based on JMS.
The major advantage of all the web-service standards, including WS-RM is that they are platform agnostic. An increasing number of applications support web-services, and as the application server vendors build WS-RM capability into their products, more and more applications will support WS-RM.
If you have already have application servers that support WS-ReliableMessaging out-of-the-box, you may not require an additional messaging platform. Existing web-services can be enhanced to support WS-RM. The proprietary messaging layer could then be replaced by reliable web-services.
The backing of major players in the industry, and the fact that they are following through by implementing the standard in their strategic product releases is a demonstration of the importance of this particular WS standard.
Open source support is evident with the Apache foundation extending its extremely popular web-services platform, Axis, to include support for WS-RM using the Sandesha module.
One example of a commercial ESB that uses WS-RM as its preferred reliable messaging platform is Cape Clear. The ESB does not come with a messaging platform as such, but rather recommends the use of WS-RM to connect the ESB components and applications in the enterprise architecture landscape.
The biggest advantage of WS-ReliableMessaging is that it can be used across organizations, and not just within them. The same reliable interface could be exposed both inside an organization and outside of it. This could potentially become the ultimate messaging platform.
These same vendors are also driving the ever-expanding web-services standards - A growing number of integration standards for application integration over web technologies.
This article aims to demonstrate that one particular web-services standard is now reaching the level of maturity where it threatens to supersede existing messaging infrastructure. A dedicated message platform based on existing message technology is no longer required to achieve the required QoS (Quality of Service) within an SOA environment.
SOA
A typical Service Oriented Architecture (SOA) implementation is comprised of different layers of services connected using a message bus.
According to the majority of SOA blueprints, the Basic Services layer includes the core applications. The Mediation Services provide technical message translation, transformation, routing and mappings typically built on an Enterprise Service Bus (ESB) platform.
The business Orchestration Services are typically built using a Business Process Management (BPM) platform.
Note: The term ESB often refers to a combination of the Message Bus and Mediation Services.
This article focuses on the message bus component.
Reliable Message Delivery
This quality of service measure ensures that business critical messages are not lost in transit. An example is the delivery of a new customer message from a sales system to a back-end billing system. If the message is not delivered due to technical issues, for example, the customer will not be billed. Platforms that support reliable message delivery include a series of acknowledgements, and a message resend capability guaranteeing that the message will eventually reach its destination.
SOAP over HTTP
SOAP provides an envelope for web-services messages. HTTP is the underlying internet messaging protocol. The great benefit of this combination of standards, and the reason for its wide adoption, is that it is interoperable across different platforms (and organizations). However, its Achilles’ heal is the lack of guaranteed message delivery.
JMS
The Java Message Service is today the most widely adopted enterprise messaging standard. The majority of ESB products in the market today expose a JMS interface. The java message service does provide guaranteed delivery of messages through a protocol of message acknowledgements, and resend capability.
SOAP over JMS
More recently platforms have began to support web-services implemented as SOAP over JMS. This solves the issue of unreliable HTTP message delivery by using a reliable message platform for transporting the SOAP messages. The disadvantage of this approach is that the JMS interface is specific to the java platform, and is not interoperable. A number of JMS vendors offer adapters for different development platforms (including Microsoft .net), although these adapters are non-standard. Another disadvantage of this approach is that JMS is not a common transport across organizations. It is a hub-based messaging architecture, rather than
distributed, does not use standard firewall ports, nor is it a wire standard.
The key reason for implementing SOAP over JMS in place of SOAP over HTTP is that the latter did not support reliable message delivery - until now.
Unreliable Web-Services
Solution Architects design their applications to expose web-services, in an attempt to provide the most standard, interoperable and flexible interface.
However, Integration Architects struggle to reach the QoS required within the enterprise using SOAP over HTTP web-services alone, and therefore opt to use a messaging backbone (typically JMS-based) for internal messaging.
This article proposes that the new web-service standard WS-ReliableMessaging could be used as the enterprise message bus standard in place of proprietary messaging platforms.
One of the dilemmas for Integration Architects is how to bridge SOAP over HTTP web-services to proprietary messaging platforms without compromising the QoS. The solution in the majority of cases is to build an adapter from the application to the message platform bypassing the web-services interface. If the SOAP over HTTP web-services interface is connected directly to the messaging platform, reliable messaging will be compromised.
Applications expose their basic services using SOAP over HTTP web-services. However, most SOA/ESB solutions use a reliable messaging platform such as JMS. A technical transformation is required.
The important point to note here is that because the SOAP over HTTP web-service is unreliable, connecting this web-service directly to an ESB compromises reliable message delivery.
One way to resolve this shortcoming is to connect the application directly to the reliable messaging platform. This may be achieved by either modifying the application to include an interface to the message bus (see J2EE application to the right of the diagram, connecting directly to JMS), or by building (or purchasing) an adapter. The former solution leads to a tights coupling of the application to the message bus technology.
It should also be noted that the SOAP over HTTP interface exposed by .net application is suitable for exposing over the internet.
Wouldn’t it be great if the inter and intra enterprise messaging standards were the same? The Integration Architect would only need to expose a service using one method for it to be available both internally and externally (security considerations would also have to be accommodated of course).
This article proposes a method for achieving this using a web-service standard that is gaining momentum in the industry: WS-ReliableMessaging.
WS-Reliable Messaging
This specification driven by Microsoft, IBM, TIBCO, BEA and others defines a standard way of sending messages in a predefined sequence, and receiving an acknowledgement for receipt of those messages.
Like all WS-* standards, WS-ReliableMessaging is implemented by extending the SOAP header to provide additional information, in this case regarding the sequence and delivery of messages.
The specification states that the sender adds a sequence to each message, and decides, based on acknowledgement from the destination whether a message should be resent or not. The destination acknowledges receipt of messages in a message sequence.
Quality of service is determined using four delivery assurances: AtMostOnce (no duplication, an error raised on duplication), AtLeastOnce (an error is raised if a message is not delivered), ExactlyOnce (no duplication, an error is raised on duplication, or if a message is not delivered) and InOrder (can be used in addition to one of the previous assurances).
Attached to the sending application is a Reliable Messaging (RM) source component, and attached to the receiver is an RM destination component. These components include persistence, thereby ensuring that messages are saved in a transactional manner, even if one or more components fail.
This new web-service standard is driven by the major application server and integration platform vendors, and is now incorporated into a number of mainstream products, including the most widely used application servers. This places the standard one step ahead of a large number of WS standards, many of which may not become widely adopted.
The diagram below illustrates the WS-RM based solution to the problem of connecting unreliable SOAP over HTTP web-services to a reliable message bus. With WS-RM, the web-services become reliable, and can therefore be connected to a message bus without
compromising reliable delivery of messages.
The messaging platform could remain a proprietary message bus, connected to application endpoints using reliable web-services (WS-RM).
If the WS-RM protocol provides reliable message delivery, is there really a need for a proprietary message bus? Would it not be simpler to use WS-RM as the preferred method for all reliable messaging?
A WS-RM Enterprise Service Bus
While WS-RM provides reliable delivery of messages, its architecture is very different to that of proprietary messaging platforms (including JMS).
Hub versus Distributed Message Platform
The JMS architecture is hub-based, while WS-RM is based on a distributed architecture.
The hub-based messaging platforms include a central messaging server where messages are published and received. The advantage of a hub-based message server is that all of the messages travel through a central point, enabling simpler management of messages and the messaging platform.
WS–ReliableMessaging is a distributed messaging architecture. It is designed to be used across enterprise boundaries such as firewalls, and allows messages to be sent using the SOAP over HTTP wire standard. This implies that different vendor implementations of WS-RM (potentially within different organizations) can act as the different WS-RM endpoints within a messaging topology (in the same way as is done today with standard SOAP over HTTP web-services). Responsibility for reliable message delivery is distributed between the various WS-RM endpoints, thereby eliminating the requirements for a central message broker.
However, a distributed message platform does require more complex management, as there will a larger number of message management points (in the case of WS-RM these are the endpoint RM-Source and RM-Destination), and this will inevitably lead to a higher cost of ownership. Savings will be achievable by the reduction in license costs (no requirement for a central message platform), and removal of support costs associated with the central message platform.
Other Web Service Standards
WS-ReliableMessaging is complemented by the benefits of the many other emerging web-services standards. For example, service discovery of web-services is available through the UDDI standard. WS-Transactions and WS-Eventing will add transaction management and publish-subscribe capability to web-service messaging. As these standards become more widely adopted by vendors, they will strengthen the web-services platform on which WS-ReliableMessaaging resides.
Is WS-ReliableMessaging the new Enterprise Service Bus?
The question is not so much whether the WS-RM will be used between enterprises. This is more or less a given. The question is whether WS-RM will be used within the enterprise, and will eventually replace the current wave of ESB offerings, most of which are based on JMS.
The major advantage of all the web-service standards, including WS-RM is that they are platform agnostic. An increasing number of applications support web-services, and as the application server vendors build WS-RM capability into their products, more and more applications will support WS-RM.
If you have already have application servers that support WS-ReliableMessaging out-of-the-box, you may not require an additional messaging platform. Existing web-services can be enhanced to support WS-RM. The proprietary messaging layer could then be replaced by reliable web-services.
The backing of major players in the industry, and the fact that they are following through by implementing the standard in their strategic product releases is a demonstration of the importance of this particular WS standard.
Open source support is evident with the Apache foundation extending its extremely popular web-services platform, Axis, to include support for WS-RM using the Sandesha module.
One example of a commercial ESB that uses WS-RM as its preferred reliable messaging platform is Cape Clear. The ESB does not come with a messaging platform as such, but rather recommends the use of WS-RM to connect the ESB components and applications in the enterprise architecture landscape.
The biggest advantage of WS-ReliableMessaging is that it can be used across organizations, and not just within them. The same reliable interface could be exposed both inside an organization and outside of it. This could potentially become the ultimate messaging platform.
A PDF of this article is available at:
About the author
Adi is an independent enterprise integration consultant, and owner of Arcadium Limited (http://www.arcadium-consulting.com/).
The contents of this article may not be copied, reproduced or published without permission from the author.
