Message-oriented middleware

From Wikipedia, the free encyclopedia
  (Redirected from Message Oriented Middleware)
Jump to: navigation, search
This article has multiple issues. Please help improve it or discuss these issues on the talk page.
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2009)
This article may require cleanup to meet Wikipedia's quality standards. No cleanup reason has been specified. Please help improve this if you can. (November 2007)
Gnome-searchtool.svg
 This article's factual accuracy is disputed. Please help to ensure that disputed statements are reliably sourced. See the relevant discussion on the talk page. (June 2012)
It has been suggested that this article be merged into Middleware (distributed applications). (Discuss) Proposed since September 2010.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating system and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.[1]

MOM provides software elements that reside in all communicating components of a client/server architecture and typically support asynchronous calls between the client and server applications. MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism.

Contents

Advantages[edit]

Central reasons for using a message-based communications protocol include its ability to store (buffer), route, or transform messages while conveying them from senders to receivers.

Asynchronicity[edit]

MOM comprises a category of inter-application communication software that generally relies on asynchronous message-passing, as opposed to a request-response architecture. In asynchronous systems, message queues provide temporary storage when the destination program is busy or not connected. In addition, most asynchronous MOM systems provide persistent storage to back up the message queue. This means that the sender and receiver do not need to connect to the network at the same time (asynchronous delivery), and problems with intermittent connectivity are solved. 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 queue for later processing when the receiver restarts.

Routing[edit]

Many message-oriented middleware implementations depend on a message queue system. Some implementations permit routing logic to be provided by the messaging layer itself, while others depend on client applications to provide routing information or allow for a mix of both paradigms. Some implementations make use of broadcast or multicast distribution paradigms.

Transformation[edit]

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.[2] 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.

Disadvantages[edit]

The primary disadvantage of many message oriented middleware systems is that they require an extra component in the architecture, the message transfer agent (message broker). 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 to a message 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.

Standards[edit]

Historically, there was a lack of standards governing the use of message-oriented middleware that has caused problems. Most of the major vendors have their own implementations, each with its own application programming interface (API) and management tools.

The Advanced Message Queuing Protocol (AMQP) is an emerging standard that defines the protocol and formats used in the messaging server and client, so implementations are interoperable. AMQP is defined to provide flexible routing, including common messaging paradigms like point-to-point, fanout, publish/subscribe, and request-response. It also supports transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support. Java applications that use AMQP are typically written in Java JMS. Other implementations provide APIs for C#, C++, PHP, Python, Ruby, and other languages.

The Object Management Group's Data Distribution Service (DDS) provides message-oriented Publish/Subscribe (P/S) middleware standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers.[3] The standard provides interfaces to C++, C++11, C, Ada, Java and Ruby.

The Java EE programming environment provides a standard API called JMS (Java Message Service), which is implemented by most MOM vendors and aims to hide the particular MOM API implementations; however, JMS does not define the format of the messages that are exchanged, so JMS systems are not interoperable.

A similar effort is with the actively evolving OpenMAMA project, which aims to provide a common API, particularly to C clients. However, at the moment (August 2012) it is primarily appropriate for distributing market-oriented data (e.g. stock quotes) over pub-sub middleware.

Trends[edit]

See also[edit]

References[edit]

  1. ^ Curry, Edward. 2004. "Message-Oriented Middleware". In Middleware for Communications, ed. Qusay H Mahmoud, 1-28. Chichester, England: John Wiley and Sons. doi:10.1002/0470862084.ch1. ISBN 978-0-470-86206-3
  2. ^ E. Curry, D. Chambers, and G. Lyons, "Extending Message-Oriented Middleware using Interception", presented at Third International Workshop on Distributed Event-Based Systems (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004.
  3. ^ Data Distribution Service for Real-time Systems (DDS), Object Management Group, version 1.2, January 2007
  4. ^ OASIS AMQP version 1.0, sections 2.6.7-2.6.8". OASIS AMQP Technical Committee. Retrieved 18 June 2012.
  5. ^ Johansson, Leif (April 18, 2005). "XMPP as MOM". Greater NOrdic MIddleware Symposium (GNOMIS). Oslo: University of Stockholm
  6. ^ STOMP Protocol Specification, Version 1.2, 22 October 2012, {http://stomp.github.com//stomp-specification-1.2.html}
  7. ^ Are You Soft in the Middle? The future of enterprise IT rests in hardware applications
Retrieved from "http://en.wikipedia.org/w/index.php?title=Message-oriented_middleware&oldid=560435640"