Overview

OpenMOM's Simple concept

OpenMOM makes it easy to use rugged, effective, distributed applications.

Basically, OpenMOM lets the different components of a distributed application (called services) communicate with each other through messages. This communication is based on special programs called OpenMOM servers (or OpenMOM message brokers). An OpenMOM server is not a server in the application sense of the term (a role that will be played by the services you define), but rather a message server organized like a set of mailboxes corresponding to the different services available from the server.

OpenMOM's minimum client program framework

A given OpenMOM client program has its own services to offer, and can use the services of other programs too. It always has to be connected to at least one OpenMOM server.

The program defines one or more services, giving a service name and various properties (using the RE_CPcreateService function). If this service is designed to distribute its functional capacities to the other services, then it has to declare the events it can react to by calling the RE_CPaddServiceEvent function.

Once these definitions are made, the service can be connected to the OpenMOM server(s) by the RE_CPconnect function. With this connection, the service is "registered" on the server(s), which means its properties become visible and an interface is defined so that the other services can address it. A session is created on the client at the same time.

The service is then operational. It can send (RE_CPsendMessage function) and receive (RE_CPgetMessage function) messages.

Any session that has become useless should be closed, by calling the RE_CPdisconnect function.

Sessions and connections

A session links a service to a connection (that is, an OpenMOM server 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 (see 'Servers.lst' configuration file).

Services

A service declaration is dynamic, and can be modified. As soon as a service connects to an OpenMOM server, 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. It also integrates a unique identifier on each server to which it is connected. The activation of a service can be controlled by modifying its status.

Messages

OpenMOM messages are used for transferring data among services. The services concerned may be performed on different machines or different operating systems, and may be developed in different languages. No special development effort is needed to convert, encode, or decode the data transmitted by a message. This data can be of simple, structured types, or arrays. They will be converted by OpenMOM. Also, 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 has the ability 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 acknowledge mechanism to inform the sender that 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 on correct operation 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 been made, 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 set of message envelopes, and then decide which message to get.

Customizing the server

OpenMOM servers are fully adaptable programs whose actions can be modified dynamically, and whose execution can be monitored.

An OpenMOM server 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, monitoring 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 server, 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.

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

Examples of useful reflexes

Access control, alert callbacks to clients when a message arrives, compression-decompression, activity surveillance, ciphering and deciphering, fine-tuned load balancing, routing, among others.

Using a reflex

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 server.

Routing

OpenMOM can define special services called routers.

A router controls the route a message takes. It is active on a given server and is used to redirect the messages.

A router can be defined for a server (in which case all the messages reaching the server will be routed to the proxy server described by the router); it can be defined for a service (all messages are mailed along to the proxy service described by the router), or for a special event (the messages corresponding to the event are mailed on to the proxy event described by the router).

A router can be created dynamically, so services can be substituted during execution.

Tuning

OpenMOM behaviour can be modified by some system defined variables. On Microsoft Windows systems, these variables have to be defined in the registry, and on UNIX systems, they are setted using environment variables.

Copyright © 1999 - 2001 4 Tier Software