 |
Frequently Asked Questions |
|
Frequently Asked Questions |
What is an OpenMOM
message broker?
What is an OpenMOM
service?
How do I register an
OpenMOM service?
What's in a message?
What is a seed message?
Does OpenMOM support
synchronous messaging?
How are messages
addressed to a service? Is location transparency ensured?
Does the broker
acknowledge when a message is sent?
Is message delivery
guaranteed?
How do you enable
message recovery ?
Is it possible to have
replicated logging of messages?
Does OpenMOM provide any
transaction processing / unit-of-work capabilities and are they
XA compliant?
Can I use OpenMOM to
build fault tolerant distributed applications?
What are broadcast and
multicast?
What is object morphing?
What is a broker's
reflex?
Can client applications
communicate with each other?
Can I use OpenMOM
brokers to establish protocol bridges?
Does OpenMOM require an
understanding of the underlying network, platform, or queue
structure?
What is the maximum
message size?
Is there a separate
message box for each service?
How are undeliverable
messages handled?
How are unsolicited
messages handled?
Can activity be audited?
Is it possible to
inspect queued messages before getting them?
Can messages priorities
be established?
Is it possible to
control message flow?
Can programs be started
automatically when specific conditions are met?
Can we transmit a file
along with the API function calls?
Can I use OpenMOM in
multi-threaded programs?
Can I use OpenMOM for
inter-process communication on a standalone computer?
Can I use OpenMOM for
mobile computing?
Can I connect an OpenMOM
service to multiple OpenMOM brokers?
Can OpenMOM brokers be
connected together? What is dynamic routing?
Does OpenMOM detect when
a client connection is broken?
If an OpenMOM broker
exits and restarts, do clients reconnect automatically to the
restarted process?
Is there a maximum
number of connections to an OpenMOM broker?
Can I mix OpenMOM with
other middleware? Is OpenMOM CORBA compliant?
What about security? Is
it possible to encrypt and authenticate messages?
Which programming
languages are supported?
Which platforms are
supported?
Which networking
protocols are supported?
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.
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:
OpenMOM can send a message
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 :
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.
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.
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:
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 :
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).
For pure Java clients, the Java RMI is used.