Editing Message-oriented middleware

{{Short description|Type of software or hardware infrastructure}}
{{Multiple issues|
{{more citations needed|date=March 2009}}
{{disputed|date=June 2012}}
}}

'''Message-oriented middleware''' ('''MOM''') is software or hardware infrastructure supporting sending and receiving messages between distributed systems. Message-oriented middleware is in contrast to [[streaming-oriented middleware]] where data is communicated as a sequence of bytes with no explicit message boundaries. Note that streaming protocols are almost always built above protocols using discrete messages such as frames ([[Ethernet frame|Ethernet]]), datagrams ([[User Datagram Protocol|UDP]]), packets ([[Internet Protocol|IP]]), cells ([[Asynchronous Transfer Mode|ATM]]), et al. 

MOM allows [[modular programming|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. Application programming interfaces ([[API]]s) that extend across diverse platforms and networks are typically provided by MOM.<ref>{{Cite Book|author=Curry, Edward |date=2004 |url=https://www.wiley.com/en-us/Middleware+for+Communications-p-9780470862063 |title=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}}</ref>

This middleware layer allows software components (applications, servlets, and other components) that have been developed independently and that run on different networked platforms to interact with one another. Applications distributed on different network nodes use the application interface to communicate. In addition, by providing an administrative interface, this new, virtual system of interconnected applications can be made fault tolerant and secure.<ref name="oracle">{{Cite book|title=Message Oriented Middleware |url=http://docs.oracle.com/cd/E19340-01/820-6424/aeraq/}}</ref>

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.

==Middleware categories==
*[[Remote procedure call]] or RPC-based middleware
*[[Object request broker]] or ORB-based middleware<ref name="CORBA">{{Cite book|title=Common Object Request Broker Architecture |url=https://www.omg.org/spec/CORBA/}}</ref>
*[[Message-oriented middleware]] or MOM-based middleware

All these models make it possible for one software component to affect the behavior of another component over a network. They are different in that RPC- and ORB-based middleware create systems of tightly coupled components, whereas MOM-based systems allow for a [[loose coupling]] of components. In an RPC- or ORB-based system, when one procedure calls another, it must wait for the called procedure to return before it can do anything else. In these mostly [[synchronous messaging]] models, the middleware functions partly as a super-linker, locating the called procedure on a network and using network services to pass function or method parameters to the procedure and then to return results.<ref name=oracle/> Note that [[Object request broker]]s also support fully [[asynchronous messaging]] via oneway invocations.<ref name=CORBA/>

==Advantages==
Central reasons for using a message-based communications [[protocol (computing)|protocol]] include its ability to store (buffer), route, or transform [[message]]s while conveying them from senders to receivers.

Another advantage of messaging provider mediated messaging between clients is that by adding an administrative interface, you can monitor and tune performance. Client applications are thus effectively relieved of every problem except that of sending, receiving, and processing messages. It is up to the code that implements the MOM system and up to the administrator to resolve issues like interoperability, reliability, security, scalability, and performance.

===Asynchronicity===
Using a MOM system, a client makes an API call to send a message to a destination managed by the provider. The call invokes provider services to route and deliver the message. Once it has sent the message, the client can continue to do other work, confident that the provider retains the message until a receiving client retrieves it. The message-based model, coupled with the mediation of the provider, makes it possible to create a system of loosely coupled components.

MOM comprises a category of inter-[[application software|application]] [[communication software]] that generally relies on [[wikt:asynchronous|asynchronous]] [[message passing|message-passing]], as opposed to a [[request-response]] architecture. In asynchronous systems, [[message queue]]s provide temporary storage when the destination program is busy or not connected. In addition, most asynchronous MOM systems provide [[persistent storage]] to [[backup|back up]] the message queue. This means that the sender and receiver do not need to connect to the network at the same time ([[asynchrony (computing)|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 [[Broadcasting (networking)|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 [[Data transformation|transform]] messages and route to match the requirements of the sender or of the recipient.<ref name="MOM">{{Cite web|url=http://www.edwardcurry.org/web_publications/curry_DEBS_04.pdf|title=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.|access-date=2011-08-09|archive-url=https://web.archive.org/web/20110726015301/http://www.edwardcurry.org/web_publications/curry_DEBS_04.pdf|archive-date=2011-07-26|url-status=dead}}</ref> 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 [[software developer|programmer]]s to specify transformation rules applicable to a simple [[graphical user interface|GUI]] [[drag-and-drop]] operation.

==Disadvantages==
The primary disadvantage of many message-oriented middleware systems is that they require an extra component in the [[software architecture|architecture]], the message transfer agent ([[message broker]]). As with any [[system]], adding another component can lead to reductions in [[computer performance|performance]] and reliability, and can also make the system as a whole more difficult and expensive to [[software maintenance|maintain]].

In addition, many inter-application communications have an intrinsically [[Synchronization (computer science)|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|near-real-time]] for extreme cases). Because message-based [[data communication|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.

With a synchronous messaging system, the calling function does not return until the called function has finished its task. In a [[loose coupling|loosely coupled]] asynchronous system, the calling client can continue to load work upon the recipient until the resources needed to handle this work are depleted and the called component fails. Of course, these conditions can be minimized or avoided by monitoring performance and adjusting message flow, but this is work that is not needed with a synchronous messaging system. The important thing is to understand the advantages and liabilities of each kind of system. Each system is appropriate for different kinds of tasks. Sometimes, a combination of the two kinds of systems is required to obtain the desired behavior.

==Standards==
Historically, there was a lack of [[standardization|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.

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

The [[Advanced Message Queuing Protocol]] (AMQP) is an approved [[OASIS (organization)|OASIS]]<ref>[http://www.amqp.org/node/102 1.0 Becomes OASIS Standard]. AMQP (2012-10-31). Retrieved on 2014-05-23.</ref> and ISO<ref>{{Cite web|url=http://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/06/49/64955.html|title=ISO/IEC 19464:2014|website=ISO}}</ref> 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 pattern|messaging paradigms]] like [[Point-to-point (telecommunications)|point-to-point]], [[Fan-out (software)|fan-out]], [[publish/subscribe]], and [[request-response]] (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 (programming language)|Java]] JMS. Other implementations provide APIs for [[C Sharp (programming language)|C#]], [[C++]], [[PHP]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]], and other [[programming language]]s.

The [[High Level Architecture]] (HLA IEEE 1516) is an [[Institute of Electrical and Electronics Engineers]] (IEEE) and [[Simulation Interoperability Standards Organization]] (SISO) standard for simulation interoperability. It defines a set of services, provided through an API in C++ or Java. The services offer publish/subscribe based information exchange, based on a modular Federation Object Model. There are also services for coordinated data exchange and time advance, based on logical simulation time, as well as synchronization points. Additional services provide transfer of ownership, data distribution optimizations and monitoring and management of participating Federates (systems).

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 pattern|Publish/Subscribe]] (P/S) middleware standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers.<ref>Data Distribution Service for Real-time Systems (DDS), Object Management Group, version 1.2, January 2007</ref> The standard provides interfaces to C++, C++11, C, [[Ada (programming language)|Ada]], Java, and Ruby.

=== XMPP ===
The eXtensible Messaging and Presence Protocol ([[XMPP]]) is a communications protocol for message-oriented middleware based on Extensible Markup Language ([[XML]]). 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]], many freeware and proprietary 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 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.<ref>[http://www.disa.mil/Services/Network-Services/UCCO/~/media/Files/DISA/Services/UCCO/UCR2013/01_Framework_2013.pdf] {{webarchive|url=https://web.archive.org/web/20130523040719/http://www.disa.mil/Services/Network-Services/UCCO/~/media/Files/DISA/Services/UCCO/UCR2013/01_Framework_2013.pdf|date=May 23, 2013}}</ref>

The [[Java EE]] programming environment provides a standard API called [[Java Message Service]] (JMS), 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, especially to C clients. As of August 2012, it is mainly appropriate for distributing market-oriented data (e.g. stock quotes) over pub-sub middleware.

==Message queuing==
{{see also|Message queuing service}}
[[Message queue]]s allow the exchange of information between distributed applications. A message queue can reside in memory or disk storage. Messages stay in the queue until the time they are processed by a service consumer. Through the message queue, the application can be implemented independently - they do not need to know each other's position, or continue to implement procedures to remove the need for waiting to receive this message.<ref name="tutorialsto">{{Cite web|url=https://itgix.com/blog/mq-introduction-to-message-oriented-middleware-and-ibm-mq/|title=MQ – Introduction to Message Oriented Middleware and IBM MQ|website=itgix.com|date=2018-08-30}}</ref>

==Trends==
* [[Advanced Message Queuing Protocol]] (AMQP) provides an open standard application layer protocol for message-oriented middleware.<ref>OASIS AMQP version 1.0, sections 2.6.7-2.6.8". OASIS AMQP Technical Committee. Retrieved 18 June 2012.</ref>
* The [[Object Management Group]]'s [[Data Distribution Service]] (DDS) has added many new standards to the basic DDS specification. See [https://web.archive.org/web/20130202055113/http://www.omg.org/technology/documents/dds_spec_catalog.htm Catalog of OMG Data Distribution Service (DDS) Specifications] for more details.
* The [[Object Management Group]]'s [[Common Object Request Broker Architecture]] (CORBA) has added many new standards recently including a new language mapping to [[C#]] and an update to the IDL to C++ mapping specification to support the latest updates to the [[C++]] language standards. See [https://www.omg.org/spec/category/corba-platform Catalog of OMG CORBA Specifications] for more details.
* [[Extensible Messaging and Presence Protocol]] (XMPP) is a communications protocol for message-oriented middleware based on Extensible Markup Language (XML).<ref>Johansson, Leif (April 18, 2005). "XMPP as MOM". Greater NOrdic MIddleware Symposium (GNOMIS). Oslo: University of Stockholm</ref>
* [[Streaming Text Oriented Messaging Protocol]] (STOMP), formerly named TTMP, is a simple text-based protocol, provides an interoperable wire format that allows STOMP clients to talk with any Message Broker supporting the protocol.<ref>{{Cite web|url=https://stomp.github.io/stomp-specification-1.2.html |title=STOMP Protocol Specification, Version 1.2 |date=22 October 2012 |website=stomp.github.io}}</ref>
* An added trend sees message-oriented middleware functions being implemented in hardware, usually in a [[field-programmable gate array]] (FPGA), [[application-specific integrated circuit]] (ASIC), or other specialized silicon chip.<ref>[http://advice.cio.com/ralph_frankel/are_you_soft_in_the_middle_the_future_of_enterprise_it_rests_in_hardware_applications?commentpage=1 Are You Soft in the Middle? The future of enterprise IT rests in hardware applications] {{webarchive|url=https://web.archive.org/web/20090209044943/http://advice.cio.com/ralph_frankel/are_you_soft_in_the_middle_the_future_of_enterprise_it_rests_in_hardware_applications?commentpage=1 |date=2009-02-09}}</ref>
<ref>
[https://www.ois.com/index.php/orbexpress-fpga/ ORB''express'' for Field Programmable on Gate Arrays] ([[FPGA]])</ref>

==See also==
* ''[[Enterprise Integration Patterns]]'' (book)
* [[Enterprise messaging system]]
* [[Enterprise service bus]]
* [[Flow-based programming]]
* [[Event-driven architecture]]

==References==
{{Reflist}}

== External links ==
* {{Cite book|title=IBM MQ Developer Essentials |url=https://developer.ibm.com/series/badge-ibm-mq-developer-essentials/}}
* {{Cite book|title=ORBexpress: An Overview |url=https://www.ois.com/index.php/communications-middleware/}}
{{Navbox
|title = [[Message-oriented middleware]]
|state = {{{state|<noinclude>uncollapsed</noinclude>}}}
|listclass = hlist

|list1 =
*[[Apache ActiveMQ]]
*[[Apache Camel]]
*[[Apache Kafka]]
*[[Apache Qpid]]
*[[ORBexpress]]
*[[Open Message Queue]]
*[[RabbitMQ]]
*[[ZeroMQ]]
*''[[:Category:Message-oriented middleware|more]]''...

|name = Message-oriented middleware
}}

[[Category:Message-oriented middleware| ]]
[[Category:Enterprise application integration]]
[[Category:Middleware]]
[[Category:Systems engineering]]