Message oriented middleware
Message oriented middleware (MOM) is software or hardware infrastructure supporting the sending and receiving of messages between distributed systems. Because 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. 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 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.[1]
Middleware categories
- Remote Procedure Call or RPC-based middleware
- Object Request Broker or ORB-based middleware
- Message Oriented Middleware or MOM-based middleware
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, whereas 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. In these synchronous messaging 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.[2]
Advantages
- Using a MOM system, a client makes an API call to send a message to a destination managed by the provider. The call invokes provider services to route and deliver the message. Once it has sent the message, the client can continue to do other work, confident that the provider retains the message until a receiving client retrieves it. The message-based model, coupled with the mediation of the provider, makes it possible to create a system of loosely coupled components.
- An advantage of messaging provider mediated messaging between clients is that by adding an administrative interface, you can monitor and tune performance. Client applications are thus effectively relieved of every problem except that of sending, receiving, and processing messages. It is up to the code that implements the MOM system and up to the administrator to resolve issues like interoperability, reliability, security, scalability, and performance.
Disadvantages
- loose coupling - With a synchronous messaging system, the calling function does not return until the called function has finished its task. In an asynchronous system, the calling client can continue to load work upon the recipient until the resources needed to handle this work are depleted and the called component fails. Of course, these conditions can be minimized or avoided by monitoring performance and adjusting message flow, but this is work that is not needed with a synchronous messaging system. The important thing is to understand the advantages and liabilities of each kind of system. Each system is appropriate for different kinds of tasks. Sometimes, you will need to combine the two kinds of systems to obtain the exact behavior you need.
Message queuing
Message Queuing technology allows the exchange of information between distributed applications. A message queue can reside in memory or disk storage. Messages stay in the queue until the time they are processed by a service consumer. Through the message queue, the application can be implemented independently - they do not need to know each other's position, or continue to implement procedures to remove the need for waiting to receive this message.[3]
In the distributed computing environment, in order to integrate distributed applications, developers need for a heterogeneous network environment of distributed applications to provide an effective means of communication. In order to manage the need to share information, on the application of the provision of public information exchange mechanism is important.
Design methods of distributed applications include: Remote Procedure Call (RPC) - Distributed Computing Environment (DCE), one of the basis of standard components; Object Transaction Monitor (OTM) - based on the CORBA object-oriented transaction processing with industry-standard (TP) a combination of monitoring technology; message queue (MessageQueue) - Construction of loosely coupled distributed application methods.
(a) Distributed Computing Environment / Remote Procedure Call (DCE / RPC)
RPC is the composition of DCE, is an Open software foundation (OSF) released software application integration standards. RPC function to imitate a program used to invoke another program of traditional programming methods, this reference is a form of procedure call, once called, the program will turn the control process is called.[4]
The realization of the RPC, the process is called local or remote in the other systems and in the implementation of presence. When the procedure is called to complete the processing of input data, resulting in the return on the procedure call to return to the variables in the procedure call. RPC program immediately after the completion of return to the calling procedure. Therefore, mimic RPC subroutine call / return structure, it only provides a Client (call procedure) and Server (called process) synchronization between the data exchange.
(b) Object Transaction Monitor (OTM)
CORBA-based object-oriented and industry-standard transaction processing (TP) a combination of monitoring technology in the CORBA specification is defined: the use of object-oriented technology and methods of architecture; public Client / Server Programming Interface; multi-platform inter-transmission and guidelines for the translation of data; the development of distributed application interface language (IDL), and for the structural distribution of Client / Server applications provide a broad and consistent pattern.[5]
(c) Message Queue (Message Queue)
Message queue for the structure to synchronous or asynchronous means of loosely coupled distributed applications methods. Message Queue API call is embedded into new or existing applications, through the message is sent to memory or disk-based queue or read from it to provide information exchange. Message Queuing can be used in applications to perform multiple functions, such as request for service, the exchange of information or asynchronous processing.
Middleware is a system independent of software or service program, distributed applications using the software between the different technologies in the shared resources, management, communication and network computing resources. It in the computer system is a key software applications that it can achieve interconnection and interoperability, to ensure the system is safe, reliable, efficient operation. Located in the user applications and middleware and network operating system software, which will provide a common means of communication, and independent of the network and operating system. For the development of middleware to provide the public and the environment for all the Application Programming Interface, when embedded in the application of its function call, it can be run using its operating system and network environment-specific functions, communications functions for the application execution.[6]
Message-Oriented Middleware completed if there is no exchange of information, application developers in order to transmit data, it is necessary to learn how to use the network and operating system software, to prepare the appropriate applications to send and receive information, and there is no standard method to exchange information, each application must be specific and multi-platform programming and thus, under different circumstances one or more application communications. For example, in order to achieve different network communication between the host system will be required to have on the network's knowledge of how the exchange of information (such as the use of TCP / IP the socket programming); In order to achieve the same host in the communication between different processes, will require with the operating system message queue, or Named Pipes knowledge.[7]