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.