MOM message-oriented Middleware Message-based middleware (background research)

Message-based middleware mom

Middleware covers a wide range of applications to different needs to emerge a variety of unique middleware products. However, there is not a more precise definition of middleware so far, so the classification of middleware will be different at various angles or different levels. Since middleware needs to shield heterogeneous operating systems and network protocols in distributed environments, it must be able to provide communication services in a distributed environment, which we call the platform. Depending on the purpose and the implementation mechanism, we divide the platform into the following major categories:

Remote Procedure Call (remotes Procedure calls)
Message-oriented middleware (message-oriented middleware)
Object Request Agent (Brokers)

They can provide different forms of communication services, including synchronization, queuing, subscription publishing, broadcast, etc., on these basic communication platforms, can build a variety of frameworks, for applications to provide services in different areas, such as transaction processing monitors, distributed data access, object transaction manager OTM and so on. Platform for the upper layer of the application to shield the differences of heterogeneous platforms, and its framework defines the application in the corresponding domain system structure, standard service components, etc., the user only need to tell the framework of the event of concern, and then provide the code to deal with these events. When an event occurs, the framework invokes the user's code. User code does not need to call the framework, the user program does not have to care about the framework structure, the execution process, the system-level API calls, etc., all of which are the framework responsible for completion. Therefore, middleware-based applications have good extensibility, manageability, high availability and portability.

MOM Message-oriented middleware

MOM refers to the use of efficient and reliable messaging mechanism for platform-independent data exchange, and based on data communication for the integration of distributed systems. By providing a messaging and Message Queuing model, it extends inter-process communication in a distributed environment and supports multiple communication protocols, languages, applications, hardware, and software platforms. At present, the popular MOM middleware products are IBM MQSeries, Bea Messageq and so on. Messaging and queuing technologies have the following three main features:

The communication program can run the program at different times not directly to each other on the network, but indirectly put the message into the message queue, because there is no direct connection between the program. So they don't have to run at the same time. When a message is placed in the appropriate queue, the target program does not even need to be running at all, and even if the target program is running, it does not mean that the message is processed immediately.

There is no constraint on the structure of the application. In complex applications, communication programs can be a one-to-many relationship, as well as a single-to-many and multi-pair approach, or even a combination of the various methods described above. The construction of multiple communication methods does not add to the complexity of the application.

Program is isolated from network complexity

The program communicates messages into or out of the message queue, all activities associated with it, such as maintaining Message Queuing, maintaining relationships between programs and queues, processing network restarts, and moving messages across the network are Mom's tasks, and programs do not directly communicate with other programs. And they do not involve the complexity of network communication.

/*****************************************************************/

JMS as the MOM (Message oriented middleware) standard

The Java Messaging Service specification was originally developed to enable Java applications to access existing MOM systems. After introducing the specification, it has been adopted by many existing MOM vendors and has been implemented as an asynchronous messaging system with its own capabilities.

When creating a JMS specification, the designer wants to fuse the essence of an existing messaging system. This includes:

The concept of a messaging provider that routes and transmits messages

Different messaging modes or domains, such as point-to-point messaging and publish/subscribe messaging

Tools for receiving synchronous and asynchronous messages

Support for reliable messaging

Common message formats, such as stream, text, and bytes

The vendor implements the JMS specification by providing a JMS provider that consists of a library that implements the JMS interface, the routing and delivery of messages, and the management tools used to manage, monitor, and tune the messaging service. Routing and delivery can be performed by a centralized messaging server or proxy, or by the functionality of each client run-time environment.

Similarly, a JMS provider can play multiple roles: it can be created as an embedded component in a standalone product or in a large distributed runtime environment system. As a standalone product, it can be used to define the backbone of an enterprise application integration system, and it can support inter-component messaging when embedded in an application server. For example, Java EE implements a message-driven Bean using a JMS provider and allows the EJB component to send and receive messages.

If you create a standard that contains all the features of an existing system, it is difficult for users to understand and implement systems established through this standard. JMS defines the common characteristics of messaging concepts and functions. This makes this standard easier to master and maximizes the portability of JMS applications between JMS providers. One thing to emphasize is that JMS is an API standard, not a protocol standard. It is easy to move a JMS client from one vendor to another. However, different JMS vendors often do not communicate directly with each other.

/*****************************************************************/

MOM message-oriented Middleware Message-based middleware (background research)