MOM Vs RPC
|
Feature |
MOM |
RPC |
|
Metaphor |
Post-office like |
Telephone like |
|
Client/Server time relationship |
Asynchronous. Clients and Servers may operate at different times and speeds |
Synchronous. Clients and Servers must run concurrently. Servers must keep up with clients. |
|
Client/Server Sequencing |
No fixed sequence |
Servers must first come up before clients can talk to them. |
|
Style |
Queued |
Call-Return |
|
Partners need to be available |
No |
Yes |
|
Load-balancing |
Single queue can be used to implement FIFO or priority based policy |
Requires a separate TP Monitor. |
|
Transactional Support |
Yes (Some Products) Message Queue can participate in the commit synchronization |
No. Requires a Transactional RPC. |
|
Message Filtering |
Yes |
No |
|
Performance |
Slow. An intermediate hop is required |
Fast |
|
Asynchronous processing |
Yes. Queues and triggers are required |
Limited. Requires threads and tricky code for managing threads. |
Messaging and Queuing : The MOM Middleware
- MOM is a key piece of middleware that is absolutely essential for a class of client/server products.
- If the application can tolerate a certain level of time-independent responses, MOM provides the easiest path for creating enterprise and inter-enterprise client/server systems.
- This accumulates outgoing transactions in queue and do a bulk upload when a connection can be established with an office server.
- MOM allows general purpose messages to be exchanged in a client/server system using message queues.
- Applications communicate over networks by simply putting messages in queues and getting messages from queues.
- MOM hides all the nasty communications from applications and typically provides a very simple high-level of API to its services.
- A MOM consortium was formed in mid-1993 with the goal of creating standards for messaging middleware.
- Members are product providers including
- IBM – MQSeries
- Covia – Communications Integrator
- Peerlogic – PIPES
- Horizon Strategies – Message Express
- System Strategies – ezBridge
- MOM’s messaging and queuing allows clients and servers to communicate across a network without being linked by a private, dedicated, logical connection.
- The clients and servers can run at different times.
- Everybody communicates by putting messages on queues and by taking messages from queues.
- MOM products provide their own NOS services – including hierarchical naming, security, and a layer that isolates applications from the network.
- They use virtual memory on the local OS to create their queues.
- Most messaging products allow the sender to specify the name of the reply queue.
- The products also include some type of format field that tells the recipient how to interpret the message data.
- MOM enabled programs do not talk to each other directly, so either program can be busy, unavailable, or simply not running at the same time.
- The target program can even be started several hours later.
- Many clients are sending requests to one server queue.
- The messages are picked off the queue by multiple instances of the server program that are concurrently servicing the clients.
- The server instances can take messages off the queue either on a FIFO basis or accounting to some priority to load-balancing scheme.
- The message queue can be concurrently accessed.
- The servers can also use messaging filters to throw away the messages they don’t want to process, or they can pass them on to other servers.
- The MOM messaging products provide persistent (logged on disk) and non-persistent (in memory) message queues.
- Persistent messages are slower, that they can be recovered in case of power failures after a system restart.
- A message queue can be local to the machine or remote.
- System administrators can usually specify the number of messages a queue can hold and the maximum message size.
