Message-oriented middleware
From Wikipedia, the free encyclopedia
 |
This article may require cleanup to meet Wikipedia's quality standards. Please discuss this issue on the talk page or replace this tag with a more specific message. This article has been tagged since December 2005. |
Message-oriented middleware comprises a category of inter-application communication software that generally relies on asynchronous message-passing as opposed to a request/response metaphor.
Most message-oriented middleware (MOM) depends on a message queue system, although some implementations rely on broadcast or on multicast messaging systems.
Contents |
[edit] Origins
Middleware arrived on the computing landscape comparatively late. It emerged in the 1980s as a solution to the problem of how to link new applications to older legacy systems. It also facilitated distributed processing – the connection of multiple applications together to create a larger application, usually over a network.
[edit] A requirements fable
The case of a large High Street bank provides a good example of how middleware emerged as a business requirement:
The bank had stored all its customer details on its large mainframe since the 1960s. This mainframe remained in heavy use and underwent several upgrades.
Although ground-breaking in its day, the mainframe's usefulness to the bank’s staff diminished as the bank introduced new, separate applications based on personal computers (PCs), allowing the bank’s staff to offer customers new services that the mainframe could not support.
An ideal situation would allow the PC-based application to link to the older mainframe application and allow the mainframe and the PCs to share each others' data. Accessing the mainframe’s data offers two advantages:
- new front-end PC applications can replace the old user-unfriendly mainframe terminals
- PC-based systems can use the data from the mainframe in new ways — previously impracticable due to the constraints of the mainframe’s software
Up until the late 1980s systems builders had no easy way to link these different applications together. Developers faced several challenges:
- the developers would have to construct a separate software ‘adapter’ on both systems to translate data from source applications into a format that the destination system could understand (and vice versa).
- the processing speed of each system would constrain the other system. For example, if the mainframe ran slowly, the PC-based application would have to wait until the mainframe caught up, thereby slowing down the PC application.
- communications programmers would need to install a network gateway system to form a bridge between the mainframe’s network and the PC network if the different systems used different network protocols. The gateway would translate the network packets from the source system and pass them on to the destination system using the destination system’s protocol.
Such issues made integration between applications difficult. Much of such integration also required re-engineering every time two applications on disparate platforms needed linking together, as every situation differed to some extent. By devoting effort to linking together applications on different systems, IT departments started to spend nine or ten times the amount spent on original development per sub-system.
Developers apparently needed a separate piece of software that would literally sit in the middle of two or more applications and would handle all the ‘plumbing’ between the two systems. Such software needed the intelligence to handle different platforms, different programming languages, various network protocols and diverse hardware. Developers allegedly wanted to remove themselves from the complexities of the underlying computing infrastructure so that they could focus on functionality within actual applications.
Towards the end of the 1980s middleware began to emerge which attempted to address these issues. Initial middleware offerings addressed specific handfuls of platforms or languages and thus had limited usefulness. Over time, however, middleware products have become more and more advanced, supporting multiple platforms, languages and protocols.
The ability of middleware to link together disparate systems across a heterogeneous network environment offers only one example of the benefits of this dominant technology. Middleware as of 2006 provides a whole raft of new functionality that augments and enhances the existing applications that it interconnects.
[edit] Advantages
The primary advantage of a message-based communications protocol lies in its ability to store, route or transform messages in the process of delivery.
[edit] Storage
Most MOM systems provide persistent storage to back up the message transfer medium. This means that the sender and receiver do not need to connect to the network at the same time (asynchronous delivery). This becomes particularly useful when dealing with intermittent connections, such as unreliable networks, casual users or timed connections. It also means that should the receiver application fail for any reason, the senders can continue unaffected, as the messages they send will simply accumulate in the message store for later processing when the receiver restarts.
[edit] Routing
MOM delivers another important advantage through its ability to route messages within the middleware layer itself. Taking things a step further, middleware messaging can deliver a single message to more than one recipient (broadcast or multicast).
[edit] Transformation
In a message-based middleware system, the recipient's message need not replicate the sender's message exactly. A MOM system with built-in intelligence can transform messages en-route to match the requirements of the sender or of the recipient. In conjunction with the routing and broadcast/multicast facilities, one application can send a message in its own native format, and two or more other applications may each receive a copy of the message in their own native format. Many modern MOM systems provide sophisticated message transformation (or mapping) tools which allow programmers to specify transformation rules applicable to a simple GUI drag-and-drop operation.
[edit] Disadvantages
The primary disadvantage of message oriented middleware stems from its requiring an extra component in the architecture, the message transfer agent. As with any system, adding another component can lead to reductions in performance and reliability, and can also make the system as a whole more difficult and expensive to maintain.
In addition, many inter-application communications have an intrinsically synchronous aspect, with the sender specifically wanting to wait for a reply before continuing (see real-time computing and near-real-time for extreme cases). Because message-based communication inherently functions asynchronously, it may not fit well in such situations. That said, most MOM systems have facilities to group a request and a response as a single pseudo-synchronous transaction.
[edit] Lack of standards
The lack of standards governing the use of message oriented middleware has caused problems. All the major vendors have their own implementations, each with its own application programming interface (API) and management tools.
The Java EE programming environment provides a standard API called JMS (Java Message Service), implemented by the most of MOM vendors and aiming to hide the particular MOM implementations. Microsoft doesn't support JMS.
[edit] Trends
The Advanced Message Queuing Protocol (AMQP) is an attempt to define behavior of the messaging server and client such that implementations are truly interoperable. The flexibility of this protocol to define installations with point to point messaging (e.g. WebSphere MQ), publish/subscribe messaging (e.g. TIBCO Rendezvous) or combinations of both is extremely powerful and may become the standard that is needed in this domain. The protocols which can be claimed to be a standard that are used for Message-oriented middleware include XMPP and Streaming_Text_Orientated_Messaging_Protocol.
