Message broker's goals.

Transparent cooperation of heterogeneous systems.

When two applications A and B communicate ,the message broker converts the messages' data formats so that they are perceived as native by each application. Numbers, character chains, structures, etc. are perceived by application A in the same language format as application A is written in and on the same operating system. The same is true for B.

Communications are transparent whatever the operating systems and programming languages. The Message broker controls that the data type used by A can be converted to a type identified by B.

Furthermore communication through messages enables to build tailor-made APIs: A and B agree to the same message format. A does not have to respect an imposed format in the same way as a client has to when calling a service in the lower levels of the operating systems or DBMS.A message broker simplifies the communication for heterogeneous systems, hiding everybody's technical details.

A message broker offers, of course, a message dispatching services over a standard protocol, such as TCP/IP or Named Pipes, its complexity also being hidden.

Dynamic application environment

In the event of a change of server or network, the middleware enables an application to move from one system to another without changing the program, only the network addresses change. OpenMOM adds an additional degree of liberty : the dynamic routing. Services can be changed or added at any time with no downtime to the application. Consequently, companies who continuously alter their applications to remain competitive can do so in real-time.

This feature permits OpenMOM to choose dynamically the path followed by a message.

OpenMOM automatically forwards the message to the most available service.

Clients and services do not need to be hard-wired or pre-programmed to communicate. OpenMOM automatically connects the requestor to the necessary service, without developer intervention.

In the event of a server breakdown, OpenMOM can dispatch a message to another backup server.

Flexibility and reliability

A synchronous application architecture cannot operate if one component is not available. With a message broker , persistent messages wait for the program to become available. This functionality presents a number of advantages :

Flexibility : a program that doesn't need an immediate answer, can send its message whenever it wants, independently of the recipient's availability.. Senders and recipients are independent and thus unattached.

Reliability : a persistent message is never lost. A program can send several messages at the same time in parallel.

Load balancing : a server program processes the messages in the queue as soon as possible.

Scalability

When the process volume increases, for example when the number of users rises, the application architecture must support this additional charge without any modification.

Two features address the scalability requirements :

-dynamic routing (explained in a previous section) : allows to start as many servers, offering the same service , as required.

-multiplexing : This function enables several programs to share a message queue. It is the same kind of multiplexing that you get with a transaction processing monitor placed between a DBMS and its clients, which allows the DBMS to perform successively during TPC-C benchmarks on UNIX and on mainframes. Thanks to multiplexing, the DBMS and its operating system handle fewer processes and connections than the real number of clients.

It is important to underline that a message broker is a high-performing communication tool:

-supports important volumes : several hundreds of messages per second on a local network, corresponding to several hundreds of thousands of octets per second; optimized communication initialization and message transfer.

-optimal use of system resources; the message broker uses only one socket session as long as needed and multiplexes many asynchronous communications with the same session.

-small footprint : the message broker is simple and consumes less system and network resources than a DBMS Client/server middleware.

Optimized network usage

Once a program has sent its messages, it doesn't need to stay connected and wait for the answers. This represents dramatic savings in telephone bills.

The load balancing facility generates highly available message queues and allows an effective peak-hours network management. In this configuration , a low-bandwidth network might be satisfactory, whereas it would have collapsed in a synchronous system.

You can easily build an application architecture where the resources are closer to the users who need them and thereby reduce the network load.

Simplified implementation

The message broker, i.e., a high-performing and solid communication infrastructure, simplifies significantly the development of distributed applications.

The OpenMOM product line is extremely easy to learn and use:

* Simple functional model
* About twenty functions
* Hardly any sources for bugs and a straightforward debugging
* Administration with an intuitive graphic user interface.