《ActiveMQ in Action》的笔记-第158页
- 页码：第158页 2011-10-28 23:54:01
请求回复在JMS中的实现。7.3 Implementing request/reply with JMS As described in earlier chapters, messaging is all about the decoupling of senders from receivers. Messages are sent by one process to a broker, and messages are received from a broker by a different process in an asynchronous manner. One style of system architecture that can be implemented using JMS is known as request/reply. From a high level, a request/reply scenario involves an application that sends a message (the request) and expects to receive a message in return (the reply). Traditionally, such a system design was implemented using a client-server architecture, with the server and the client communicating in a synchronous manner across a network transport (TCP, UDP, and so on). This style of architecture certainly has scalability limitations, and it’s difficult to distribute it further. That’s where messaging enters the picture—to provide the ability to design a system that can easily scale much further via a messaging-based request/reply design. Some of the most scalable systems in the world are implemented using asynchronous processing like that being demonstrated in this example. The diagram shown in figure 7.2 depicts an overview of the request/reply paradigm. Note that the client consists of both a producer and a consumer, and the worker also consists of both a producer and a consumer. These two entities are both explained next. First, the producer creates a request in the form of a JMS message and sets a couple of important properties on the message—the correlation ID (set via the JMSCorrelationID message property) and the reply destination (set via the JMSReplyTo message property). The correlation ID is important, as it allows requests to be correlated with replies if there are multiple outstanding requests. The reply destination is where the reply is expected to be delivered (usually a temporary JMS destination since it’s much more resource friendly). The client then configures a consumer to listen on the reply destination. Second, a worker receives the request, processes it, and sends a reply message using the destination named in the JMSReplyTo property of the request message. The reply message must also set JMSCorrelationID using the correlation ID from the orig- inal request. When the client receives this reply message, it can then properly associate it with the original request. Now comes the interesting part—to demonstrate how this architecture can be highly scalable. Imagine that a single worker isn’t enough to handle the load of incoming requests. No problem: just add additional workers to handle the load. Those workers can even be distributed across multiple hosts—this is the most important aspect of scaling this design. Because the workers aren’t contending for the same resources on the same host, the only limit is the maximum throughput of messages through the broker, which is much higher than you can achieve with any classic clientserver setup. Furthermore, ActiveMQ can be scaled both vertically and horizontally, as discussed in part 4. Let’s now take a look at a simple implementation of request/reply.
stephansun对本书的所有笔记 · · · · · ·
Message-oriented middleware (MOM) is best described as a category of software for communic...
Request/reply messaging in JMS applications Although the JMS spec doesnâ€™t define request...
Using the request/reply pattern, envision that there are thousands of requests entering t...
说明 · · · · · ·