Compare and Contrast Between RPC and MOM

Malik Mustafa Ibraheem Y.Y. Ahmaro Ahmad Al-Ahmad

Researcher Researcher Researcher
UUM-University UiTM, Shah Alam- Malaysia Yarmouk University
Malikjwarneh@yahoo.com Ibraheem.ahmaro@hotmail.com Ahmad.salah.85@gmail.com


Abstract:

Messaging system found from 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.

Introduction to Messaging
Systems:

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.



Applications distributed on different
network nodes use the application
interface to communicate without having
to be concerned neither 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
applications 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,
where as 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. As mentioned
before, in these 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.
Message-Oriented Middleware
(MOM):

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. APIs that
extend across diverse platforms and
networks are typically provided by the
MOM.
MOM is software that resides in both
portions of 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.

Characteristics of Message-Oriented
Middleware (MOM)
The primary characteristics of Message-
Oriented Middleware are:

Messages can either be sent
synchronously or asynchronously.
Synchronous messages require the
application to send a message and
receive a positive acknowledgement
from the receiving application before it
processes the next transaction. By also
allowing asynchronous transmissions, the
Middleware frees the sending application
from waiting for the response. It can
continue to process at its own speed.
Message delivery is guaranteed since the
Middleware accepts ownership for a
message and controls its progress until it
is complete.
MOM has been designed to operate on
multiple platforms, such as UNIX, NT,
IBM MVS, etc. This permits
interoperability between applications that
run on totally different platforms.
Messages can be sent with different
priority classifications so that the
receiving system can process the
transactions in the order that is important
to it, rather than in the order that the
messages were sent.
Messages can be sent as broadcasts,
where a sending application creates one
message that is received by multiple
systems.

Message Oriented Middleware
(3) Types:
I. Message Passing: Allows instructions
and requests to be passed directly
between 2 applications in the form of
messages, which may contain either data
or control information. Message passing
may be either synchronous or
asynchronous, but it is always connection
oriented (i.e.: a logical connection must
be formed between the 2 applications
using message passing).
Advantages:
A. Supports both synchronous and
asynchronous communication.
B. Works well for event driven
transactions.
Disadvantages:
A. Lacks standards.
B. Connection oriented nature makes it a
poor choice for loosely coupled time
independent applications.
II. Message Queuing: Message Queuing
allows applications to communicate
through the use of message queues
instead of having to send messages
directly from application to application.
This allows 2 applications
communicating via message queues to
run independently at their own rate while
still insuring that requests are fulfilled.
This makes message queuing
asynchronous and connectionless by
nature.



Advantages:
A. Support for a range of QoS
levels.
B. Can provide limited support for
transaction processing.
C. Can provide support for triggers
and network session concentration
which can limit the amount of
resources used

Disadvantages:
A. Lack of standards.
B. Can only support transactions
that occur in the message queues
which it manages.

III. Publish and Subscribe: Breaks
out of the current client/server
model by allowing computers to be
either publishers who offer data or
subscribers who consume the
data. Publish subscribe helps to
maximize communications
efficiency because publishers do not
need to receive requests from
clients. When a publisher changes
its data offerings, the data is
automatically collected by all
subscribers who are interested in it.
This allows for a high degree of
dynamic reconfiguration in
publish/subscribe systems.


Advantages:
A. Provides for rapid and dynamic
system reconfiguration
B. Can minimize resource usage
through the use of multicasting
C. Systems do not need to even be
aware of each others existence.
Disadvantages:
A. Does not support transactions.
B. Does not support traditional
client/server request/reply type
application architectures.
C. Does not support synchronous
communication.

Examples
I. Message passing:
1. PeerLogic PIPES
2. Aspen Systems MPI/Pro.
II. Message Queuing
1. BEA systems DecmesageQ
2. IBM MQSeries.
3. Microsoft MSMQ.
III. Publish / Subscribe
1. RTI NDDS

Remote Procedure Call

RPC Based Middleware functions
by allowing a client computer to
execute a procedure on a remote
server computer as if it were a
local procedure. This is managed by
what are called stubs. A stub is a
placeholder procedure that invokes
an actual business application at the
server level. The stub is
standardized so that writing a client
to call it is a simple process which
can invoke a much more complex
procedure at the server level. The
server returns the results of this
procedure by calling client stubs
which activate routines on the client
which receive the results from the
server. RPCs are known as a
synchronous blocking type of
architecture because once the client
calls a stub procedure on the server,
it is blocked from calling anymore
procedures until is receives the
results of the last call from the
server. This synchronous blocking
communication alleviates problems
of synchronization.


Advantages:
1. Automatic Data type Format
Conversion
2. Allows programming in an
applications native APIs
3. DCE provides a standard for the
use of RPCs

Disadvantages:
1. Compiled nature of IDL lacks
flexibility
2. No support for asynchronous
communication
3. Relies heavily on TCP/IP
transport protocols

Compares and Contrasts wWith
Example:

1. Web-based messaging
(Exchange Server 2007) As
RPC :
Microsoft Exchange Server 2007
incorporates features that enable
enterprises to effectively meet these
challenges without fundamentally
altering the traditional methods used
by end users to access e-mail. This
article highlights some of these
features, discussing the core
architecture, mailbox data access,
and secures deployment components
of Exchange Server 2007.
Web-based messaging is enabled
by OWA and the Outlook
Anywhere feature. OWA provides
Web browserbased access to
mailbox data, and Exchange Server
2007 provides enhanced browser-
based functionality that includes
access to Unified Messaging data,
HTML data conversion, and
reduced local client data storage to
enhance security. OWA also
provides access to Windows Share
Point Services and Windows file
shares. This feature requires Internet
connectivity through a Web
browser, but not an Outlook client.
The Outlook Anywhere feature
provides Outlook client connectivity
to Exchange Server 2007 through
the Internet, without requiring a
connection to an internal enterprise
network; in Exchange Server 2003,
similar functionality was referred to
as RPC over HTTP. The Client
Access server role hosts the services
and functionality required for OWA
and Outlook Anywhere support, and
facilitates the access of OWA Web
browser clients and remote Outlook
clients to data hosted on Exchange
Server 2007 Mailbox servers.


2. JMS as a MOM Standard
The Java Messaging Service
specification was originally
developed to allow Java applications
access to existing MOM systems.
Since its introduction, it has been
adopted by many existing MOM
vendors and it has been
implemented as an asynchronous
messaging system in its own right.
In creating the JMS specification, its
designers wanted to capture the
essential elements of existing
messaging systems. These included:
The concept of a messaging
provider that routes and delivers
messages.
Distinct messaging patterns or
domains such as point-to-point
messaging and publish/subscribe
messaging.
Facilities for synchronous and
asynchronous message receipt.
Support for reliable message
delivery.
Common message formats such as
stream, text, and byte.
Vendors implement the JMS
specification by supplying a JMS
provider consisting of libraries that
implement the JMS interfaces, of
functionality for routing and
delivering messages, and of
administrative tools that manage,
monitor, and tune the messaging
service. Routing and delivery
functions can be performed by a
centralized message server or
broker, or they could be
implemented through functionality
that is part of each clients runtime.
Equally, a JMS provider can play a
variety of roles: it can be created as
a stand-alone product or as an
embedded component in a larger
distributed runtime system. As a
standalone product, it could be used
to define the backbone of an
enterprise application integration
system; embedded in an application
server, it could support inter-
component messaging. For example,
J2EE uses a JMS provider to
implement message-driven beans
and to allow EJB components to
send and receive messages.
To have created a standard that
included all features of existing
systems would have resulted in
system that was hard to learn and
difficult to implement. Instead, JMS
defined a least common
denominator of messaging concepts
and features. This resulted in a
standard that is easy to learn and
that maximizes the portability of
JMS applications across JMS
providers. Its important to note that
JMS is an API standard, not a
protocol standard. It is easy to move
a JMS client from one vendor to
another. But different JMS vendors
typically cannot communicate
directly with one another.

MOM vs. RPC contrast diagram:




Reference
1. JMS as a MOM Standard, Sun Java
System Message Queue 4.1
Technical Overview September
2007.
2. Understanding the Architecture and
Features of Microsoft Exchange
Server 2007, By Ananda Sankaran
Suman Kumar Singh.
3. Software Engineering and
Middleware, Wolfgang Emmerich,
University College London.
4. Message-oriented middleware
(MOM),
http://en.wikipedia.org/wiki/Mes
sage_Oriented_Middleware,
14/9/2009.
5. Remote procedure call (RPC),
http://en.wikipedia.org/wiki/Rem
ote_procedure_call, 14/9/2009.
6. Middleware Architecture,
http://ils.unc.edu/~cuevacha/inls2
58/categories.html,14/9/2009.
7. MOM vs. RPC, Communication
Models for Distributed Applications,
Daniel A. Menasc George Mason
University.