BlazeDS的通道和端点

AMF和HTTP通道都支持无轮询的请求/响应模式和客户端轮询模式（模拟实时通信），而AMF和HTTP流通道模式（Streaming）提供了真正的数据流实时模式。

【区别】就是AMFChannel/AMFEndpoint和StreamingAMFChannel/StreamingAMFEndpoint使用二进制AMF格式，速度较快，另外两种（HTTPChannel/HTTPEndpoint和StreamingHTTPChannel/StreamingHTTPEndpoint）使用AMFX（XMl）格式速度较慢，前面两种（AMFChannel/AMFEndpoint和HTTPChannel/HTTPEndpoint）是基本的通信，后面两种（StreamingAMFChannel/StreamingAMFEndpoint和StreamingHTTPChannel/StreamingHTTPEndpoint）主要用于多媒体流间的通信。

二、选择通道

基于你的应用需求，你可以选择简单AMF、HTTP通道以及基于非轮询、搭载式、轮询或者长轮询模式。当然你也可以选择streaming AMF、HTTP通道。

AMF和HTTP通道的最大不同就是前者基于二进制的AMF格式传输数据，而后者则是XML格式(AMFX)。因为AMF通道比HTTP 通道性能要好，所以只有当你的应用有特殊需求的时候才适合使用HTTP通道(事先已经知道二进制格式不能在你的应用网络中传输或者想让数据在防火墙上能更好解析)。

下面分别讲一下前面提到的几种模式：

1、无轮询AMF、HTTP通道

你可以使用这些通道无轮询的方式来提供RPC服务，比如：远程服务调用、代理HTTP服务调用以及Web service请求。这些方案不要求客户端轮询信息或者服务端将消息“推”给客户端。

<!‐‐ Simple AMF ‐‐>
<channel‐definition id="samples‐amf" type="mx.messaging.channels.AMFChannel">
<endpoint url=http://{server.name}:8080/dev/messagebroker/amf type="flex.messaging.endpoints.AmfEndpoint"/>
</channel‐definition>

<!‐‐ Simple secure AMF ‐‐>
<channel‐definition id="my‐secure‐amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url=https://{server.name}:8080/dev/messagebroker/amfsecure class="flex.messaging.endpoints.SecureAMFEndpoint"/>
</channel‐definition>

<!‐‐ Simple HTTP ‐‐>
<channel‐definition id="my‐http" class="mx.messaging.channels.HTTPChannel">
<endpoint url=http://{server.name}:8080/dev/messagebroker/http class="flex.messaging.endpoints.HTTPEndpoint"/>

</channel‐definition>

<!‐‐ Simple secure HTTP ‐‐>
<channel‐definition id="my‐secure‐http" class="mx.messaging.channels.SecureHTTPChannel">
<endpoint url=https://{server.name}:8080/dev/messagebroker/httpsecure class="flex.messaging.endpoints.SecureHTTPEndpoint"/>
</channel‐definition>

2、搭载式AMF、HTTP通道（没弄明白什么意思）

搭载式确保独立于客户端发送信息到服务端或者服务端响应消息到客户端的数据传输。搭载式提供了轻量级的假轮询：一种比固定或者适当时间间隔轮询服务端更好的方式，特别是当客户端发送一个非命令消息到服务器（使用一个生产者或RemoteObject对象）时，服务器发送任何未确定的数据到客户端或数据管理订阅随着客户端的信息响应。

也可以在一个需要确保轮询，但是间隔却比较长，例如5秒或者10秒甚至更多的通道中使用，在这种情况下，应用程序似乎更加敏感。这种模式下，客户端的轮询请求独立于任何其他消息发送给服务端。

3、轮询AMF、HTTP通道

AMF、HTTP通道提供了简单的轮询机制，客户端可以用这个机制定期发送请求消息到服务端。当长期轮询或者流通道不能使用时，或者作为一个流通道的备用通道时候，轮询AMF、HTTP通道是适用的。

<!‐‐ AMF with polling ‐‐>
<channel‐definition id="samples‐polling‐amf" type="mx.messaging.channels.AMFChannel">
<endpoint url=http://{server.name}:8080/dev/messagebroker/amfpolling type="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling‐enabled>true</polling‐enabled>
<polling‐interval‐seconds>8</polling‐interval‐seconds>
</properties>

</channel‐definition>

<!‐‐ HTTP with polling ‐‐>
<channel‐definition id="samples‐polling‐http" type="mx.messaging.channels.HTTPChannel">
<endpoint url=http://{server.name}:8080/dev/messagebroker/httppolling type="flex.messaging.endpoints.HTTPEndpoint"/>
<properties>
<polling‐enabled>true</polling‐enabled>
<polling‐interval‐seconds>8</polling‐interval‐seconds>
</properties>
</channel‐definition>

注意：这种模式中你也可以使用secure通道。

4、长轮询AMF、HTTP通道

当其他更加有效率的实时机制不合适的时候，你可以使用AMF和HTTP通道的长期轮询模式来“推”消息到客户端。这一机制的使用标准应用服务器的HTTP 请求处理逻辑，并与典型的J2EE架构协同工作。

您可以为任何通道建立长期轮询来使用相应端点，需要设置一下参数：polling-enabled、polling-interval-millis、wait-interval-millis、client-w ait-interval-mills。有关wait-interval-millis 的更多内容请参考Blazeds文档。

<!‐‐ Long polling AMF ‐‐>
<channel‐definition id="my‐amf‐longpoll" class="mx.messaging.channels.AMFChannel">
<endpoint url=http://servername:8080/contextroot/messagebroker/myamflongpoll class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling‐enabled>true</polling‐enabled>
<polling‐interval‐seconds>0</polling‐interval‐seconds>

<wait‐interval‐millis>60000</wait‐interval‐millis>
<client‐wait‐interval‐millis>3000</client‐wait‐interval‐millis>
<max‐waiting‐poll‐requests>100</max‐waiting‐poll‐requests>
</properties>
</channel‐definition>

<!-- Long polling HTTP -->
<channel-definition id="my-http-longpoll" class="mx.messaging.channels.HTTPChannel">
<endpoint url="http://servername:8700/contextroot/messagebroker/myhttplongpoll" class="flex.messaging.endpoints.HTTPEndpoint"/>

<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-seconds>0</polling-interval-seconds>
<wait-interval-millis>60000</wait-interval-millis>
<client-wait-interval-millis>3000</client-wait-interval-millis>
<max-waiting-poll-requests>100</max-waiting-poll-requests>
</properties>
</channel-definition>

5、StreamingAMF、HTTP通道

<!-- AMF with streaming -->
<channel-definition id="my-amf-stream" class="mx.messaging.channels.StreamingAMFChannel">

<endpoint url="http://servername:2080/myapp/messagebroker/streamingamf" class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
</channel-definition>

<!-- HTTP with streaming -->
<channel-definition id="my-http-stream" class="mx.messaging.channels.StreamingHTTPChannel">
<endpoint url="http://servername:2080/myapp/messagebroker/streaminghttp" class="flex.messaging.endpoints.StreamingHTTPEndpoint"/>
</channel-definition>

三、【注意】

1、使用BlazeDS，消息目标通常用作streaming通道或者polling通道。

使用streaming通道，服务器端会一直响应HTTP请求直到该通道连接被关闭，它允许服务器向客户端不断传送大量的数据。因为HTTP连接是独一无二的，这实现数据的双向传送，每个streaming AMF或者HTTP通道事实上需要两个浏览器 HTTP连接， 一个连接需要不断处理服务器端与通道紧密相关的客户端的响应。另外需要一个短暂连接,只有当数据需要传送到服务器时，它才脱离浏览器连接池；当短暂连接不再需要时，它立即被释放回浏览器连接池。

polling通道可以通过简单的时间间隔或者使用服务器等待来配置，如果数据不马上可用 (长轮循)的话。另外，每次轮循响应完成请求。默认下浏览器HTTP 1.1的连接是持续的，浏览器轮循已有的连接，发送并发的轮循请求，以此来减轻轮循的开销。

当需要准实时通信时，streaming通道是最好选择。

2、IE 与 Firefox浏览器下的不同

浏览器对每个session都有连接数限制。不同的浏览器，连接最大数以及对session的处理方式都不一样。

IE中每个session的最大连接数为2。 但如果从开始菜单或快捷方式打开多个IE实例，每个IE实例开启不同的进程并拥有各自session。另外，如果我们通过CTRL+N 开启对已有的IE实例一个新的IE窗口，该窗口将与创建它的IE实例共用一个session 。也就是说，如果程序实例开启不同的进程，我们可以通过HTTP streaming建立不限量应用取得服务器端数据；如果通过CTRL+N开启多个窗口，每个session最多建立2个连接。

Firefox中每个session最多建立8个连接。如果从开始菜单或快捷方式打开多个Firefox实例，所有实例开启使用同一进程并共用一个session。既然浏览器对普通的HTTP请求通常只需要一个连接， 理论上我们可以最多可以建立7个HTTP streaming连接。

3、messaging-config.xml

另外，如果每个session到达最大连接数，使用streaming channel连接到服务器的下一次尝试将失败：Endpoint with id 'my-streaming-amf' cannot grant streaming connection to FlexClient with id 'D640B86F-6B1D-92DF-8288-1B737A371AFE' because max-streaming-connections-per-session limit of '1' has been reached。不过，BlazeDS提供一种优雅的退后机制来处理这种情况：客户端始终会尝试使用通道表(messaging-config.xml中为服务终端定义)中的第一个通道来连接。如果该连接失败, 客户端将自动退后到通道表中的下一通道。在本实例中，我们为所有的服务终端定义了如下默认的ChannelSet：

<default-channels>
 <channel ref="my-streaming-amf"/>
 <channel ref="my-polling-amf"/>
</default-channels>

也就是说，客户端应用会首先尝试使用streaming channel连接，如果连接失败会使用polling channel。