沈阳婚纱照工作室排名:CometD 2.x Reference 翻译

原文地址：

              http://cometd.org/documentation/2.x/concepts

CometD 2概念

由sbordet提交的关于2011年8月23日，星期二 - 16:05。

CometD 2概念

CometD项目实现各种comet的技术，提供可伸缩的Web消息系统，可以运行在HTTP或其他新兴协议，如WebSocket的网页协议。

定义

让我们定义客户端为发起连接的实体，服务器接受连接的实体。
建立连接是持久的 - 也就是说，它仍然打开，直至任何一方决定关闭它。

典型的客户端浏览器（毕竟，我们在Web环境），但也可能是其他应用程序，如Java应用程序，浏览器插件应用程序（如Silverlight），或在任何脚本语言的脚本。

根据comet的技术，客户端可能会打开多个物理连接，连接服务器，但我们可以假设客户端和服务器之间只存在一个逻辑频道。

CometD项目使用Bayeux协议在客户端和服务器之间进行信息交流。
交换信息的单位是Bayeux message，它是JSON格式。
message包含几个字段，其中有些是Bayeux协议授权，而其他的可能由应用程序添加。
一个字段是一个键/值对，比方说message有一个foo的字段，意味着该message有一个字段，其键是字符串“foo”。

所有客户端和服务器之间交换的消息，都有一个频道领域。

有3种频道：（meta channel）元数据频道，（service channel）服务频道和（broadcast channel）广播频道。

元数据频道由Bayeux创建实现，应用程序不能创建新的元数据频道。
服务频道和广播频道是由应用程序创建的，他们可以在任何时间创建，并且很有必要。
频道是由一个字符串代表，并且类似URL路径，例如：/meta/handshake，/service/game ， /foo/bar。
一个频道以/meta/开头则它是元数据频道，一个频道以/service/开头则它是服务频道，而所有其他的频道则是广播频道。

一个消息频道领域是元数频道则里面的消息是元数据消息，同样的，有服务频道消息和广播频道消息。

高层次视图

CometD实现Web消息传递系统，特别是Web消息传递系统是基于（publish）发布/（subscribe）订阅范式的。

在（publish）发布/（subscribe）订阅消息传递系统中，publish发出消息，这些消息被赋予类的特点。Subscribe表示的是订阅他们感兴趣的一个或多个类的消息，并接收他们订阅的兴趣相匹配的唯一消息。发送消息的人，在一般情况下，不知道收件人或多个收件人将收到他们发布的消息。

在CometD中，频道领域提供已经类化的消息。
频道是CometD的中心概念：发布者把消息发送到频道里，订阅者订阅这个频道来接收消息。

这些将会在CometD API中有详细反映，我们可以去查看。

消息系统的功能之一是他们的拓扑结构， CometD实现的是枢纽发言的拓扑结构。
在默认配置下，表示有一个中央服务器（中心），并且所有客户端通过管道链接（辐条）连接到该服务器。如图：

在CometD中，服务器接受来自发布者发送的消息，如果消息的频道是一个广播频道，则服务器会转发该消息给所有订阅这个频道的订阅者。
CometD服务器的元数据消息和服务消息会被特殊处理，不重新路由到任何用户（实际上，默认情况下，元数据频道是被禁止订阅的，它是一个无操作订阅服务频道） 。

例如，让我们想象，clientAB订阅频道/ A和/ B，clientB订阅通道/ B
如果发布者发布一个消息到频道/ A，只有clientAB将接收它。另一方面，如果发布者发布一个消息到频道/ B，则clientAB和clientB都将收到消息。此外，如果发布者发布一个消息到频道/ C，则clientAB和clientB都不会收到的消息，而它将会结束其在服务器上的刚刚开始的征程。
重新路由广播消息是服务器的默认行为，而且它不需要任何应用程序代码进行重新路由。

从高层次来看，那么，你会看到消息通过客户端和服务器之间的管道来回流动。
一个单一的广播消息到达服务器，就重新路由到所有客户端，你可以想像成：当它在服务器上时，该消息是复制一个副本发送到每个客户端（尽管，初一效率的原因，这不完全会发生）。如果发件人也是订阅的这个频道的人，它也会收到发布消息的副本。

有悬而未决的问题，但：
如果元数据消息和服务消息的旅程在服务器上结束，应用程序可以利用他们来做些什么，？

一个客户端怎么与其他的，特殊的客户端进行连接？

服务器可以是发布消息的发布者吗？

为了回答这些问题和其他问题，我们需要采取细看CometD是如何工作的。继续往下阅读。

一个较低的水平视图

在下面的章节中，我们将采取深入探讨CometD是如何实施工作的。

现在应该明确，CometD，它的中心，是一个客户端/服务器系统，是通过了一项协议，Bayeux协议进行通信的。

在CometD实现中，客户端/服务器通信的捕获是用半对象加协议模式：当在客户端上的半对象建立与服务器的通信管道时，其通信半对象也在服务器上创建，形成两条通道- 逻辑 –连接。
在CometD中，这种格局的变化是因为有抽象传输消息，出入服务器的需要。
传输可以基于HTTP协议，也可以基于最近CometD版本的WebSocket协议（及更多的传输可插入）。

从广义上讲，“客户”是由客户端的半对象（用JavaScript类化的org.cometd.Cometd对象，和用Java类化org.cometd.bayeux.client.ClientSession的对象）

和客户端的传输（用JavaScript类化的org.cometd.Transport对象和用Java类化的org.cometd.client.transport.ClientTransport对象）组成的。
“服务器”是一个更复杂的实体，由一个org.cometd.bayeux.server.BayeuxServer实例，服务器传输（org.cometd.bayeux.server.ServerTransport类）的消息处理组件，一个服务器端的半对象（org.cometd.bayeux.server.ServerSession类）库和频道（org.cometd.bayeux.server.ServerChannel）库组成。如下图：

消息流

客户端的半对象把消息传递委托给一个客户端传输，客户端传输负责建立与服务器的频道，并发送该频道的消息。
在服务器上，它是服务器传输，接收消息。
服务器传输委托一个消息进程给消息处理组件，以处理传入消息，它生成一个消息的回复，并又委托该服务器传输把回复交付给客户端。

在上图中，可以看到导管连接的客户端传输和服务器传输，此外ServerSession可能参与（只发送，而不是直接接收）发送消息到客户端（通过服务器传输）。

TODO：解释广播消息流是如何工作的，但是这需要引入服务器会话队列的概念

Bayeux协议

客户端与服务器交换的Bayeux消息。

Bayeux协议的要求，一个新的客户端发送的第一条消息是一个握手消息（/meta/handshake频道上发送的消息）。
在服务器上，如果传入的握手消息的处理是成功的，然后BayeuxServer创造了一个半服务器端对象的实例（一个ServerSession），在服务器上，客户端发起握手。
当握手处理完成后，服务器发送回给客户端一个答复。

客户端进程的握手消息的答复，如果它是成功，开始 - 在幕后 - 与服务器的心跳机制，来交换连接的消息。
这个心跳机制的细节取决于客户端上使用的传输工具，可以作为客户端发送连接消息，并期待回复，一段时间后，看到（使用HTTP传输时，心跳机制也被称为“长轮询”） 。
心跳机制，允许客户端检测服务器是否关闭了（客户端将无法接收来自服务器的连接的消息答复），并允许服务器检测客户端是否关闭了（服务器将不会收到客户端的连接消息请求）。

客户端和服务器之间的连接的消息一直都有，直至任何一方决定中断并发送一个disconnect的消息（发送/meta/disconnect断开通道消息）。