MOM was created to address some of the shortcomings of RPCs by the use of messaging. Traditional MOM is queuing software, using messages-byte-sized units of information that move between applications-as a mechanism to move information from point to point.
Because MOM uses the notion of messages to communicate between applications, direct coupling with the middleware mechanism and the application is not required. MOM products rely on an asynchronous paradigm.
The asynchronous model allows the application to function independently-that is, to continue processing after making a middleware service request. The message is dispatched to a queue manager, which ascertains that the message is delivered to its final destination. Messages returning to the calling application are handled when the calling application finds the time.
Unlike the synchronous paradigm, the asynchronous paradigm does not block the application from processing. Although this model is more complex than the synchronous model, it is more convenient for developers and users. In addition, MOM can ensure delivery of a message from one application to the next for several sophisticated mechanisms, such as message persistence. Developers find that MOM's use of messages is relatively easy to manage. Messages have a structure (a schema) and content (data). It is possible to think of them as little one-record databases that move between applications through message-passing mechanisms. MOM supports two models: point-to-point and message queuing (MQ)-the second is our primary focus here.
MQ has a number of performance advantages over standard RPCs. MQ lets each participating program proceed at its own pace, without interruption from the middleware layer. As a result, the calling program can post a message to the queue and then "get on with its life." If a response is required, the calling program can get it from the queue later. MQ allows programs to broadcast the same message to many remote programs without having to wait for the remote programs to be up and running.
Because MQ software (e.g., IBM's MQSeries or Microsoft MSMQ) manages the distribution of messages from one program to the next (although the program is responsible for putting messages into the queue and pulling messages from it), the queue manager can optimize performance by utilizing such methods as prioritization, load balancing, and thread pooling.
There is little danger of messages being lost during a network or system failure. Most MQ software allows messages to be declared as persistent or stored to disk during a commit at certain intervals. This ensures recovery from such situations.
Dig Deeper on Topics Archive
Related Q&A from David Linthicum
David Linthicum explains what advanced business application programming (ABAP)/4 means. Continue Reading
David Linthicum defines Service Component Architecture (SCA) and Service Data Objects (SDO) and explains how to best build these components to enable... Continue Reading
David Linthicum explains how it is possible that Apache Tomcat is both a Web server and an application server. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.