Advanced
We recommend Middleware as prerequisite reading for this technology description.
Message-oriented middleware (MOM)
is a client/server infrastructure that increases the
interoperability,
portability, and
flexibility of
an application by allowing the application to be distributed over multiple
heterogeneous platforms. It reduces the
complexity of developing
applications that span multiple operating systems and network protocols by
insulating the application developer from the details of the various operating
system and network interfaces- Application
Programming Interfaces (APIs) that extend across diverse platforms and
networks are typically provided by the MOM
[Rao 95].
Message-oriented middleware, as shown in Figure 22
[Steinke 95], is software that resides in both portions of a client/server
architecture and typically supports asynchronous calls between the client and
server applications. Message queues provide temporary storage when the
destination program is busy or not connected. MOM reduces the involvement of
application developers with the
complexity of the master-slave nature of the client/server mechanism.
Figure 22: Message-Oriented Middleware
MOM increases the flexibility of an architecture by enabling applications to exchange messages with other programs without having to know what platform or processor the other application resides on within the network. The aforementioned messages can contain formatted data, requests for action, or both. Nominally, MOM systems provide a message queue between interoperating processes, so if the destination process is busy, the message is held in a temporary storage location until it can be processed. MOM is typically asynchronous and peer-to-peer, but most implementations support synchronous message passing as well.
MOM is most appropriate for
event-driven applications. When an event occurs, the client application
hands off to the messaging middleware application the responsibility of
notifying a server that some action needs to be taken. MOM is also well-suited
for
object-oriented systems
because it furnishes a conceptual mechanism for peer-to-peer communications between objects. MOM insulates developers from connectivity concerns- the application developers write to APIs that handle the complexity of the specific interfaces.
Asynchronous and synchronous mechanisms
each have strengths and weaknesses
that should be considered when designing any specific application. The
asynchronous mechanism of MOM, unlike
Remote
Procedure Call (RPC) , which uses a a synchronous, blocking mechanism,
does not guard against overloading a network. As such, a negative aspect of
MOM is that a client process can continue to transfer data to a server that is
not keeping pace. Message-oriented middleware's use of message queues,
however, tends to be more flexible than RPC-based systems, because most
implementations of MOM can default to synchronous and fall back to
asynchronous communication if a server becomes unavailable
[Steinke 95].
Implementations of MOM first became available in the mid-to-late 1980s. Many
MOM implementations currently exist that
support a variety of protocols and operating systems. Many implementations support multiple protocols and operating systems simultaneously.
Some vendors provide tool sets to help extend existing interprocess communication across a heterogeneous network.
MOM is typically implemented as a proprietary product, which means MOM implementations are nominally incompatible with other MOM implementations. Using a single implementation of a MOM in a system will most likely result in a dependence on the MOM vendor for maintenance support and future enhancements. This could have a highly negative impact on a system's flexibility, maintainability, portability, and interoperability.
The message-oriented middleware software (kernel) must run on every platform of a network. The impact of this varies and depends on the characteristics of the system in which the MOM will be used:
- Not all MOM implementations support all operating systems and protocols. The flexibility to choose a MOM implementation may be dependent on the chosen application platform or network protocols supported, or vice versa.
- Local resources and CPU cycles must be used to support the MOM kernels on each platform. The performance impact of the middleware implementation must be considered; this could possibly require the user to acquire greater local resources and processing power.
- The administrative and maintenance burden would increase significantly for
a
network manager
with a large distributed system, especially in a mostly heterogeneous system.
- A MOM implementation may cost more if multiple kernels are required for a heterogeneous system, especially when a system is maintaining kernels for old platforms and new platforms simultaneously.
Other infrastructure technologies that allow the distribution of processing across multiple processors and platforms are
MOM can be effectively combined with remote procedure call (RPC) technology-RPC can be used for synchronous support by a MOM.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Rao 95]
|
Rao, B.R. "Making the Most of Middleware." Data Communications
International 24, 12 (September 1995): 89-96.
|
|
[Steinke 95]
|
Steinke, Steve. "Middleware Meets the Network."
LAN: The Network Solutions Magazine 10, 13 (December 1995): 56.
|
Cory Vondrak, TRW, Redondo Beach, CA
Ed Morris, SEI
10 Jan 97 (original)
