Message Oriented Middleware (MOM) and Java Message Service (JMS)

 

Message oriented middleware (MOM) frameworks enable one or more enterprise applications to communicate and share data in a heterogeneous environment. In addition to supporting heterogeneity, they also support asynchronous communication and tolerance to network failures. MOMs provide a standardized and fault tolerant way for applications to produce, exchange, and consume messages without any regard to the implementation detail of messages or the underlying network availability. Messages are sent to the logical destinations and domains rather than physical addresses. Messaging clients declare their interest in a particular domain or destination, provide appropriate security credentials, and exchange messages with the other clients via the MOM.

 

This concept of asynchronous communication agnostic to the underlying infrastructure is similar to how physical (postal) mail is delivered. The sender of a message is only responsible for using the correct packaging, providing an accurate address, and applying appropriate postage. The postal service, similar to a MOM system, handles all the issues pertaining to the secure routing and delivery of the message irrespective of the medium used to deliver the message.

 

MOM servers allow heterogeneous systems to exchange messages, but each MOM vendor has a proprietary API for handling and delivering messages. This lack of standardization is unacceptable in the Java technology development paradigm. To take advantage of the already existing infrastructure of MOMs without sacrificing standardization, the J2EE platform offers Java Message Service (JMS). JMS defines the rules for message delivery in Java enterprise systems, and also declares interfaces to facilitate message exchange between application components and MOMs. JMS clients open connections to destinations on the MOM server and then send and receive messages on those destinations. JMS outsources the responsibilities of guaranteed delivery, message notification, message durability, and all of the underlying networking and routing issues to the messaging system. JMS and MOMs work nicely together because they both divide responsibility between message clients and the messaging server.

 

JMS supports two fundamental messaging mechanisms. The first is point-to-point messaging, in which a message is sent by one publisher (sender) and received by one subscriber (receiver). The second is publish-subscribe messaging, in which a message is sent by one or more publishers and received by one or more subscribers. Based on these two messaging mechanisms, we can derive the following messaging patterns:

• One-to-one messaging is a point-to-point model. A message is sent from one JMS client (publisher) to a destination on the server known as a queue. Another JMS client (subscriber) can access the queue and retrieve the message from the server. Multiple messages may reside on the queue, but each message is removed upon retrieval. 
• One-to-many messaging is a publish-subscribe model. A JMS client still publishes a message to a destination on the server, but the destination is now referred to as a topic. The key difference here is that messages placed in a topic include a parameter that defines the message durability (how long it should remain on the server awaiting subscribers). The message will remain on the topic until all subscribers to the topic have retrieved a copy of the message or until its durability has expired, whichever comes first.
• Many-to-many messaging, also a publish-subscribe model, extends one-to-many messaging. In addition to supporting multiple subscribers, this model also supports multiple publishers on the same topic. A good example of many-to-many messaging would be an e-mail listserve: multiple publishers can post messages on a topic, and all subscribers will receive each message.

The type of messaging model you employ depends upon the needs of your enterprise. It is not uncommon to employ more than one messaging strategy within a single enterprise. The structure of a JMS message is fairly intuitive. There is a section for routing, addressing, and message identification; an optional section where application-specific parameters can be passed; and a third section where the message payload (text, bytes, value map, object, etc.) is stored. These three sections are known as the header, property, and body, as illustrated in Figure below.

 

List of Open Source JMS Providers

·         Apache ActiveMQ

·         FUSE Message Broker (enterprise ActiveMQ)

·         OpenJMS

·         JBoss Messaging

·         JORAM, from Objectweb

·         Open Message Queue, from Sun Microsystems

·         Sun Java System Message Queue, from Sun Microsystems, supported version of Open Message Queue     

List of Proprietary JMS Providers

·         Synchrony Messaging from Axway

·         BEA Weblogic, part of the Oracle Fusion Middleware suite

·         Oracle AQ

·         SAP NetWeaver WebAS Java JMS from SAP AG

·         3260 Content Router from Solace Systems

·         SonicMQ from Progress Software

·         TIBCO Software

·         webMethods Broker Server from webMethods

·         WebSphere Application Server from IBM

·         WebSphere MQ from IBM (formerly MQSeries)

·         FioranoMQ