Download lecture8

Chapter 9 – RPCs, Messaging &
EAI
Message-Oriented Middleware (MOM) and RPCs based middleware
tend to be traditional, point-to-point middleware. Because of that,
they are not effective solutions for most EAI projects.
Middleware itself is a common point of integration for source and
target systems. Despite the limitations of this technology for EAI
solutions, the appropriate tradeoffs in both technology and
product decisions may make the inclusion of this middleware
important to a particular EAI problem domain.
RPCs
RPCs are a method of communicating with a remote computer, in
which the developer invokes a procedure on the server by making
a simple function call on the client (see Fig. 9.1)
Fig. 9.1 Using RPCs
The client process that calls the function must suspend itself
until the procedure is completed.
This blocking of an application might become a problem for the
performance of that application. Also there is a high level of
network communication between the client and the server
when using RPCs, thus the RPC architecture requires a highspeed network.
RPCs were the base middleware layers of the early client/server
systems. In addition to many database-oriented middleware
layers, they are capable of running network operating
systems, such as Sun’s NFS (Network File System) and DCE
(from Open Software Foundation)
Distributed object technology, such as COM and CORBA,
leverage RPCs effectively in order to provide object-toobject communications.
DCE
DCE is complex (but effective) middleware solution. It was
developed by OSF and it makes many diverse computers
function as a single virtual system – excellent for
distributed computing.
Fig. 9.2 The DCE Architecture
Because the heart of DCE is a classic RPC mechanism, every
limitation inherent in RPCs - including blocking and the
need for a high speed network – also exist in DCE.
But, DCE allows developers to reach across platforms to access
many types of application services, including database,
distributed objects, and TP monitors.
DCE also provides a sophisticated naming service, a
synchronization service, a distributed file system, and builtin network security. Another plus is that DCE is available on
almost any platform.
MOMs
If the required bandwidth is not available for use with an RPC
middleware, or in the situation where a server cannot be
depended upon to always be up and running, messageoriented middleware (MOM) is more advisable than any
other type of middleware.
Fig. 9.3 Using MOMs
Like RPCs, MOM provides a standard API across hardware,
operating system platforms and networks. It is also able to
guarantee that messages will reach their destination, even
when the destination is not available (meaning the server is
not on line, the application is not started, application
crushed, etc)
MOM utilizes one of the two macro-messaging models
1. Process-to-Process  both the sending and receiving
processes must be active for messages to be exchanged
2. Message Queuing  allows messages to be stored in a
queue, so only one process needs to be active (the sender
process). This method is the most beneficial when
communication is taking place between computers that are
not always up and running, over networks that are not
always dependable, or when there is a limitation on
bandwidth.
Unlike RPCs, MOM is asynchronous, thus it doesn’t block the
application from processing when the middleware API is
invoked.
MOM message functions can return immediately even though
the request has not actually been completed. This allows
the application to continue processing, assured that it will
know when the request is completed.
The queuing model is the most useful from transactionsoriented EAI applications that must transverse multiple
platforms.
Unlike DCE, the platform does not have to be up and running
for an application to request services. If the server is down
the request remains in queue. When the server comes back
online, the request will be processed.
In addition to these features, MOM provides concurrent
execution features, allowing the processing of more than
one request at the same time.
In conclusion, MOM is a good fit for store-and-forward
communications or when dealing with applications that are
not expected to be reachable at the same time.
MOM is also good for “defensive” communication, or when the
network between applications fails a lot. Also it’s a good
option for when communications between processes need
to be logged.
MOM and messaging tend to be better EAI fits than RPC based
middleware, but MOM alone does not provide all the
infrastructure necessary for EAI.
Message Brokers add value to traditional MOM products by
providing data and schema transformation function, as well
as intelligent routing and event-driven processing to move
information on an enterprise network. (see Fig. 9.4)
Fig. 9.4 Message Brokers using MOM
Microsoft Message Queue (MSMQ)
It’s a Windows NT/2000 based and COM enabled MOM. It is
also a key product for Microsoft as it joints the Microsoft
Transaction Server (MTS), Internet Information Server (IIS),
SQL Server, and Microsoft’s Active Platform.
MSMQ provides a set of Active X components that implements
an API to all MSMQ features. Active X allows these other
Microsoft products to access MSMQ.
MSMQ can guarantee the delivery of messages by utilizing disk
based intermediary storage and log-based recovery
techniques. Some of the protocols MSMQ works well with
are IPX/SPX and TCP/IP. Using MSMQ as a common
translation mechanism these protocols can even be mixed
and matched.
MSMQ is tightly integrated with MTS and MTS services
participate in the MSMQ transaction.
Some of the MSMQ features are:
1. On time, in order delivery of messages from source to
destination
2. Message-routing services, which give the EAI applications
the ability to send messages to their destination using
least-cost routing
3. Notification services, which informs the sender that the
message was received and processed.
4. Message priorities, which allow developers to assign
priorities to messages.
5. Journaling, which maintains copies of the messages moving
in the system.
Using MSMQ
When an application needs to place a message in the queue, it
uses the MSMQ Open API, which has an Active X control
wrapped around it. By passing in, the name and destination
queue, a queue handle is created, allowing the MSMQ to
identify the destination queues to the MSMQ server sending
the message.
Once a queue handle has been created, the next step is to
create a message by allocating local memory and adding
information to the message. At this step, parameters (timeout values, names of response queues, priorities, etc) can
be added. The message is then sent through the MSMQ
“Send API”. Finally the application closes the queue handle
using the MSMQ “Close API” function (MQCloseQueue).
The receiver application requires the Open API, along with
queue identification information, to create the queue
handle. When calling the MSMQ Receiver API, MSMQ will
pass back a pointer with control information to the
message.
After receiving the information, the application will close the
connection to the queue.
Fig. 9.5 The Architecture of MSMQ
IBM MQSeries
IBM has over 65% of the middleware market and although is not
the best of the message middleware software, the IBMs
MQSeries is at the top of the EAI world as the preferred
messaging layer for moving information through an
enterprise network.
MQSeries support a variety of platforms working with IBM
OS/390, Pyramid, Open VMS, IBM AIX, NCR UNIX, Solaris,
Windows NT, MacOS, etc.
MQseries supports all the features of MSMQ, including support
for transactions, journaling, message routing and priorities.
It also provides a common API for use across a variety of
development environments and on a variety of platforms.
The interesting thing is that MQSeries provides a single
multiplatform API, so messages can be sent from a
Windows 2000 computer and routed via UNIX, VMS, etc,
before reaching their final destination.
MQSeries can also be used as a transactional recovery method
and a mail transport mechanism, assuring the delivery of
the message.
Fig. 9.6 MQSeries MOM
MQSeries supports what IBM calls “advanced message
framework”, a framework that consists of 3 layers:
1. Customer Application Options
2. Trusted Messaging Backbone
3. Comprehensive Communications Choices
Fig. 9.7 The 3 Layers of MQSeries
1. Customer Application Options  provide services such as
basic messaging, transactional messaging, workflow
computing, mail messaging, option messaging, cooperative
processing, data replication and mobile messaging.
2. Trusted Messaging Backbone  guarantees that messages
are delivered to their destinations and that the information
encapsulated in those messages is secure.
3. Comprehensive Communications Choices  allow MQSeries
to leverage any number of protocols and networks for
message traffic.
MQSeries Features
- Database-message resource coordination (DMRC)
- Smart message distribution
- Supports NT/2000 & OS/2
- SQL support
- Ability to support large message