Message-oriented middleware

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 systems 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.

One of the long-standing standards for message oriented middleware is X/Open group's is XATMI specification (Distributed Transaction Processing: The XATMI Specification) which standardizes API for inter-process communications. Known implementations for this API is ATR Baltic's Enduro/X middleware and Oracle's Tuxedo.

Advantages

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

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

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

In a message-based middleware system, the message received at the destination need not be identical to the message originally sent. 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

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

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 approved OASIS[3] and ISO[4] standard that defines the protocol and formats used between participating application components, so implementations are interoperable. AMQP may be used with flexible routing schemes, including common messaging paradigms like point-to-point, fan-out, publish/subscribe, and request-response (note that these are intentionally omitted from v1.0 of the protocol standard itself, but rely on the particular implementation and/or underlying network protocol for routing). 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 MQ Telemetry Transport (MQTT) is an ISO standard (ISO/IEC PRF 20922) supported by the OASIS organization. It provides a lightweight publish/subscribe reliable messaging transport protocol on top of TCP/IP suitable for communication in M2M/IoT contexts where a small code footprint is required and/or network bandwidth is at a premium.

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.[5] The standard provides interfaces to C++, C++11, C, Ada, Java and Ruby.

The eXtensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language). Designed to be extensible, the protocol has also been used for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, Internet of Things applications such as the smart grid, and social networking services. Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license; although many server, client, and library implementations are distributed as free and open-source software, numerous freeware and commercial software implementations also exist. The Internet Engineering Task Force (IETF) formed an XMPP working group in 2002 to formalize the core protocols as an IETF instant messaging and presence technology. The XMPP Working group produced four specifications (RFC 3920, RFC 3921, RFC 3922, RFC 3923), which were approved as Proposed Standards in 2004. In 2011, RFC 3920 and RFC 3921 were superseded by RFC 6120 and RFC 6121 respectively, with RFC 6122 specifying the XMPP address format. In addition to these core protocols standardized at the IETF, the XMPP Standards Foundation (formerly the Jabber Software Foundation) is active in developing open XMPP extensions. XMPP-based software is deployed widely across the Internet, according to the XMPP Standards Foundation, and forms the basis for the Department of Defense (DoD) Unified Capabilities Framework.[6]

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.

One of the long-standing standards for message oriented middleware is X/Open group's is XATMI specification (Distributed Transaction Processing: The XATMI Specification) which standardizes API for inter-process communications. Known implementations for this API is ATR Baltic's Enduro/X middleware and Oracle Tuxedo.

See also

References

  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. ↑ 1.0 Becomes OASIS Standard. AMQP (2012-10-31). Retrieved on 2014-05-23.
  4. ↑ ISO/IEC 19464:2014
  5. ↑ Data Distribution Service for Real-time Systems (DDS), Object Management Group, version 1.2, January 2007
  6. ↑ Archived May 23, 2013, at the Wayback Machine.
  7. ↑ OASIS AMQP version 1.0, sections 2.6.7-2.6.8". OASIS AMQP Technical Committee. Retrieved 18 June 2012.
  8. ↑ Johansson, Leif (April 18, 2005). "XMPP as MOM". Greater NOrdic MIddleware Symposium (GNOMIS). Oslo: University of Stockholm
  9. ↑ STOMP Protocol Specification, Version 1.2, 22 October 2012
  10. ↑ Are You Soft in the Middle? The future of enterprise IT rests in hardware applications
This article is issued from Wikipedia - version of the 11/11/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.