ActiveMQ in Action-7.3 Implementing request/reply with JMS- 高飞网

7.3 Implementing request/reply with JMS

——使用JMS实现请求/应答

2016-06-07 22:43:01.0

7.3 使用JMS实现请求/应答

    正如前面章节中描述的那样,消息框架是发送者与接收者之间的解耦。消息由一个进程发送到服务端,而又以异步的方式通过另一个进程从服务端接收。有种称为请求/应答类型的系统架构可以通过JMS来实现。从一个高级别来看,请求应答的场景涉及这样的一个应用,它发送消息(请求),并且期望收到一条消息作为返回(应答)。这种系统习惯上会使用客户端-服务器架构来实现,通过网络(TCP,UDP等)在客户端与服务端之间进行同步的通信。当然这种的架构有其在扩展上的局限性,在未来它难以分散部署。这就是消息系统所涉及的地方——基于消息系统请求/应答模式,提供可以一个轻松扩展系统的能力。而世界上多数的可扩展系统都是通过像示例中的异步处理来实现的。

    图7.2中演示了请求/应答范例的预览。注意其中的客户端包括生产者和消费者。这两个实体稍后都会解释。    


    首先,生产者使用JMS消息格式创建一个请求,并设置了两个重要的属性——关联ID(通过JMSCorrelationID消息属性设置)和应答目的(通过JMSReplyTo属性设置)。关联ID很重要,因为当有很多为完成的请求时,它可以用来将请求和应答关联起来。而应答目的地是指应答期望传输到(通常是一个临时的JMS目的,因为资源更友好)的地方。客户端配置了一个消费者监听者应答目的。

    其次,工作站接收到该请求,然后处理它,并使用请求消息中属性JSMReplyTo的值为目的地发送一个应答消息。应答消息也必须用原始请求的关联ID设置JMSCorrelationID。当客户端接收到应答消息以后,然后它可以把应答与原来的请求关联起来。

    现在进入最有趣的部分——验证该架构如何能更好地扩展。设想一下,一个工作站诚然不足以应付所有的请求。没问题:尽管加入更多的工作站来处理。这些工作站甚至可以跨越多个主机进行部署——这是这个扩展设计的最重要的一方面。由于业务端并不会在一个主机上竞争相同的资源,仅有的限制就是服务端的消息总量的极限,而这远优于你用传统的客户端服务端的架构。此外,ActiveMQ可以纵横扩展,像第4部分描述的那样。让我们看一下请求/应答的一个简单实现。

7.3.1 实现服务端和工作站