1.3 消息传送模型
Messaging Models
JMS支持两类消息传送模型：点对点模型和发布/订阅模型。有时候，又称这些消息传送模型为消息传送域。点对点消息传送模型和发布/订阅消息传送模型经常分别缩写为p2p和Pub/Sub。在本书中，这二者的原文和缩写都会用到。
简而言之，发布/订阅模型设计用于一对多（one-to-many）消息广播，而点对点模型则设计用于一对一（one-to-one）消息传送（参见图1-4）。
[img]http://dl.iteye.com/upload/attachment/526165/95d8eac1-2c22-39ac-9c2e-6371fe573872.gif[/img]
从JMS的视角来看，消息传送客户端称为JMS客户端（JMS client)，而消息传送系统则称为JMS提供者（JMS provider）。一个JMS应用程序是由多个JMS客户端和（通常是）一个JMS提供者所组成的业务系统。
此外，生产消息的JMS客户端称为消息生产者（message producer），而接收消息的JMS客户端则称为消息消费者（message consumer）。一个JMS客户端可以既是消息生产者，又是消息消费者。当我们使用术语消费者（consumer）或生产者（producer）时，我们分别是指消费或生产消息的一个JMS客户端。在全书中，我们都会用到这个术语。
1.3.1 点对点模型
Point-to-Point
点对点消息传送模型允许JMS客户端通过队列（queue）这个虚拟通道来同步和异步发送、接收消息。在点对点模型中，消息生产者称为发送者（Sender），而消息消费者则称为接收者（receiver）。传统上，点对点模型是一个基于拉取（Pull）或基于轮询（polling）的消息传送模型，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。点对点消息传送模型的一个突出特点就是：发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。
点对点消息传送模型既支持异步“即发即弃（fire and forget）”消息传送方式，又支持同步请求/应答消息传送方式。点对点消息传送模型比发布/订阅模型具有更强的耦合性，发送者通常会知道消息将被如何使用，而且也会知道谁将接收该消息。举例来说，发送者可能会向一个队列发送一个证券交易订单并等待响应，响应中应包含一个交易确认码。这样一来，消息发送者就会知道消息接收者将要处理交易订单。另一个例子就是一个生成长时间运行报告的异步请求。发送者发出报告请求，而当该报告准备就绪时，就会给发送者发送一条通知消息。在这种情况下，发送者就会知道消息接收者将要处理该消息并创建报告。
点对点模型支持负载均衡，它允许多个接收者侦听同一队列，并以此来分配负载。如图1-4所示，JMS提供者负责管理队列，确保每条消息被组内下一个可用的接收者消费一次，而且仅仅一次。JMS规范没有规定在多个接收者中间分发消息的规则，尽管某些JMS厂商已经选择实现此规则来提升负载均衡能力。点对点模型还具有其他优点，比如说，队列浏览器允许客户端在消费其消息之前查看队列内容——在发布/订阅模型中，并没有这种浏览器的概念。第4章会详细介绍点对点消息传送模型的更多细节。
1.3.2 发布/订阅模型
Publish-and-Subscribe
在发布/订阅模型中，消息会被发布到一个名为主题（topic）的虚拟通道中。消息生产者称为发布者（publisher），而消息消费者则称为订阅者（subscriber）。与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。有时候，也称这项技术为广播（broadcasting）消息。每个订阅者都会接收到每条消息的一个副本。总地来说，发布/订阅消息传送模型基本上是一个基于推送（push）的模型，其中消息自动地向消费者广播，它们无须请求或轮询主题来获得新消息。
发布/订阅模型的去耦能力要比p2p模型更强，消息发布者通常不会意识到有多少订阅者或那些订阅者如何处理这些消息。举例来说，假定每次在Java应用程序发生异常时，向一个主题发布一条消息。发布者的责任仅仅是广播发生了一个异常。该发布者不会知道，或者说通常也不关心如何使用该消息。例如，有可能是订阅者根据该异常向开发人员或支持人员发送了一封电子邮件，也有可能是订阅者收集不同类型的异常数目用于生成报告，甚至是订阅者根据异常的类型，使用这个信息来通知随叫随到（on-call）的技术支持人员。
在发布/订阅消息传送模型内部，有多种不同类型的订阅者。非持久订阅者是临时订阅类型，它们只是在主动侦听主题时才接收消息。而另一方面，持久订阅者将接收到发布的每条消息的一个副本，即便在发布消息，它们处于“离线”状态时也是如此。另外还有动态持久订阅者和受管的持久订阅者等类型。第2章和第5章会详细讨论发布/订阅消息传送模型的更多细节
Messaging Models
JMS支持两类消息传送模型：点对点模型和发布/订阅模型。有时候，又称这些消息传送模型为消息传送域。点对点消息传送模型和发布/订阅消息传送模型经常分别缩写为p2p和Pub/Sub。在本书中，这二者的原文和缩写都会用到。
简而言之，发布/订阅模型设计用于一对多（one-to-many）消息广播，而点对点模型则设计用于一对一（one-to-one）消息传送（参见图1-4）。
[img]http://dl.iteye.com/upload/attachment/526165/95d8eac1-2c22-39ac-9c2e-6371fe573872.gif[/img]
从JMS的视角来看，消息传送客户端称为JMS客户端（JMS client)，而消息传送系统则称为JMS提供者（JMS provider）。一个JMS应用程序是由多个JMS客户端和（通常是）一个JMS提供者所组成的业务系统。
此外，生产消息的JMS客户端称为消息生产者（message producer），而接收消息的JMS客户端则称为消息消费者（message consumer）。一个JMS客户端可以既是消息生产者，又是消息消费者。当我们使用术语消费者（consumer）或生产者（producer）时，我们分别是指消费或生产消息的一个JMS客户端。在全书中，我们都会用到这个术语。
1.3.1 点对点模型
Point-to-Point
点对点消息传送模型允许JMS客户端通过队列（queue）这个虚拟通道来同步和异步发送、接收消息。在点对点模型中，消息生产者称为发送者（Sender），而消息消费者则称为接收者（receiver）。传统上，点对点模型是一个基于拉取（Pull）或基于轮询（polling）的消息传送模型，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。点对点消息传送模型的一个突出特点就是：发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。
点对点消息传送模型既支持异步“即发即弃（fire and forget）”消息传送方式，又支持同步请求/应答消息传送方式。点对点消息传送模型比发布/订阅模型具有更强的耦合性，发送者通常会知道消息将被如何使用，而且也会知道谁将接收该消息。举例来说，发送者可能会向一个队列发送一个证券交易订单并等待响应，响应中应包含一个交易确认码。这样一来，消息发送者就会知道消息接收者将要处理交易订单。另一个例子就是一个生成长时间运行报告的异步请求。发送者发出报告请求，而当该报告准备就绪时，就会给发送者发送一条通知消息。在这种情况下，发送者就会知道消息接收者将要处理该消息并创建报告。
点对点模型支持负载均衡，它允许多个接收者侦听同一队列，并以此来分配负载。如图1-4所示，JMS提供者负责管理队列，确保每条消息被组内下一个可用的接收者消费一次，而且仅仅一次。JMS规范没有规定在多个接收者中间分发消息的规则，尽管某些JMS厂商已经选择实现此规则来提升负载均衡能力。点对点模型还具有其他优点，比如说，队列浏览器允许客户端在消费其消息之前查看队列内容——在发布/订阅模型中，并没有这种浏览器的概念。第4章会详细介绍点对点消息传送模型的更多细节。
1.3.2 发布/订阅模型
Publish-and-Subscribe
在发布/订阅模型中，消息会被发布到一个名为主题（topic）的虚拟通道中。消息生产者称为发布者（publisher），而消息消费者则称为订阅者（subscriber）。与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。有时候，也称这项技术为广播（broadcasting）消息。每个订阅者都会接收到每条消息的一个副本。总地来说，发布/订阅消息传送模型基本上是一个基于推送（push）的模型，其中消息自动地向消费者广播，它们无须请求或轮询主题来获得新消息。
发布/订阅模型的去耦能力要比p2p模型更强，消息发布者通常不会意识到有多少订阅者或那些订阅者如何处理这些消息。举例来说，假定每次在Java应用程序发生异常时，向一个主题发布一条消息。发布者的责任仅仅是广播发生了一个异常。该发布者不会知道，或者说通常也不关心如何使用该消息。例如，有可能是订阅者根据该异常向开发人员或支持人员发送了一封电子邮件，也有可能是订阅者收集不同类型的异常数目用于生成报告，甚至是订阅者根据异常的类型，使用这个信息来通知随叫随到（on-call）的技术支持人员。
在发布/订阅消息传送模型内部，有多种不同类型的订阅者。非持久订阅者是临时订阅类型，它们只是在主动侦听主题时才接收消息。而另一方面，持久订阅者将接收到发布的每条消息的一个副本，即便在发布消息，它们处于“离线”状态时也是如此。另外还有动态持久订阅者和受管的持久订阅者等类型。第2章和第5章会详细讨论发布/订阅消息传送模型的更多细节
扫一扫
568
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
