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通道
搭載式確保獨立于客戶端發(fā)送信息到服務端或者服務端響應消息到客戶端的數據傳輸。搭載式提供了輕量級的假輪詢：一種比固定或者適當時間間隔輪詢服務端更好的方式，s特別是當客戶端發(fā)送一個非命令消息到服務器（使用一個生產者或RemoteObject對象）時，服務器發(fā)送任何未確定的數據到客戶端或數據管理訂閱隨著客戶端的信息響應。
也可以在一個需要確保輪詢，但是間隔卻比較長，例如5秒或者10秒甚至更多的通道中使用，在這種情況下，應用程序似乎更加敏感。這種模式下，客戶端的輪詢請求獨立于任何其他消息發(fā)送給服務端

3)輪詢AMF、HTTP通道
AMF、HTTP通道提供了簡單的輪詢機制，客戶端可以用這個機制定期發(fā)送請求消息到服務端。當長期輪詢或者流通道不能使用時，或者作為一個流通道的備用通道時候，輪詢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來發(fā)送請求。本人的QGYWebIM就是采用的此方案。這種方案的優(yōu)點是：后端程序編寫比較容易，發(fā)送完響應信息馬上斷開連接，不會占用太多服務器資源。缺點是一般情況下，頻繁的請求中有大半是無用，這些冗余請求無形中浪費了帶寬和服務器資源。我們可以通過判斷用戶的活躍程度來決策請求服務器的間隔，我在51的一個帖子提到過這種方法，但是間隔一旦長了，消息的傳送就有延時，違背了即時聊天的初衷了。

2.長輪詢(long-polling)：基本原理是客戶端向服務器發(fā)送請求，服務器接到請求后hold住連接，直到有新消息才返回響應信息并關閉連接，連接被斷開期間用戶的新信息會被服務器緩存起來。客戶端處理完響應信息后再向服務器發(fā)送新的請求。這種做法的優(yōu)勢是如果用戶一直沒新消息，客戶端不會頻繁的輪詢去服務器取消息，節(jié)省了流量，但是服務器維持長連接是很消耗資源的。具體實現起來，前端這邊基本不需要什么改動，依然是用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了。

無疑，使用長連接對于用戶來說是最好的方案，用戶體驗最好（消息能及時的到達）、占用用戶帶寬最少（不會發(fā)送無用的請求），但是會增加服務器的開銷；長輪詢是折中方案，Facebook IM 就是采用這種方案，不過做了一點改動：客戶端發(fā)起的每個連接服務器都hold10S，這10S中新消息會源源不斷的返回給客戶端，10s后連接關閉，客戶端發(fā)起下一個連接。這樣做是因為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.