| Need |
Features |
Comments |
| Enterprise
level messaging activity |
A
Multi-Threaded Architecture |
A
message broker has to be fast and reliable to support 24x7 activity.
They
must also be developed with 3GL standard such as C or C++,
to integrate a robust memory management, fully compiled for
maximum efficiency with no bottlenecks in the complete processing
of message brokering.
Every
task must have multiple parallel executions (task are network
protocol sensitive, execution of a local service, routing
messages between services, etc.)
|
|
Dynamic
Load balancing |
The
possibility to have multiple services performing the same kind
of message for scalability purpose. The first available service
will catch the next in-coming message. Services can be started
or stopped during online activities for a good tuning of the
distributed application scalability. |
|
Broker
proxies & multiplexing |
This
is the answer to scalability needs for message broker based
distributed architecture.
A
broker can be a proxy for different or other brokers ; any
kind of broker network can be designed even with proxy loops.
Broker proxies can be defined at broker, service, or message
level for a fine business exchange.
When
a message is posted to a broker, the broker looks around for
services to match the delivery conditions contained within,
if not the message is routed to the proxy brokers and so on.
Message
with infinite number of copies are distributed all around
the network. All routed message between 2 brokers uses the
same network connection (multiplexing).
|
| Guaranteed
delivery for Transactional messaging |
Guaranteed
delivery |
A
service sending an asynchronous message will get a receipt from
the broker. The message will be administrated, (persistency,
logging, mirroring), until the targeted service will execute
it. |
|
Once
and Only Once delivery |
A
transaction oriented message has to be delivered once to the
potential services able to execute it even with a load balanced
application architecture with multiple potential services performing
the same transaction. The message must deliver the exact number
of copies the transaction has to execute (only once or a predefined
number of times in replicated information systems). |
|
Persistency |
A
message with a copy number greater than 0 will stay in the broker
until its deletion (if requested). |
|
Asynchronous
& synchronous messaging |
A
service sends messages, either waits or does not wait for the
result of the execution of the attached events to the targeted
services. The communicating services have to be present simultaneously
in the network. |
|
Loosely
coupled asynchronous messaging |
This
is the full featured guaranteed delivery. Services can be independently
presents in the network, they put and get messages from message
broker whenever the sender or the receiver is absent. |
|
Notification
of waiting message |
A
service has to be informed when a message is waiting for it.
There are two ways to be inform : by a callback sent by the
message broker or by polling to get information from the message
broker. |
|
Distributed
transaction support |
A
service can be connected to multiple brokers at the same time
with different sessions to manage transaction oriented message. |
|
Logging
& multiple logging |
A
broker failure can happens, persistent messages have to be stored
in log file (better with multiple files on different systems)
for a guaranteed delivery by starting a new broker on these
log files. |
| Fault
tolerance |
Broker
mirroring & Automatic service reconnection
|
Logging
persistent message for guaranteed delivery is good but services
will be disconnected as for a Client connected to a DBMS when
a failure occurs. Restarting all services on a new broker take
a while and disappoints Internet / Intranet end-users. A broker
can be started as a mirror at any time for an other broker.
The main broker and its mirror share the same log files, when
the main fails all connected services are reconnected to the
mirror automatically and all the messaging activity is reloaded
to the mirror. The complete process take only few seconds. |
| TP
oriented messaging |
Local
service execution |
A
broker can dynamically load add-on services from libraries and
execute them in local threads. |
|
Security |
A
broker can refuse a service connection or message emission /
reception depending on service and message filter list and identification. |
| Intelligent
Information exchange |
Development
Languages integration |
The
architecture of the message broker is at the heart of the overall
system architecture but the way to access the messaging activity
not only has to be relevant to its context, but also the cost
and the complexity of a distributed application development
are conditioned by the robustness and the richness of the APIs. |
|
Raw
data exchanges |
The
API send data "AS IS" from the sender and the receivers
have to know the composition of the data stream. This data format
exchange is the proposed method of exchange by MQ products.
If this technique is good enough for transferring files, blob,
video, or character strings, it becomes insufficient when structured
objects are involved. |
|
Self
-describing structured datas exchanges |
The
API from the sender encode the structured object into an internal
format which will be decoded by the receiving API which automatically
recuperates the structured object, even between different host
languages and operating systems. |
|
Message
selection |
A
message broker exchanges objects between services encapsulated
in messages, for reliability. A service can get the envelope
of waiting message from the broker, (provenance, id, name, size
of encapsulated object, arrival date, etc.) and in any order,
not only FIFO. |
|
Publishing
messages & Subscribing to Messages |
Services
involved in the distributed application subscribe to messages
then want to be in copy and publish message for other services
subscribed for. |
|
Full
& controlled Multicasting |
A
service can send a message to a broker with few restriction
regarding the targeted services. The broker posts as many copies
of the message to services matching the designated criteria.
A
message can have limited copies (1 to infinite), and the first
service available will retrieve it.
|
| Mobile
computing integration |
Small
footprint for the complete product |
Mobile
computers are going to be an important part of distributed computing
architecture. A message broker have to be small to allow a complete
standalone installation on PCs or laptop. |
|
Local
Message Database keeping previous or default answer message
when targeted services are not reachable |
In
the case when a service posts a message to a broker for the
execution of an event on an other broker. If the targeted service
is not available, the broker checks if the answer to the message
is available within "persistent messages", ( the broker
can also look first in persistent message then to an available
service to execute the message). |
