Messaging, a brief review

There are various semantics when the term messaging is used. Such as e-mail, which is primarily used for communication between people, is also referred to as messaging.

The term messaging discussed in this blog space is scoped as follows.

The scope.

Messaging is a communication model. It is usually made possible by a messaging system. A messaging system is commonly referred to as a message oriented middleware (MOM).

A messaging system provides API, messaging agents, and routing services to facilitate software components to create, send, receive, and read messages.

A major characteristic of messaging is to communicate asynchronously. This is in contrast to RPC or RMI style communications.

Software components that communicate with messaging style are usually distributed and loosely coupled. The communication parties (producers and consumers) are not required to be active (running) simultaneously. They are not required to know each other's existence or implementation. And they are not required to use the same communication protocol to send and receive messages.

Messaging can be categorized into two domains. Point-To-Point messaging domain and Publish-and-Subscribe messaging domain.

A destination within the Publish-and-Subscribe messaging domain is called a topic. A destination within the Point-To-Point domain is called a queue.

A topic is a destination from which all the attached subscribers will receive a copy for each message published to it.

A queue is a destination from which only one consumer will receive each message sent to it.

With messaging, software components communicate with each other through a destination. The communication parties only require to know the destination and the format of the message to communicate effectively.


Java Message Service (JMS)

In 1998, Sun and a majority of messaging vendors defined a set of Java API and message routing behavior for the above messaging scope. The JMS messaging service is commonly used by the corporate IT systems.

The JMS messaging service is also commonly used as the back-bone routing service for the Service-Oriented Architecture (SOA) implementation.

Almost all major messaging providers today support and implement the JMS specification.

For JMS, the communication protocols between messaging clients and a messaging provider are vendor dependent. JMS does not define protocols between JMS clients and a messaging provider. The JMS communication protocols are transparent to the applications but are not compatible among messaging providers.


The transition

As the programming environment has moved to the Internet, the messaging model is also evolving. The boundaries between enterprise messaging and the web are often required to be crossed.

Since 1999, there are specifications been developed to address and attempt to resolve messaging issues across the web and corporate boundaries. Such as ebxml messaging service (ebMS), WS-Reliability, and WS-ReliableMessaging . Each of the specification was based on SOAP and defined sophisticated rules for the messaging behavior, reliability, and security requirements.

But the level of complexity and compatibility issues were among the challenges for the mass adoption for these specifications and implementations.

With Software as a Service (SaaS) becomes a reality, the concept of Messaging as a Service (MaaS) is also a part of the transition.

The JMS messaging service are naturally adopted and served as the back-bone routing service for the implementation of a MaaS due to its solid foundation and widely availability.

As of today, the RESTful architectural style has become a popular design choice for the new generation of web services. It is thus a natural transition to present MaaS in a RESTful way. This makes it much simpler to participate in messaging for a web capable software component.

In the mean time, the cloud computing is also gaining its momentum. The combination of MaaS and cloud seems to be a good fit. The messaging in the cloud development is on-going. The pay-per-use messaging concept is becoming an alternative option to corporate IT and start-ups.