Edward Curry National University of Ireland, Galway, Ireland
As software systems continue to be distributed deployments over ever-increasing scales, transcending geographical, organizational, and traditional commercial boundaries, the demands placed upon their communication infrastructures will increase exponentially. Modern systems operate incomplex environments with multiple programming languages, hardware platforms, operating systems and the requirement for dynamic ﬂexible deployments with 24/7 reliability, high throughput performance and security while maintaining a high Quality-of-Service (QoS). In these environments, the traditional direct Remote Procedure Call (RPC) mechanisms quickly fail to meet the challenges present. Inorder to cope with the demands of such systems, an alternative to the RPC distribution mechanism has emerged. This mechanism called Message-Oriented Middleware or MOM provides a clean method of communication between disparate software entities. MOM is one of the cornerstone foundations that distributed enterprise systems are built upon. MOM can be deﬁned as any middleware infrastructure that providesmessaging capabilities. A client of a MOM system can send messages to, and receive messages from, other clients of the messaging system. Each client connects to one or more servers that act as an intermediary in the sending and receiving of messages. MOM uses a model with a peer-to-peer relationship between individual clients; in this model, each peer can send and receive messages to and fromother client peers. MOM platforms allow ﬂexible cohesive systems to be created; a cohesive system is one that allows changes in one part of a system to occur without the need for changes in other parts of the system. 1.1.1 Interaction Models Two interaction models dominate distributed computing environments, synchronous and asynchronous communication. This section introduces both interaction models; asolid
Middleware for Communications. Edited by Qusay H. Mahmoud 2004 John Wiley & Sons, Ltd ISBN 0-470-86206-8
Caller Call Remote Procedure
Caller is blocking and must wait for control to return
Remote Procedure Returns
Figure 1.1 Synchronous interaction model
knowledge of these models and the differences between them is key tounderstanding the beneﬁts and differences between MOM and the forms of distribution available. 1.1.2 Synchronous Communication When a procedure/function/method is called using the synchronous interaction model, the caller code must block and wait (suspend processing) until the called code completes execution and returns control to it; the caller code can now continue processing. When using thesynchronous interaction model, as illustrated in Figure 1.1, systems do not have processing control independence; they rely on the return of control from the called systems. 1.1.3 Asynchronous Communication The asynchronous interaction model, illustrated in Figure 1.2, allows the caller to retain processing control. The caller code does not need to block and wait for the called code to return. This modelallows the caller to continue processing regardless of the processing state of the called procedure/function/method. With asynchronous interaction, the called code may not execute straight away. This interaction model requires an intermediary to handle the exchange of requests; normally this intermediary is a message queue. While more complex than the synchronous model, the asynchronous modelallows all participants to retain processing independence. Participants can continue processing, regardless of the state of the other participants. 1.1.4 Introduction to the Remote Procedure Call (RPC) The traditional RPC model is a fundamental concept of distributed computing. It is utilized in middleware platforms including CORBA, Java RMI, Microsoft DCOM, and XML-RPC. The objective of RPC is to...