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.
在一個(gè)polling AMF或HTTP channel默認(rèn)配置下，服務(wù)端endpoint不會(huì)等待消息，當(dāng)輪詢請(qǐng)求被收到時(shí)，它檢查任何消息是否排隊(duì)等待輪詢的客戶端，如果是，這些消息被交付給HTTP請(qǐng)求的響應(yīng)。
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)無(wú)輪詢AMF、HTTP通道
你可以使用這些通道無(wú)輪詢的方式來(lái)提供RPC 服務(wù)，比如遠(yuǎn)程服務(wù)調(diào)用、代理HTTP服務(wù)調(diào)用以及Web service請(qǐng)求。這些方案不要求客戶端輪詢信息或者服務(wù)端將消息“推”給客戶端。
<!-- 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通道
搭載式確保獨(dú)立于客戶端發(fā)送信息到服務(wù)端或者服務(wù)端響應(yīng)消息到客戶端的數(shù)據(jù)傳輸。搭載式提供了輕量級(jí)的假輪詢：一種比固定或者適當(dāng)時(shí)間間隔輪詢服務(wù)端更好的方式，s特別是當(dāng)客戶端發(fā)送一個(gè)非命令消息到服務(wù)器（使用一個(gè)生產(chǎn)者或RemoteObject對(duì)象）時(shí)，服務(wù)器發(fā)送任何未確定的數(shù)據(jù)到客戶端或數(shù)據(jù)管理訂閱隨著客戶端的信息響應(yīng)。
也可以在一個(gè)需要確保輪詢，但是間隔卻比較長(zhǎng)，例如5秒或者10秒甚至更多的通道中使用，在這種情況下，應(yīng)用程序似乎更加敏感。這種模式下，客戶端的輪詢請(qǐng)求獨(dú)立于任何其他消息發(fā)送給服務(wù)端

3)輪詢AMF、HTTP通道
AMF、HTTP通道提供了簡(jiǎn)單的輪詢機(jī)制，客戶端可以用這個(gè)機(jī)制定期發(fā)送請(qǐng)求消息到服務(wù)端。當(dāng)長(zhǎng)期輪詢或者流通道不能使用時(shí)，或者作為一個(gè)流通道的備用通道時(shí)候，輪詢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)  長(zhǎng)輪詢AMF、HTTP通道
當(dāng)其他更加有效率的實(shí)時(shí)機(jī)制不合適的時(shí)候，你可以使用AMF和HTTP通道的長(zhǎng)期輪詢模式來(lái)“推”消息到客戶端。 This mechanism uses the normal application server HTTP request processing logic and works with typical J2EE deployment architectures.這一機(jī)制的使用標(biāo)準(zhǔn)應(yīng)用服務(wù)器的HTTP請(qǐng)求處理邏輯，并與典型的J2EE架構(gòu)協(xié)同工作。
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 .您可以為任何通道建立長(zhǎng)期輪詢來(lái)使用相應(yīng)端點(diǎn)，需要設(shè)置一下參數(shù)：polling-enabled、polling-interval-millis、wait-interval-millis、client-w ait-interval-mills。有關(guān)wait-interval-millis的更多內(nèi)容請(qǐng)參考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>

關(guān)于 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)：核心思想是客戶端定時(shí)去服務(wù)器取消息。為了實(shí)現(xiàn)即時(shí)效果，輪詢的間隔必須設(shè)計(jì)得足夠短，另外為了操作的流暢，需要使用Ajax來(lái)發(fā)送請(qǐng)求。本人的QGYWebIM就是采用的此方案。這種方案的優(yōu)點(diǎn)是：后端程序編寫比較容易，發(fā)送完響應(yīng)信息馬上斷開連接，不會(huì)占用太多服務(wù)器資源。缺點(diǎn)是一般情況下，頻繁的請(qǐng)求中有大半是無(wú)用，這些冗余請(qǐng)求無(wú)形中浪費(fèi)了帶寬和服務(wù)器資源。我們可以通過(guò)判斷用戶的活躍程度來(lái)決策請(qǐng)求服務(wù)器的間隔，我在51的一個(gè)帖子提到過(guò)這種方法，但是間隔一旦長(zhǎng)了，消息的傳送就有延時(shí)，違背了即時(shí)聊天的初衷了。

2.長(zhǎng)輪詢(long-polling)：基本原理是客戶端向服務(wù)器發(fā)送請(qǐng)求，服務(wù)器接到請(qǐng)求后hold住連接，直到有新消息才返回響應(yīng)信息并關(guān)閉連接，連接被斷開期間用戶的新信息會(huì)被服務(wù)器緩存起來(lái)?？蛻舳颂幚硗觏憫?yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求。這種做法的優(yōu)勢(shì)是如果用戶一直沒(méi)新消息，客戶端不會(huì)頻繁的輪詢?nèi)シ?wù)器取消息，節(jié)省了流量，但是服務(wù)器維持長(zhǎng)連接是很消耗資源的。具體實(shí)現(xiàn)起來(lái)，前端這邊基本不需要什么改動(dòng)，依然是用Ajax輪詢?nèi)⌒畔?，后端需要在沒(méi)有新消息時(shí)處理一下。

3.長(zhǎng)連接(streaming)：其實(shí)很早以前就有人使用這種技術(shù)來(lái)實(shí)現(xiàn)聊天室的通訊，HTTP1.1開始支持。以前在頁(yè)面中嵌入一個(gè)iframe，iframe里放一個(gè)使用長(zhǎng)連接頁(yè)面，服務(wù)器有新消息就會(huì)及時(shí)的在iframe里反映出來(lái)，再依靠客戶端的腳本解析出來(lái)就OK了。這樣做一個(gè)比較嚴(yán)重的問(wèn)題是：使用 iframe請(qǐng)求長(zhǎng)連接時(shí)，無(wú)論是IE還是firefox都會(huì)認(rèn)為頁(yè)面沒(méi)有加載完而顯示進(jìn)度條，很難看。不過(guò)這個(gè)問(wèn)題是可以解決的。firefox支持了Streaming Ajax，在readyState為3的時(shí)候就能接受數(shù)據(jù)，所以問(wèn)題不大；IE則只能在readyState為4，即連接斷開時(shí)才能得到返回值。但是偉大的Google工程師使用了一個(gè)hack成功的解決了這個(gè)問(wèn)題：使用一個(gè)被稱為“htmlfile”的ActiveX，把iframe放在這個(gè)ActiveX里就OK了。

無(wú)疑，使用長(zhǎng)連接對(duì)于用戶來(lái)說(shuō)是最好的方案，用戶體驗(yàn)最好（消息能及時(shí)的到達(dá)）、占用用戶帶寬最少（不會(huì)發(fā)送無(wú)用的請(qǐng)求），但是會(huì)增加服務(wù)器的開銷；長(zhǎng)輪詢是折中方案，F(xiàn)acebook IM 就是采用這種方案，不過(guò)做了一點(diǎn)改動(dòng)：客戶端發(fā)起的每個(gè)連接服務(wù)器都hold10S，這10S中新消息會(huì)源源不斷的返回給客戶端，10s后連接關(guān)閉，客戶端發(fā)起下一個(gè)連接。這樣做是因?yàn)镕acebook的用戶會(huì)不斷的打開、關(guān)閉新頁(yè)面，如果每個(gè)頁(yè)面都建立一個(gè)永久的長(zhǎng)連接，會(huì)阻塞瀏覽器其他請(qǐng)求，服務(wù)器也會(huì)吃不消的；短輪詢因?yàn)閷?shí)現(xiàn)起來(lái)簡(jiǎn)單，適用于小型應(yīng)用。

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.