White Paper

____________________________________________________
TABLE OF CONTENTS

Introduction

Message Brokers

OpenMOM: how does it work?

OpenMOM: how to use it

OpenMOM: features summary

____________________________________________________
Introduction

Message Brokers represent the most flexible type of inter-application communication architecture today: they simplify the logical connections among multiple application systems.  

A message broker is a value-added, application-to-application middleware service, composed of one or more software facilities, and capable of one-to-many, many-to-one and many-to-many message distribution. A message broker is an architectural concept, a way of using middleware, rather than an off-the-shelf product.

Message brokers are logical entities, distinct from senders and receivers, that coordinate message distribution. By formalizing and making inter-application links explicit, message brokers provide a logical place to implement a variety of value-added services such as message transformation (a type of translation).

Compared to a more traditional synchronous approach, such as Client/Server software solutions, OpenMOM offers unique features :  

	Transparent communication across operating systems and languages.
	Dynamic definition of your correspondents.
	Flexible approach : you move your application across systems with no interruption.
	Ease of use : An application can send a message regardless of the receiver's availability or of a session’s initialization.
	Asynchronous messaging facility (no locked-up client).
	Optional synchronous facility ( fast RPC mechanism)
	Seamless communication between objects.
	Performance : Parallel servers and services with dynamic load balancing.
	Multiplexing of server and network communication requests.
	Automatic message queuing facility for ad-hoc requests.
	Fast transfer of important volumes of messages.
	Small software footprint.
	Stability : The server guarantees the delivery and integrity of messages ,independently of the system or network availability.
	Openness : Supports the major network protocols and development languages.
	Straightforward implementation : OpenMOM requires little training, programming and administration.

This document will cover all these items in great details.

____________________________________________________
Message Brokers

 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 :

---

---

---

---

---

To reply or not to a received message,
To talk and to listen at the same time,
To obtain an acknowledgment of receipt from the message in the addressee's queue, with the time of reception (this queuing does not imply, however, that the addressee has already or will read his mail box).

OpenMOM also supports synchronous messaging , including answers’ monitoring.

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.

 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.

____________________________________________________
OpenMOM: how does it work?

  Communication broker

The OpenMOM's architecture , based on asynchronous communication, relies on a message broker. The message broker provides communication and interoperability services to applications. These applications are not restricted to interact only with the message broker and can participate, at the same time, to a traditional client/server architecture.

Application, Service and Function

A broker manages communications with a group of applications called services, such as a stock management service or an order management service. A service publishes and subscribes messages to a broker for multiple functions , each of them associated with a specific event. For example , the stock management service will provide a specific processing for each event such as stock input, stock output or order to supplier. An event is expressed with the reception of a message in the mail box.

An application registers its service to all the OpenMOM brokers that it plans to use.

A session links a service to a connection (that is, a OpenMOM broker and the information for reaching it). Session parameters can be set to determine what the session can do. For example, a session can be made to re-establish a connection when the connection is no longer being used, without the user intervening at all.
The session is then restored with the same server, not necessarily using the same path, or with another server, if "spare" servers have been named

A service declaration is dynamic, and can be modified. As soon as a service connects to an OpenMOM broker, its interface becomes visible for the other services, which can then use it. A service is identified by a name, user, machine, type, and the set of events it can process. The activation of a service can be controlled by modifying its status. As opposed to CORBA or COM, OpenMOM does not limit the services to what is created during the development phase of the application.

An application has access to remote functionality, picked up in real time: this is a software "plug and play" approach.

Similarly, an end-user program can dynamically select the application service of its choice.

Registering an application with multiple brokers allows to:  

	Optimize the message transfer by selecting the closest broker.
	Take advantage of multiple routes to be protected from network failures.

Local services and filters

A service is local if its application is linked (at run time) to the OpenMOM communication's broker. The OpenMOM broker is the main program, in which case the local services will be DLLs. A service linked to a message broker must be compiled in multithread (thread-safe) mode.

OpenMOM brokers are fully adaptable programs whose action can be modified dynamically, and whose execution can be monitored. An OpenMOM broker manages each client access on an independent thread, which can include event-triggered calls to external functions (provided in DLLs). This is called reflex triggering. Reflexes are of use when connecting services (for example for protecting access to a server with passwords, spying on accesses, and so forth). But they can also be triggered when a message arrives (any message, or specific messages determined by selection criteria) to run other actions, act on the message, allow it or keep it from being processed, routing it to another destination, converting it, having it processed by another communication program, or the like.
One type of reflex is the local service. These are special reflexes that can be viewed as actual services. They can process messages reaching the brokers, and return a reply to the sender. In such a case, the message processing is synchronous. Filters are another type of reflex. They return a value that will interrupt a process.

When a service connects to a broker, the corresponding reflexes are triggered. The service that is trying to connect can associate a message with its connect request. It is the reflex that interprets the data contained in this message (a password, for example). The value returned by the filter reflex will determine whether or not the processing will be continued (connection refused or accepted). A list of filters can be declared for each service. These filters will be run in a sequence, and the first that returns a zero will reject the connect request.

When a message arrives on a broker, the reflexes associated with the message are triggered. Since the message is sent through the address to the reflex functions, it can be modified (to change its destination, content, and so forth). If the reflex is a filter, its result will decide whether or not the processing will continue. A list of filters can be declared for each local service. These filters will be run in a sequence, and the first that returns a zero will reject the connect request (the message will not be mailed, and the following reflexes will not be triggered).

Since the action of OpenMOM brokers is entirely configurable, it is important to distinguish them clearly from one another. Beside from the brokers name, there also exists a Role property to make the server easier to identify. This property is an integer value which you can give any meaning you wish. You may decide, for example, that all your Role 1 brokers are "main" brokers, Role 2 servers are backup brokers, and so forth.

Reflexes are meant to be run concurrently on different threads, and so should be written to support this (Multi-Thread safe). A specific prototype also has to be used for each type of reflex. A specific configuration file declaring the available reflexes can be associated with each OpenMOM broker.

Examples of useful reflexes:

	Access control
	Alert callbacks to clients when a message arrives
	Compression-decompression
	Activity surveillance
	Encryption-decryption
	Customized load balancing
	Routing

 An application Service can also act as a main program and the OpenMOM broker becomes a sub-program dynamically linked to the application : on Windows, OpenMOM broker will be handled as a DLL.

Remote services

A service is remote if its application is located in a different machine than the one supporting the OpenMOM broker.

OpenMOM network Topology

Multi-brokers, Multi-protocols

	The OpenMOM architecture can operate with one or many message broker.
	OpenMOM can forward messages in a Multi-protocols' network.

Dynamic routing

A OpenMOM proxy is a service, provided under three different forms:  

	Broker proxy, routing broker-to-broker messages.
	Service proxy, routing service-to-service messages.
	Event proxy, routing service’s event-to service’s event messages.

Dynamic routing addresses two important needs:  

	Load balancing (equivalent services on different broker)
	Fail-over protection (different paths to access the same service)

Dynamic routing is an optional feature: you can specify an explicit path for a message.

OpenMOM messages

OpenMOM messages are used for transferring data (up to 2 GB for the object encapsulated in a message) among services. The services concerned may be performed on different machines or different operating systems, and may have been developed in different languages. No special development effort is needed to convert, encode, or decode the data transmitted by a message. This data may be of simple, structured types, or arrays. They will be converted by OpenMOM. And, when a service receives a message, an automatic check is made between the data expected and the data received.

When a message is sent, the profile of a set of destination services is stipulated. This profile may designate a single, identified service, but it may also represent a set of services corresponding to given criteria.

When a message reaches a server, a copy of it is sent to each service that might be able to process it. The original message has a property determining the maximum number of copies that can be processed (i.e. mailed and delivered to the addressee). The original message is called the seed message.

There is an acknowledgment mechanism so the sender can know if a message has actually been delivered. Except in cases of synchronous processing (synchronous message sending or local performance of a service), this is not an acknowledge of message delivery, and even less of message processing.

Messages in a distributed system do not all have the same importance. Some must absolutely be processed, while others may be lost without any major consequences to the good working order of the applications. So it is possible to qualify a message as being persistent, in which case the seed message will remain available on the server as long as the maximum number of copies has not yet been made of it, and as long as it has not been explicitly cleared, so that each new service connecting to the server and corresponding to the message addressee profile will receive a copy of it. The messages can be saved on disk, to be sure they will be restored if the server shuts down.

To recover the messages meant for a given service, a message profile is given. This profile may designate a single, identified message, or a set of messages, or all the messages posted. If more than one message is a candidate, the oldest of them is selected.

You can also ask for a message envelope containing a set of messages, and then decide which message to get.

Each language's API manages the data conversion to or from the OpenMOM generated format, for structured data (objects, arrays of objects) conversion is done in the following ways:  

	pre-processing for compiled languages
	Dynamic conversion for interpreted languages.
	OpenMOM will identify the type mismatches between senders and receivers.

 

____________________________________________________
OpenMOM: how to use it ?

Programming

OpenMOM supplies APIs for popular languages such as C, C++, Perl, Java, Python, Visual Basic , Active X or more specialized ones, such as CA-OpenROAD, Jasmine.

OpenMOM APIs offer many services easy to use and regrouped in five categories:

• Initialization and manipulation of communication sessions
• Services and routers management
• Sending messages
• Receiving messages
• Message Brokers management

As opposed to CORBA, OpenMOM does not use IDL descriptions nor runtimes (stub): the declaration and installation of service interfaces are fully dynamic.

OpenMOM can be used as an RPC (Remote Procedure Call) to send function calls and handle the results.

Asynchronism and message persistence are two key implementation features of the message broker, which architecture relies on a lightweight implementation of the DCE/RPC standard.

OpenMOM is also a perfect fit for object communication with object-oriented languages, such as C++.

Administration

An easy-to-use and intuitive graphic user interface helps you to administer the OpenMOM based distributed environments.

____________________________________________________
Features summary

Copyright © 1999 4 Tier Software