message oriented middleware (MOM)
Message Oriented Middleware (MOM) is the basis for asynchronous communication between client and server in a distributed application. This form of communication contrasts with when the client and server are in direct and simultaneous - i.e. synchronous - contact with each other and can therefore block each other in the same way.
MOM is therefore also referred to as a loose coupling between the participants. The MOM server takes over the management of the asynchronous messages, usually in the form of a queue. This allows the receiver to pick up the messages from this queue at any time.
The central consideration of a MOM server is the independent switching of messages. This gives a MOM server an advantage over classical distributed systems based on Remote Procedure Call( RPC). Through services such as message bundling, an increase in message exchange performance is achievable. Message Oriented Middleware thus offers a concept for the exchange of messages independent of programming languages and platforms. However, programming interfaces( API) exist for different programming languages, for example the Java Message Service( JMS).
The architecture of Message Oriented Middleware
_en.png)
The figure illustrates the basic architecture of Message Oriented Middleware, a very popular model for the development of distributed systems.
It is based on a message-oriented model that organizes the asynchronous exchange of messages between different processes. The following terms are often used for this concept: Messaging, Message Queuing, Message Oriented Middleware (MOM). As a rule, the technique of queues is used:
- The sender places a message in the queue of the receiver.
- The sender and receiver always act independently of each other.
- The sender continues to act without being aware of the status of its message.
- The receiver fetches the message from its queue at any time.
The components of the Message Oriented Middleware
Central component in the shown architecture is the administrator of the queue, also called manager or provider. This is responsible for the classification of the messages into the queues of the receivers, the notification of the receivers, the initialization and control of the queues and for the access interfaces and the transmission protocol.
In addition to the asynchronous mode already mentioned, a Message Oriented Middleware should have the following additional features: The coupling of the components should be loose, since only in such a way no component has the reference for another, and the components are not only distributed but have also a different status regarding their availability - see for example applications on laptops, cell phones etc..
For the asynchronous transmission of messages there are still the following additions to the MOM model
Request-Reply model See the figure for this. Here, the basically asynchronous infrastructure is used to simulate synchronous communication. This means that the sender remains blocked until it has received the reply message. Both the variant with temporary queues for response messages and that so-called identifiers mark related messages are possible, whereby a queue can then also support several parallel connections. Both possibilities lead in any case to a closer coupling.
Publish-Subscribe Model The publish-subscribe model is shown in the figure. In this model, a system of subscribers is implemented. Here, a publisher publishes news about a topic, which is subscribed to by a subscriber and distributed by the broker. Typical applications of this model are stock exchange services or RSS feeds.