The following example shows a RemoteObject component that defines a channel set and channel inline in MXML:
...
<RemoteObject id="ro" destination="Dest">
<mx:channelSet>
<mx:ChannelSet>
<mx:channels>
<mx:AMFChannel id="myAmf"
uri="http://myserver:2000/myapp/messagebroker/amf"/>
</mx:channels>
</mx:ChannelSet>
</mx:channelSet>
</RemoteObject>

The following example shows ActionScript code that is equivalent to the MXML code in the previous example:
private function run():void {
 ro = new RemoteObject();
 var cs:ChannelSet = new ChannelSet();
 cs.addChannel(new AMFChannel("myAmf",
 "http://servname:2000/eqa/messagebroker/amf"));
 ro.destination = "Dest";
 ro.channelSet = cs;
}

Important: When you create a channel on the client, you must still include a channel definition that specifies an endpoint class in the services-config.xml file. Otherwise, the message broker cannot pass a Flex client request to an endpoint.

Assigning channels and endpoints to a destination
1,If most of the destinations across all services use the same channels, you can define application-level default channels in the services-config.xml file, as the following example shows.
Note: Using application-level default channels is a best practice whenever possible.
<services-config ...>
...
<default-channels>
<channel ref="my-http"/>
<channel ref="my-amf"/>
</default-channels>
...
In this case, all destinations that do not define channels use a default channel. Destinations can override the
default channel setting by specifying their own channels, and services can also override it by specifying their own
default channels.
2,If most of the destinations in a service use the same channels, you can define service-level default channels, as
the following example shows:
<service ...>
...
<default-channels>
<channel ref="my-http"/>
<channel ref="my-amf"/>
</default-channels>
...
In this case, all destinations in the service that do not explicitly specify their own channels use the default
channel.
3,The destination definition can reference a channel inline, as the following example shows:
<destination id="sampleVerbose">
<channels>
<channel ref="my-secure-amf"/>
</channels>
...
</destination>

How to choosing a channel?
1, Non-polling AMF and HTTP channels
You can use AMF and HTTP channels without polling for remote procedure call (RPC) services, such as remoting service calls, proxied HTTP service calls and web service requests. These scenarios do not require the client to poll for messages or the server to push messages to the client.
2, Piggybacking on AMF and HTTP channels
The piggybacking feature enables the transport of queued messages along with responses to any messages the client sends to the server over the channel. Piggybacking provides lightweight pseudo polling, where rather than the client channel polling the server on a fixed or adaptive interval, when the client sends a non-command message to the server (using a Producer or RemoteObject object), the server sends any pending data for client messaging or data management subscriptions along with the response to the client message.
Piggybacking can also be used on a channel that has polling enabled but on a wide interval like 5 seconds or 10 seconds or more, in which case the application appears more responsive if the client is sending messages to the server. In this mode, the client sends a poll request along with any messages it sends to the server between its regularly scheduled poll requests. The channel piggybacks a poll request along with the message being sent, and the server piggybacks any pending messages for the client along with the acknowledge response to the client message.
3, Polling AMF and HTTP channels
AMF and HTTP channels support simple polling mechanisms that clients can use to request messages from the server at set intervals. A polling AMF or HTTP channel is useful when other options such as long polling or streaming channels are not acceptable and also as a fallback channel when a first choice, such as a streaming channel, is unavailable at run time.
4, Long polling AMF and HTTP channels
You can use AMF and HTTP channels in long polling mode to get pushed messages to the client when the other more efficient and real-time mechanisms are not suitable. This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures.
You can establish long polling for any channel that uses a non-streaming AMF or HTTP endpoint by setting the polling-enabled ,  polling-interval-millis ,  wait-interval-millis , and  client-wait-interval-
millis  properties in a channel definition.
5, Streaming channels
For streaming, you can use streaming AMF or HTTP channels. Streaming AMF and HTTP channels work with streaming AMF or HTTP endpoints.

Long polling AMF and HTTP channels
In the default configuration for a polling AMF or HTTP channel, the endpoint does not wait for messages on the server. When the poll request is received, it checks whether any messages are queued for the polling client and if so, those messages are delivered in the response to the HTTP request. You configure long polling in the same way as polling, but you also must set the  wait-interval-millis ,  max-waiting-poll-requests , and client-wait-interval-millis  properties.
在一个polling AMF或HTTP channel默认配置下，服务端endpoint不会等待消息，当轮询请求被收到时，它检查任何消息是否排队等待轮询的客户端，如果是，这些消息被交付给HTTP请求的响应。
To achieve long polling, you set the following properties in the  properties  section of a channel definition in the services-config.xml file:
polling-enabled
polling-interval-millis
wait-interval-millis 
max-waiting-poll-requests .
client-wait-interval-millis

下面分别讲一下前面提到的几种模式：
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 polling-enabled , polling-interval-millis , wait-interval-millis , and client-wait-interval-millis properties in a channel definition; for more information, see Simple 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>

关于 Non-polling,Polling,Long polling和steaming的一些解释
http://www.qgy18.com/2008/08/webim-design-transport/
http://newteevee.com/2009/10/04/adobe-to-finally-support-http-streaming/

1.短轮询(polling)：核心思想是客户端定时去服务器取消息。为了实现即时效果，轮询的间隔必须设计得足够短，另外为了操作的流畅，需要使用Ajax来发送请求。本人的QGYWebIM就是采用的此方案。这种方案的优点是：后端程序编写比较容易，发送完响应信息马上断开连接，不会占用太多服务器资源。缺点是一般情况下，频繁的请求中有大半是无用，这些冗余请求无形中浪费了带宽和服务器资源。我们可以通过判断用户的活跃程度来决策请求服务器的间隔，我在51的一个帖子提到过这种方法，但是间隔一旦长了，消息的传送就有延时，违背了即时聊天的初衷了。

2.长轮询(long-polling)：基本原理是客户端向服务器发送请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，连接被断开期间用户的新信息会被服务器缓存起来。客户端处理完响应信息后再向服务器发送新的请求。这种做法的优势是如果用户一直没新消息，客户端不会频繁的轮询去服务器取消息，节省了流量，但是服务器维持长连接是很消耗资源的。具体实现起来，前端这边基本不需要什么改动，依然是用Ajax轮询取信息，后端需要在没有新消息时处理一下。

3.长连接(streaming)：其实很早以前就有人使用这种技术来实现聊天室的通讯，HTTP1.1开始支持。以前在页面中嵌入一个iframe，iframe里放一个使用长连接页面，服务器有新消息就会及时的在iframe里反映出来，再依靠客户端的脚本解析出来就OK了。这样做一个比较严重的问题是：使用 iframe请求长连接时，无论是IE还是firefox都会认为页面没有加载完而显示进度条，很难看。不过这个问题是可以解决的。firefox支持了Streaming Ajax，在readyState为3的时候就能接受数据，所以问题不大；IE则只能在readyState为4，即连接断开时才能得到返回值。但是伟大的Google工程师使用了一个hack成功的解决了这个问题：使用一个被称为“htmlfile”的ActiveX，把iframe放在这个ActiveX里就OK了。

无疑，使用长连接对于用户来说是最好的方案，用户体验最好（消息能及时的到达）、占用用户带宽最少（不会发送无用的请求），但是会增加服务器的开销；长轮询是折中方案，Facebook IM 就是采用这种方案，不过做了一点改动：客户端发起的每个连接服务器都hold10S，这10S中新消息会源源不断的返回给客户端，10s后连接关闭，客户端发起下一个连接。这样做是因为Facebook的用户会不断的打开、关闭新页面，如果每个页面都建立一个永久的长连接，会阻塞浏览器其他请求，服务器也会吃不消的；短轮询因为实现起来简单，适用于小型应用。

There is a browser-specific limit to the number of connections allowed per session. In Firefox, the limit is eight connections per session. In Internet Explorer, the limit is two connections allowed per session. Therefore, BlazeDS must limit the number of streaming connections per session on the server to stay below this limit.

Channel and endpoint recommendations

1. AMFChannel/Endpoint configured for long polling (no fallback needed)
Benifits:
Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.
Disadvantages:
When many messages are being pushed to the client, this configuration has the overhead of a poll round trip for every pushed message or small batch of messages queued between polls. Most applications are not pushing data so frequently for this to be a problem.
The Servlet API uses blocking IO, so you must define an upper bound for the number of long poll requests parked on the server at any single instant. If your number of clients exceeds this limit, the excess clients devolve to simple polling on the default 3- second interval with no server wait.
For example, if you server request handler thread pool has a size of 500, you could set the upper bound for waited polls to 250, 300, or 400 depending on the relative amount of non-poll requests you expect to service concurrently.

2. StreamingAMFChannel/Endpoint (in a channel set followed by the polling AMFChannel for fallback)
Benifits:
No polling overhead associated with pushing messages to the client.
Uses standard HTTP ports so firewalls do not interfere and all requests/responses are HTTP so packet inspecting proxies won’t drop the packets.
Disadvantages:
Holding onto the open request on the server and writing an infinite response is not typical HTTP behavior. HTTP proxies that buffer responses before forwarding them can effectively consume the stream. Assign the channel’s ‘connect-timeout-seconds’ property a value of 2 or 3 to detect this and trigger fallback to the next channel in your channel set.
No support for HTTP 1.0 client. If the client is 1.0, the open request is faulted and the client falls back to the next channel in its channel set.
The Servlet API uses blocking IO so as with long polling above, you must set a configured upper bound on the number of streaming connections you allow. Clients that exceed this limit are not able to open a streaming connection and will fall back to the next channel in their channel set.

3. AMFChannel/Endpoint with simple polling and piggybacking enabled (no fallback needed)
Benifits:
Valid HTTP request/response pattern over standard ports that nothing in the network path will have trouble with.
User experience feels more real-time than with simple polling on an interval.
Does not have thread resource constraints like long polling and streaming due to the blocking IO of the Servlet API.
Disadvantages:
Less real-time behavior than long polling or streaming. Requires client interaction with the
server to receive pushed data faster than the channel's configured polling interval.