|
The
OpenMOM's architecture, based on asynchronous communications, 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 but can
participate in a conventional client/server architecture at the
same time.
A broker manages
communications with a group of applications called services. A service
publishes and subscribes messages to a broker for a number of functions,
each of which is associated with a specific event. For example,
the stock management service will provide a specific process for
each event such as stock input, stock output or order to supplier.
An event is expressed in terms of a message received in the mail
box.
An application
registers its service(s) to all the OpenMOM brokers it plans
to use.
A component
declares one or more service interfaces dynamically to one or more
OpenMOM brokers.
A service interface consists of properties (name, type for example)
and a list of events the service can process (it may be empty if
the service acts only as a client).
These
interfaces can be declared and modified at run time,
so distributed components can be added, exchanged or relocated.
OpenMOM
messages are used for transferring data among services. The services
concerned may be performed on different machines or different
operating systems, and can be 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 simple (strings,
numerical, or other), complex (native objects or structures from
development languages, arrays) or binary data (video, sound, files
and so forth).
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.
Other message properties include the sender's description, time
stamp, and the like.
When a message
reaches a broker, 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 delivered. The original
message is called the seed message.
Synchronous
messaging is fully supported, it uses the same API calls as for
asynchronous communication but the Type property of the
message is set to Synchronous. The sender is locked until
an answer message is received (if any receivers are connected).
OpenMOM defines
a logical name space for messages and distributed architecture components.
Every parts is identified by human-readable and parametrizable information.
Applications interoperate without knowledge of their physical
location (network address, socket ports, protocol, and so forth).
Messages are sent, specifying an event name and criteria over the
recipient(s), and are automatically addressed to matching services.
On the other side of the exchange, subscribers can specify parameters
to filter incoming messages.
Yes. An acknowledge
can be requested when sending a message. This acknowledgment contains
various information like the number of messages posted and the identity
of the recipient(s).
You do not have
to ask for an acknowledge in order to make sure your message is
deposited, (the SendMessage command's return value is enough).
Yes. OpenMOM
brokers ensure that the message will be delivered (even in the case
of failure for persistent messages).
How
do you enable message recovery?
Messages identified
as persistent are stored physically in one or more log files by
OpenMOM message brokers and are kept until delivery or deletion.
If a message broker fails, pending messages can be recovered either
by a newly started message broker or, for fault tolerance purposes,
they can be recovered automatically and transparently by a mirror
broker.
These mechanisms
are implemented as an OpenMOM reflex, so they can be replaced.
Yes. As many
as four log files can be specified for each service message box.
Does
OpenMOM provide any transaction processing / unit-of-work capabilities,
and are they XA compliant?
OpenMOM's working
unit is the message.OpenMOM ensures a once and only once (or n
and only n) delivery of a message even if its addressee
is not available at the time of dispatch. Message transfers are
fail-safe when using recoverable messages, and they can be made
fault-tolerant.
OpenMOM brokers
and client APIs don't deal directly with DBMS since these are tasks
for the server side components. Nevertheless, OpenMOM's secure messaging
features make heterogeneous two phase commit possible at the application
level.
OpenMOM components can perform calls to third-party TP monitors
(and inversely).
Yes. Various
OpenMOM's features make it possible to set up fault-tolerant distributed
systems easily:
- Redundant
application processes can be added at any time.
- OpenMOM mirror
brokers can be started at any time.
- Different
routes can be created between components.
OpenMOM can
send a message
to one addressee,
to several
addressees (multicast),
to all the
addressees interested in such a message (broadcast),
to a maximum
number of all possible addressees (multicast).
The message
is sent once and is then dispatched to suitable addressees by the
OpenMOM brokers.
Object morphing
ensures a transparent translation of structured data between
various programming languages.
OpenMOM packages
data structures and objects from many languages into messages. These
messages have to be understood by the components involved, regardless
of what operating system or programming language is used.
Each language's API manages the data conversion to or from the
OpenMOM message format, so that the encoding and decoding of exchanged
objects becomes transparent.
Structured data (objects, object arrays), is converted dynamically
for interpreted languages that provide run time type information,
and preprocessed declarations are used for other languages.
OpenMOM brokers
are fully adaptable programs that can be modified dynamically,
and whose execution can be monitored. An OpenMOM broker manages
each client access on an independent thread, which may include event-triggered
calls to external functions/methods (provided in DLLs or in Java
classes). This is called reflex triggering. Reflexes are
of use when connecting services (for example for protecting access
to a server with passwords, monitoring access, and so forth). But
they can also be triggered when a message arrives (all messages,
or specific messages determined by selection criteria) to run actions,
act on the message, permit or prevent it from being processed, route
it to another destination depending on its properties or contents,
convert it, have it processed by another communication program,
or other action.
OpenMOM reflexes
are of different kinds :
- Logging
Service
This service is used to store persistent messages on disk.
- Registration
Filter
When a service connects to a server, these reflexes are triggered.
A list of filters can be declared for each service. These filters
will be run in a sequence.
- Local
Service
These are special reflexes that can be viewed as actual
services. They consume message copies, they can process messages
reaching the server, and return a reply to the sender.
- Message
Filter
When a message arrives on a server, the reflexes associated
with the message are triggered. The message can be modified in
a reflex (to change its destination, content, and so forth).
- Message
Delivery Filter
These reflexes are triggered when a posted message is about
to be delivered to a service. They decide whether or not the message
will be delivered.
- Dead
Letters Reflex
These reflexes are triggered when a message finds no matching
service.
- De-registration
Filter
When a service disconnects from a server, these reflexes are
triggered. A list of filters can be declared for each service.
These filters will be run in a sequence.
Yes. With OpenMOM,
client and server components of a distributed architecture are seen
as logical entities called services. All communication
features are automatically enabled for services.
Yes. An OpenMOM
broker can use various network protocols at the same time, so components
using different protocols can communicate.
No, the message
broker architecture manages all these points transparently.
For all platforms
the theoretical maximum message size is 2 GB (but breaking large
messages into parts prevents the network from slowing down).
Yes. OpenMOM
brokers manage structured message boxes within which messages can
be accessed individually or in sets, corresponding to given criteria.
Persistent messages
are kept by OpenMOM brokers until all their copies are dispatched.
All undelivered messages can be processed by special broker reflexes
called Dead Letters; which can be used to perform any required
action.
Pending messages
can be deleted using APIs calls or the OpenMOM explorer.
Yes.
- OpenMOM is
shipped with an administration tool (the OpenMOM explorer) for
tracking services and message activity interactively.
- Specific
reflexes can be declared to a message broker to carry out user
defined auditing/reporting functions.
- Tailor-made
administration tools are easy to develop using OpenMOM APIs.
Yes. A list
of message envelopes can be asked for. An envelope contains information
about the sender and the message (size, date, ...). The next message
to process can be chosen from this list.
Yes.
But it should be kept in mind that, with OpenMOM features, it's
a poor man's choice to rely on numerical priorities (messages can
be accessed in any order, through application logic based requests,
not only in a FIFO order).
Yes, in many
ways and at all levels.
- By using
OpenMOM brokers'reflexes, messages can be filtered by sender,
recipient, subject, size, date and contents. Reflexes can be used
to perform any required action.This feature makes it easy to define
business rules to adapt the message flow to specific needs.
- With OpenMOM's
dynamic routing features, messages can be routed between different
sets of services connected to different message brokers.
- Since message
boxes are structured, receivers can specify parameters to filter
incoming messages.
- Brokers and
services'status can be modified to stop queuing messages.
Yes. When messages
arrive on a message broker, certain reflexes are executed that can
start application services. Dedicated services can also be developed
to handle such needs.
Yes. To transmit
a binary or ASCII file, you can use the linkedFilePath
parameter of the SendMessage methods
and functions.
Yes. All OpenMOM
modules are thread-safe.
Yes, OpenMOM
is designed for inter-process communication (whether those processes
are on the same computer or not).
Yes. OpenMOM's
asynchronism and recoverable messages (allowing loosely coupled
communications), make it fully suitable to mobile computing.
Yes. By registering
an application with multiple brokers you can:
- Optimize
the message transfer by selecting the closest broker.
- Take advantage
of multiple routes to be protected from network failures.
- Dedicate
certain brokers to specific exchanges.
Yes. Routes
can be created dynamically between one broker and another,
in the OpenMOM explorer or through APIs calls.
When a route is created, a special OpenMOM service called a Router
is registered on the route's starting broker. Three levels
of routers can be set up :
- Broker routers
(messages routed to a proxy broker)
- Service routers
(messages routed to a proxy service)
- Event routers
(messages routed to a proxy service event)
Routes can be
used as aliases (or shortcuts) to add a level to the dispatching
processing, giving more flexibility.
Routes provide control over the message flow.
Routes can be used to allow groups of applications connected to
a message broker to communicate with other groups, by broker-to-broker
communication multiplexing.
Notes
:
- Routes can be set even if they define cycles.
- Messages are routed to proxies until all available copies have
been posted.
- Routes can be created within a standalone broker (for aliasing
purposes).
- Routes can be enabled/disabled by switching router status.
Yes. The necessary
cleanups and updates are performed.
Yes, clients
reconnect automatically to the restarted process. If the original
process is not restarted, clients can reconnect automatically to
a backup broker.
No. The maximum
is based on the machine's capacities. Moreover it's easy to interconnect
OpenMOM brokers to adapt to increasing connections.
OpenMOM services
are not restricted to interact only with OpenMOM message brokers.
To use the capacities of third-party services (CORBA calls, MQ messages
passing, RPC calls, TP monitor and other services), without modifying
the source code of these services and while making most of OpenMOM
capacities (such as asynchronism, fault tolerance, guaranteed delivery),
you can develop an OpenMOM service which, in reaction to some messages,
processes the calls you need. This service can be written with the
programming language best suited to your needs. Because OpenMOM's
messages are able to transport objects (automatically translated
into a native object of the target language), translations to others
communication paradigms are quite easy to perform.
With OpenMOM
capabilities you can mix different middleware solutions and enhance
point-to-point communications by providing flexibility, scalability
and reliability.
Yes. OpenMOM
allows you to insert any desired level of encryption and authentication
by adding reflexes to the broker and/or by enhancing services.
Furthermore, OpenMOM makes it easy to integrate security and control
mechanisms at the application level (each action on exchanged messages
can be monitored and filtered depending on sender, recipient, subject,
contents, or other criteria).
C, C++, Java,
VisualBasic, ActiveX, Perl, Python, OpenROAD.
Wrapping APIs can be constructed easily to integrate with other
languages.
All client runtimes
and the OpenMOM broker run on Windows NT 3.51, 4.0 and Windows95.
Java and C client runtimes are supported on any platform supporting
Java VM 1.1 (see http://java.sun.com/cgi-bin/java-ports.cgi).
These runtimes use Java RMI as transport layer.
OpenMOM broker and suitable client runtimes are ported on HP-UX,
SUN Solaris and IBM AIX (using DCE/RPC as transport layer).
- TCP/IP
- NetBIOS/NetBEUI
- NetBIOS/TCP
- NetBIOS/IPX
- UDP/IP
- IPX
- SPX
- DECnet
- Named Pipes
- Local inter
process communication
For pure Java
clients, the Java RMI is used.
|
