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.