Editing Message-oriented middleware (section)

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