Why do you need a message broker ?

Distributed applications are a business reality and introduce new challenges :

- accessing to remote data and processes through an intranet and Internet network

- building applications involving multiple servers and clients

- Simultaneous acces to heterogeneous information (RDBMS, ODBMS, Legacy DB)

...
The Client/Server architecture has partially addressed these issues by moving the user interface on the client side; but a simple remote program call still requires a lot of manipulation in data conversion, localization and security services.

The purpose was to resolve all the interoperability issues with a single software solution but this is still to be demonstrated without generating complicated scenarii.

Using ORBs or RPCs, the communication between two programs is mostly handled by a communication channel using synchronous protocols. However , the high cost of maintaining a permanent session over a telephone line as well as the protocols reliability are challenging this way of operating.

Today, the message broker technology, based on a communication architecture handling asynchronous messages, offers to the business community a safer and simpler solution to address these critical issues.

Principles and functions of a message broker

Application services, functions and events

An OpenMOM service provides functional capacities associated with specific events. For example, the stock management service offers a particular process for each event such as "Stock output" or "Supplier order", just to name a few.

Usually a message targets a given event of a given service:
its arrival triggers the execution of the corresponding function.

Message Queuing

The message, sent by an application A to an application B of the stock management service, is available for application B in a queue or "mailbox" managed by the message broker. This queue is event-specific to keep the stock input separated from the stock output.

With OpenMOM, the application B is automatically notified of the arrival of a message allocated to one of its functions ( when the server runs in an operating system supporting events such as Windows 3.x, Windows 95, Windows NT or UNIX). If the application B runs on a system unable to notify such an event, it will use the polling option from the message broker. The application B can examine the messages in the queue without a prior extraction. Then , the application B can answer to application by sending a message to one of application A's event queues.

Asynchronous and synchronous

The asynchronism of OpenMOM enables applications A and B :
To send one or more messages :

Integrity of a messaging service

Depending on your preference, OpenMOM can guarantee:

-a message arrival (once and only once), even if its addressee is not available at the time of the dispatching.

-the same relative position of the messages to a specific destination, originating from a specific source, than the departure position of this source;

-the delivery of a receiptÕs acknowledgment, once and only once, if requested.
The persistent message technique allow these guarantees to be valid even if the system or the network shuts down, or if an addressee is unavailable.