Message Oriented Middleware

Introduction
Message-oriented middleware (MOM) is software or hardware infrastructure
supporting sending and receiving messages between distributed systems. MOM allows
application modules to be distributed over heterogeneous platforms and reduces the
complexity of developing applications that span multiple operating systems and network
protocols. The middleware creates a distributed communications layer that insulates the
application developer from the details of the various operating systems and network
interfaces. APIs that extend across diverse platforms and networks are typically provided by
MO.

Characteristics
Performance
The performance of a middleware is usually tied to the response time the user (client) has to
wait until his or her response is received. This is usually the time between when the execute
button is pressed and the results of the remote server’s execution is received. Usually the user
gauges the response time against trivial requests made to the local workstation’s operating
system. Now there are a number of factors that can influence the response time, so our
assumption will be that the client’s network is not overloaded, the client’s workstation is
sufficient to do enterprise computing, the server is not overloaded with a good balance of
available CPU, memory, disk and IO bandwidth for executing client requests and there are no
significant network issues between client and server.

Scalability
One major responsibility of middleware is to scale up the number of software services
(providers) available to clients (consumers) based on past demand. The demand can be
measured in different ways depending on the programming paradigm used and whether multi-
threading is involved, but ultimately it is reflected in the time the user has to wait for results.
The middleware’s responsibility is to provide sufficient capability to enable additional servers
to be started to meet demand. In an enterprise environment, load leveling of the application
servers across the enterprise is also important to prevent overtaxing computer resources on
specific systems.

Adaptability
Adaptability is the virtue of middleware that enables it be used for different types of
applications with differing resource requirements. In some cases this refers to computer
languages and operating systems, sometimes it is adaptation to database technologies and
sometimes it is the ability to adapt to the design of the application or adhere to its business
rules. This measurement is difficult to measure sometimes because there are different ways to
implement logic depending on the programming paradigm. In other cases, it is simply a case
of “yes” it supports this or “no” it doesn’t.

Maintainability
As with many applications poorly designed, maintenance is a big consideration in choosing
middleware. Middleware maintenance refers to the number of problems that occur with
running enterprise applications. There are some cases where legacy middleware applications
are problematic: multi-language, multi-platform and multi-database heterogeneous
middleware environment always seem to have more problems that homogeneous ones. OS
and database changes contribute to the maintenance problems of middleware, but in the end,
the stability of the applications, middleware data passing, naming service functions, memory
management functions, application monitoring and resource usage determine the viability of
most middleware technologies.

Ease of Use
Perhaps the most important factor in evaluation of middleware technologies is the ease of use.
If understanding of how it works and configuration of the middleware is too difficult for
administrators, engineers and users, then it will fail. Most middleware systems have an IDL
compiler, a naming or broker service, runtime utilities and application monitors. The ability to
use each of these components determines the ease of use.

Advantages
Central reasons for using a message-based communications protocol include its ability
to store (buffer), route, or transform messages while conveying them from senders to
receivers.
Another advantage of messaging provider mediated 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.

Asynchronicity
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.
MOM comprises a category of inter-application communication software that generally
relies on asynchronous message-passing, as opposed to a request-response architecture. In
asynchronous systems, message queues provide temporary storage when the destination
program is busy or not connected. In addition, most asynchronous MOM systems provide
persistent storage to back up the message queue. This means that the sender and receiver do
not need to connect to the network at the same time (asynchronous delivery), and problems
with intermittent connectivity are solved. It also means that should the receiver application
fail for any reason, the senders can continue unaffected, as the messages they send will simply
accumulate in the message queue for later processing when the receiver restarts.

Routing
Many message-oriented middleware implementations depend on a message queue
system. Some implementations permit routing logic to be provided by the messaging layer
itself, while others depend on client applications to provide routing information or allow for a
mix of both paradigms. Some implementations make use of broadcast or multicast distribution
paradigms.

Transformation
In a message-based middleware system, the message received at the destination need
not be identical to the message originally sent. A MOM system with built-in intelligence can
transform messages en route to match the requirements of the sender or of the recipient. [3] In
conjunction with the routing and broadcast/multicast facilities, one application can send a
message in its own native format, and two or more other applications may each receive a copy
of the message in their own native format. Many modern MOM systems provide sophisticated
message transformation (or mapping) tools which allow programmers to specify
transformation rules applicable to a simple GUI drag-and-drop operation.

Disavanteges
The primary disadvantage of many message-oriented middleware systems is that they
require an extra component in the architecture, the message transfer agent (message broker).
As with any system, adding another component can lead to reductions in performance and
reliability, and can also make the system as a whole more difficult and expensive to maintain.
In addition, many inter-application communications have an intrinsically synchronous
aspect, with the sender specifically wanting to wait for a reply to a message before continuing
(see real-time computing and near-real-time for extreme cases). Because message-based
communication inherently functions asynchronously, it may not fit well in such situations.
That said, most MOM systems have facilities to group a request and a response as a single
pseudo-synchronous transaction.
With a synchronous messaging system, the calling function does not return until the
called function has finished its task. In a loosely coupled 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, a combination of the two kinds of systems is required
to obtain the desired behavior.

References

1. https://www.cl.cam.ac.uk/teaching/1011/CDSysII/12-middleware.pdf
2. https://www.whishworks.com/blog/mulesoft/message-oriented-middleware
3. http://courses.ischool.berkeley.edu/i206/f97/GroupB/mom/what_is_mom.html