Scribd
Upload
30 views

Message Oriented Middleware

Message-Oriented Middleware (MOM) allows software components to communicate asynchronously by exchanging messages. MOM systems use a messaging provider to route and deliver messages between loosely coupled clients. The provider handles issues like reliability, security, and performance so client applications only need to send, receive, and process messages. MOM enables integration between heterogeneous systems and can connect synchronous systems like RPC-based systems by acting as an intermediary between them.

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
30 views

Message Oriented Middleware

Message-Oriented Middleware (MOM) allows software components to communicate asynchronously by exchanging messages. MOM systems use a messaging provider to route and deliver messages between loosely coupled clients. The provider handles issues like reliability, security, and performance so client applications only need to send, receive, and process messages. MOM enables integration between heterogeneous systems and can connect synchronous systems like RPC-based systems by acting as an intermediary between them.

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Message-Oriented Middleware (MOM)

Because businesses, institutions, and technologies change continually, the software


systems that serve them must be able to accommodate such changes. Following a
merger, the addition of a service, or the expansion of available services, a business
can ill afford to recreate its information systems. It is at this most critical point that
it needs to integrate new components or to scale existing ones as efficiently as
possible. The easiest way to integrate heterogeneous components is not to recreate
them as homogeneous elements but to provide a layer that allows them to
communicate despite their differences. This layer, called middleware, allows
software components (applications, enterprise java beans, servlets, and other
components) that have been developed independently and that run on different
networked platforms to interact with one another. It is when this interaction is
possible that the network can become the computer.

As shown in Figure 1–1, conceptually, middleware resides between the application


layer and the platform layer (the operating system and underlying network
services).
Figure 1–1 Middleware

Applications distributed on different network nodes use the application interface to


communicate without having to be concerned with the details of the operating
environments that host other applications nor with the services that connect them
to these applications. In addition, by providing an administrative interface, this
new, virtual system of interconnected applications can be made reliable and secure.
Its performance can be measured and tuned, and it can be scaled without losing
function.

Middleware can be grouped into the following categories:

 Remote Procedure Call or RPC-based middleware, which allows procedures


in one application to call procedures in remote applications as if they were
local calls. The middleware implements a linking mechanism that locates
remote procedures and makes these transparently available to a caller.
Traditionally, this type of middleware handled procedure-based programs;
it now also includes object-based components.
 Object Request Broker or ORB-based middleware, which enables an
application’s objects to be distributed and shared across heterogeneous
networks.
 Message Oriented Middleware or MOM-based middleware, which allows
distributed applications to communicate and exchange data by sending and
receiving messages.

All these models make it possible for one software component to affect the
behavior of another component over a network. They are different in that RPC-
and ORB-based middleware create systems of tightly-coupled components,
whereas MOM-based systems allow for a looser coupling of components. In an
RPC- or ORB-based system, when one procedure calls another, it must wait for the
called procedure to return before it can do anything else. In
these synchronous messaging models, the middleware functions partly as a super-
linker, locating the called procedure on a network and using network services to
pass function or method parameters to the procedure and then to return results.

MOM-based systems allows communication to happen through


the asynchronous exchange of messages, as shown in Figure 1–2.
Figure 1–2 MOM-Based System
Message Oriented Middleware makes use of messaging provider to mediate
messaging operations. The basic elements of a MOM system are clients, messages,
and the MOM provider, which includes an API and administrative tools. The
MOM provider uses different architectures to route and deliver messages: it can
use a centralized message server or it can distribute routing and delivery functions
to each client machine. Some MOM products combine these two approaches.

Using a MOM system, a client makes an API call to send a message to


a destination managed by the provider. The call invokes provider services to route
and deliver the message. Once it has sent the message, the client can continue to do
other work, confident that the provider retains the message until a receiving client
retrieves it. The message-based model, coupled with the mediation of the provider,
makes it possible to create a system of loosely-coupled components. Such a system
can contin

One other advantage of having a messaging provider mediate messaging between


clients is that by adding an administrative interface, you can monitor and tune
performance. Client applications are thus effectively relieved of every problem
except that of sending, receiving, and processing messages. It is up to the code that
implements the MOM system and up to the administrator to resolve issues like
interoperability, reliability, security, scalability, and performance.

So far we have described the advantages of connecting distributed components


using message-oriented middleware. There are also disadvantages: one of them
results from the loose coupling itself. With a synchronous messaging system, the
calling function does not return until the called function has finished its task. In
an asynchronous system, the calling client can continue to load work upon the
recipient until the resources needed to handle this work are depleted and the called
component fails. Of course, these conditions can be minimized or avoided by
monitoring performance and adjusting message flow, but this is work that is not
needed with a synchronous messaging system. The important thing is to
understand the advantages and liabilities of each kind of system. Each system is
appropriate for different kinds of tasks. Sometimes, you will need to combine the
two kinds of systems to obtain the exact behavior you need.

Figure 1–3 shows the way a MOM system can enable communication between two
synchronous messaging systems (for example, two RPC-based systems). The left
side of the figure shows an application that distributes client, server, and data store
components on different networked nodes for improved performance. This is a
discount airline reservation system: an end user pays a fee to use this service,
which allows it to find the lowest available fare for given destinations and times.
The data store holds information about registered users and about airlines that
participate in this program. Based on the user’s request, logic on the server queries
participating airlines for prices, sorts through the information, and presents the
three lowest bids to the user. The right side of the picture shows an RPC-based
system that represents the ticket/reservation system for any one of the participating
airlines. The right side of the picture would be replicated for as many airlines as the
discounter is connected to. For each such airline, the data store would hold
information about available flights (seating, flight times, and prices). The server
component would update that information in response to data input by the end
user. The airline server also subscribes to the MOM service, accepting requests for
information from the discount reservation system and returning seating and pricing
information. If a customer decides to purchase a discounted ticket on a PanWorld
flight, the server component for that system would update the information in the
data store and then either generate a ticket for the requester or send a message to
the discounting service to generate the ticket.
Figure 1–3 Combining RPC and MOM Systems

This example illustrates some of the differences between RPC and MOM systems.
The difference in the way in which distributed components are coupled has already
been mentioned. Another difference is that while RPC systems are often used to
distribute and connect client and server components in which the client component
is directly accessed by an end-user, with MOM systems, client components are
often heterogeneous software systems that can only interoperate by means of
asynchronous messaging.

A more serious problem with MOM systems arises from the fact that MOMs are
implemented as proprietary products. What happens when your company, which
depends on SuperMOM-X acquires a company that uses SuperMOM-Y? To
resolve this problem, a standard messaging interface is needed. If both
SuperMOM-X and SuperMOM-Y implemented this interface, then applications
developed to run on one system could also run on the other. Such an interface
should be simple to learn but provide enough features to support sophisticated
messaging applications. The Java Message Service (JMS) specification, introduced
in 1998, aimed to do just that. The next section describes the basic features of JMS
and explains how the standard was developed to embrace common elements of
existing proprietary MOM products as well as to allow for differences and further
growth.

 Previous: Preface

You might also like