Chapter 9 RPCs Messaging EAI MessageOriented Middleware MOM

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 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 high -speed 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 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 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 (MQClose. Queue). 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, Mac. OS, 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