选择端点
BlazeDS提供了下列基于servlet的通道、端点组合。使用安全协议 HTTPS 向 AMF 端点发送消息安全的通道和端点都以“Secure”开头；比如，SecureAMFChannel和SecureAMFEndpoint
|
|
描述 |
| AMFChannel/AMFEndpoint |
一对简单的通道/端点组合，基于HTTP协议，以异步请求、响应的模式通过二进制AMF格式传输数据。也可以配置一个通道，专门通过这个端点来轮询新消息。你可以为轮询配置一个较长的等待间隔，实现类似实时通讯。 |
| HTTPChannel/HTTPEndpoint |
提供同样的通道/端点行为，但是是通过XML代替AMF传输数据，称为AMFX格式化。它的速度没有AMFEndpoint快。 |
| StreamingAMFChannel/StreamingAMFEndpoint |
基于HTTP协议实时传递二进制格式数据流。在实时数据服务，例如消息服务的时候使用，因为数据流对性能来说是决定性的。 |
| StreamingHTTPChannel/StreamingHTTPEndpoint |
和streaming AMF 通道/端点提供同样的行为，但是是用XML代替AMF实现数据传输。它没有streaming AMF快。 |
AMF和HTTP通道都支持无轮询的请求/响应模式和客户端轮询模式（模拟实时通信），而AMF和HTTP流通道模式提供了真正的数据流实时模式
选择通道
基于你的应用需求，你可以选择简单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}:8400/myapp/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}:9100/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}:8400/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}:9100/dev/messagebroker/
httpsecure"
class="flex.messaging.endpoints.SecureHTTPEndpoint"/>
</channel-deFinition>
2) 搭载式AMF、HTTP通道
搭载式确保独立于客户端发送信息到服务端或者服务端响应消息到客户端的数据传输。搭载式提供了轻量级的假轮询：一种比固定或者适当时间间隔轮询服务端更好的方式，s特别是当客户端发送一个非命令消息到服务器（使用一个生产者或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}:8700/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}:8700/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通道的长期轮询模式来“推”消息到客户端。 This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures.这一机制的使用标准应用服务器的HTTP请求处理逻辑，并与典型的J2EE架构协同工作。
You can establish long polling for any channel that uses a non-streaming AMF or HTTP endpoint by setting the , ,and properties in a channel deFinition; for more information,seeSimple channels and endpoints .您可以为任何通道建立长期轮询来使用相应端点，需要设置一下参数：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:8700/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>
