| There are a number of standards that continue to evolve in the area of MOM. One established standard is the Java Message Service, and others that are evolving are those based on SOAP and web services. 5.7.1 The Java Message Service (JMS) The Java Message Service (JMS) is a messaging specification that has enjoyed widespread industry adoption since its introduction in 1998. JMS provides an API and a set of rules that govern message delivery semantics in a MOM environment for both reliable and unreliable messaging. The JMS specification defines rules for operational behavior of publish-and-subscribe and point-to-point queuing. There are also very rich and flexible definitions of what a message is composed of, and strict rules governing store-and-forward messaging, guaranteed delivery, message acknowledgments, transactions, and recovery from failures. JMS also provides the multiresource transaction model described in this chapter. The advantage of having specified behavioral rules is that you can rely on a base set of behavior in the messaging environment, regardless of the vendor implementation. While largely intended as an asynchronous form of communication between applications, JMS also has a set of messaging patterns and helper interfaces to synchronously and asynchronously support the request/reply pattern using both the pub/sub and point-to-point messaging models. JMS provides an optional interface for integrating with an application server. This allows a JMS provider from one vendor to integrate with an application server from another vendor. An ESB provider that supports a JMS interface should support the application server interfaces as well. 5.7.1.1 What about the "J" in JMS? JMS most definitely has its roots in Java. However, you don't have to be a Java programmer to use a JMS-compliant messaging system if you are using an ESB. While you could theoretically implement an ESB using a MOM that is not JMS-compliant, it's a better idea not to, for a number of reasons. Using an ESB that supports JMS message delivery semantics means that you can count on certain behavioral rules. Regardless of the vendor implementation, you can rely on the existence of capabilities such as durable subscriptions for pub/sub messaging, and transactional recovery from failure with either messaging model. You also reap the benefits of standards-based integration, as outlined in Chapter 3. That said, even if you are not particularly wedded to Java, you can still take advantage of JMS if you are using an ESB. An ESB implementation that supports JMS can also provide non-Java client types for C++, VB, or C#. JMS defines an API that can be similarly implemented in Java, C++, or C# if you are coding messaging clients directly. If you are designing an ESB integration strategy that requires only plugging together application adapters and integration services without any specific client coding, JMS can add value by providing a consistent set of behavior rules for the underlying messaging system, regardless of the vendor providing the implementation. 5.7.2 Reliable Messaging with SOAP One approach to achieving asynchronous reliability between web services is via a reliable protocol at the SOAP level. In this approach, message acknowledgments and delivery receipts are encoded in predefined SOAP envelope header constructs. Examples of this that are evolving today are WS-ReliableMessaging and WS-Reliability. ESBs are well suited for adopting these protocols as they mature and are implemented by more vendors. An ESB should be capable of supporting any number of reliable messaging transports and protocols. 5.7.3 Web Services Events and Notifications Two nascent specifications, WS-Eventing and WS-Notification, describe how publish-and-subscribe should work across web services interfaces and protocols. A technical committee has been formed under OASIS under the auspice of WS-Notification to formalize a family of specifications detailing a publish-and-subscribe event notification model using web services and SOAP. |