Shulou(Shulou.com)06/01 Report--

Message-based Middleware MOM

The scope of middleware is very wide, and a variety of characteristic middleware products have emerged according to different application requirements. But so far, there is not a more accurate definition of middleware, so the classification of middleware will be different from different angles or different levels. Because the middleware needs to shield the heterogeneous operating systems and network protocols in the distributed environment, it must be able to provide communication services in the distributed environment, which we call the platform. Based on the difference of purpose and implementation mechanism, we divide the platform into the following main categories:

Remote procedure call (Remote Procedure Call)

Message-oriented middleware (Message-Oriented Middleware)

Object request broker (Object Request Brokers)

They can provide different forms of communication services, including synchronization, queuing, subscription, publication, broadcast and so on. Based on these basic communication platforms, various frameworks can be built to provide applications with services in different fields, such as transaction monitor, distributed data access, object transaction manager OTM and so on. The platform shields the differences of heterogeneous platforms for the upper applications, and the framework defines the system structure and standard service components of the applications in the corresponding field. Users only need to tell the events that the framework is concerned about, and then provide the code to handle these events. When an event occurs, the framework calls the user's code. The user code does not need to call the framework, and the user program does not have to care about the framework structure, the execution process, the call to the system-level API, etc., all of which are done by the framework. Therefore, the application based on middleware has good scalability, manageability, high availability and portability.

MOM message-oriented Middleware

MOM refers to the use of efficient and reliable message delivery mechanism for platform-independent data exchange, and based on data communication for distributed system integration. By providing a message passing and message queuing model, it can expand the communication between processes in a distributed environment and support multiple communication protocols, languages, applications, hardware and software platforms. At present, the popular MOM middleware products are IBM's MQSeries, BEA's MessageQ and so on. Message passing and queuing technology has the following three main characteristics:

Communication programs can run programs at different times instead of talking to each other directly on the network, but indirectly put messages into the message queue, because there is no direct connection between programs. 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; even if the target program is running, it does not mean that the message should be processed immediately.

There are no constraints on the structure of the application. In complex applications, communication programs can not only be an one-to-one relationship, but also one-to-many and many-to-one, or even the combination of the above-mentioned ways. The construction of multiple modes of communication does not increase the complexity of the application.

Program is isolated from network complexity

All the activities associated with the program putting messages into or taking messages from the message queue for communication, such as maintaining the message queue, maintaining the relationship between the program and the queue, dealing with network restart and moving messages in the network, are the tasks of MOM. Programs do not communicate directly with other programs, and they do not involve the complexity of network communication.

/ * /

JMS as a MOM (Message Oriented Middleware) standard

The Java messaging service specification was originally developed to enable Java applications to access existing MOM systems. After the introduction of this specification, it has been adopted by many existing MOM vendors and has been implemented as an asynchronous messaging system with its own functions.

When creating the JMS specification, the designer wanted to incorporate the essence of existing messaging systems. This includes:

The concept of messaging providers that route and deliver 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 streams, text, and bytes

Vendors implement the JMS specification by providing a JMS provider that consists of libraries that implement the JMS interface, message routing and delivery capabilities, and management tools to manage, monitor, and tune messaging services. Routing and delivery functions can be performed by a centralized message server or broker, or by the functions of each client runtime environment.

Similarly, the JMS provider can play a variety of roles: it can be created as an embedded component in a stand-alone product or in a large distributed runtime environment system. As a stand-alone product, it can be used to define the backbone of an enterprise application integration system; when embedded in an application server, it can support inter-component messaging. For example, J2EE uses JMS providers to implement message-driven Bean and allow EJB components to send and receive messages.

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

/ * /

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.