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.

Messages
All messages have client-side (ActionScript) implementations and server-side (Java) implementations because the messages are serialized and deserialized on both the client and the server.

Endpoint
 It is important that the channel and the endpoint use the same message format.

MessageBroker
The MessageBroker is responsible for routing messages to services and is at the core of BlazeDS on the server. After an endpoint initially processes the request, it extracts the message from the request and passes it to the MessageBroker. The MessageBroker inspects the message's destination and passes the message to its intended service. If the destination is protected by a security constraint, the MessageBroker runs the authentication and authorization checks before passing the message along

Services and destinations
Services and destinations are the next links in the message processing chain in the BlazeDS server. The system includes four services and their corresponding destinationsBlazeDS:
•     RemotingService and RemotingDestination
•     HTPProxyService and HTTPProxyDestination
•     MessageService and MessageDestination
Services are the targets of messages from client-side Flex components. Think of destinations as instances of a service configured in a certain way. For example, a RemoteObject component is used on the Flex client to communicate with the RemotingService. In the RemoteObject component, you must specify a destination  id  property that refers to a remoting destination with certain properties, such as the class you want to invoke methods on. The mapping between client-side Flex components and BlazeDS services is as follows:
•     HTTPService and WebService communicate with HTTPProxyService/HTTPProxyDestination         (RPC services)
•     RemoteObject communicates with RemotingService/RemotingDestination    (RPC services)
•     Producer and Consumer communicate with MessageService/MessageDestination   (Message services)

Adapters and assemblers
Although the BlazeDS server comes with a rich set of adapters and assemblers to communicate with different systems, custom adapters and assemblers can be plugged into the BlazeDS server. Similarly, you do not have to create all destinations in configuration files, but instead you can create them dynamically at server startup or when the server is running.

Configuration tokens
The configuration files sometimes contain special  {server.name}  and  {server.port}  tokens. These tokens are replaced with server name and port values based on the URL from which the SWF file is served when it is accessed through a web browser from a web server. Similarly, a special  {context.root}  token is replaced with the actual context root of a web application.
Note: If you use server tokens in a configuration file for an Adobe AIR application and you compile using that file, the application will not be able to connect to the server. You can avoid this issue by configuring channels in ActionScript rather than in a configuration file.

How you define JVM options depends on the application server you use. For example, in Apache Tomcat, you can define an environment variable JAVA_OPTS that contains tokens and their values, as this code snippet shows:
JAVA_OPTS=-Dmessaging.channel=my-amf -Dmy.token=myValue

 
How to create a Flash Builder project?
Use this procedure to create a Flex Builder project to edit one of the samples shipped with the Test Drive application.
The procedure for creating and configuring a new project is almost the same as the following procedure.
1     Start Flex Builder.
2     Select File > New > Flex Project.
3     Enter a project name. You are editing an existing application, so use the exact name of the sample folder:
testdrive-chat.
Note: If you are creating an empty project, you can name it anything that you want.
4     If you unzipped flex-src.zip in the samples directory, deselect the Use Default Location option, and specify the directory as C:\blazeds\tomcat\webapps\samples\testdrive-chat, or wherever you unzipped the file on your computer.
Note: By default, Flex Builder creates the project directory based on the project name and operating system. For example, if you are using the plug-in configuration of Flex Builder on Microsoft Windows, the default project directory is C:\Documents and Settings\USER_NAME\workspace\PROJECT_NAME.
5     Select the application type as Web application (runs in Flash Player) to configure the application to run in the browser as a Flash Player pplication.
If you are creating an AIR application, select Desktop Application (Runs In Adobe AIR). However, make sure that you do not have any server tokens in URLs in the configuration files. In the web application that ships with BlazeDS, server tokens are used in the channel endpoint URLs in the WEB-INF/flex/services-config.xml file, as the following example shows:
<endpoint
url="https://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
      class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
You would change that line to the following:
<endpoint url="http://your_server_name:8400/samples/messagebroker/streamingamf"
      class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
6     Select J2EE as the Application server type.
7     Select Use Remote Object Access.
8     Select LiveCycle Data Services.
9     If the option is available, deselect Create Combined Java/Flex Project With WTP.
10  Click Next.
11  Deselect Use Default Location For Local LiveCycle Data Services Server.
12  Set the root folder, root URL, and context root of your web application.
The root folder specifies the top-level directory of the web application (the directory that contains the WEB-INF directory). The root URL specifies the URL of the web application, and the context root specifies the root of the web application.
13  Make sure that your BlazeDS server is running, and click Validate Configuration to ensure that your project is valid.
14  Verify that the Compile The Application Locally In Flex Builder option is selected.
15  Clear the Output Folder field to set the directory of the compiled SWF file to the main project directory.
By default, Flex Builder writes the compiled SWF file to the bin-debug directory under the main project directory. To use a different output directory, specify it in the Output Folder field.
16  Click Next.
17  Set the name of the main application file to Chat.mxml, and click Finish.

 Client-side logging
For client-side logging, you directly write messages to the log file, or configure the application to write messages generated by Flex to the log file. Flash Debug Player has two primary methods of writing messages to a log file:
?     The global  trace()  method. The global trace() method prints a String to the log file. Messages can contain checkpoint information to signal that your application reached a specific line of code, or the value of a variable.
?     Logging API. The logging API, implemented by the TraceTarget class, provides a layer of functionality on top of the  trace()  method. For example, you can use the logging API to log debug, error, and warning messages generated by Flex while applications execute.
Flash Debug Player sends logging information to the flashlog.txt file. The operating system determines the location of this file, as the following table shows:
Use settings in the mm.cfg text file to configure Flash Debug Player for logging. If this file does not exist, you can create it when you first configure Flash Debug Player. The location of this file depends on your operating system.
The following table shows where to create the mm.cfg file for several operating systems:
The mm.cfg file contains many settings that you can use to control logging. The following sample mm.cfg file enables error reporting and trace logging:
ErrorReportingEnable=1
TraceOutputFileEnable=1
After you enable reporting and logging, call the  trace()  method to write a String to the flashlog.txt file, as the
following example shows:
trace("Got to checkpoint 1.");
Insert the following MXML line to enable the logging of all Flex-generated debug messages to flashlog.txt:
<mx:TraceTarget loglevel="2"/>

Server-side logging
You configure server-side logging in the logging section of the services configuration file, services-config.xml. By default, output is sent to System.out.
You set the logging level to one of the following available levels:
?     All
?     Debug
?     Info
?     Warn
?     Error
?     None
You typically set the server-side logging level to  Debug  to log all debug messages, and also all info, warning, and error messages. The following example shows a logging configuration that uses the  Debug  logging level:
<logging>
<!-- You may also use flex.messaging.log.ServletLogTarget. -->
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[Flex]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint</pattern>
<!--<pattern>Service.*</pattern>-->
<!--<pattern>Message.*</pattern>-->
</filters>
</target>
</logging>

You use two parameters in a channel definition to enable message processing metrics:
     <record-message-times> 
     <record-message-sizes> 
Set these parameters to  true  or  false ; the default value is  false . You can set the parameters to different values to capture only one type of metric. For example, the following channel definition specifies to capture message timing
information, but not message sizing information:
<channel-definition id="my-streaming-amf"
class="mx.messaging.channels.StreamingAMFChannel">
<endpoint
url="http://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
class="flex.messaging.endpoints.StreamingAMFEndpoint"/>
 <properties>
  <record-message-times>true</record-message-times>
  <record-message-sizes>false</record-message-sizes>
 </properties>
</channel-definition>

What's Producer?

The BlazeDS core features include the RPC services and the Messaging Service.
You can access data through client-side RPC components that include HTTP GET or POST (HTTP services), SOAP (web services), or Java objects (remote object services).
BlazeDS lets you use RemoteObject components to access remote Java objects without configuring them as SOAP-compliant web services.

Client applications that send messages are called message producers. You define a producer in a Flex application by using the Producer component. Client applications that receive messages are called message consumers. You define a consumer in a Flex application by using the Consumer component. A Consumer component subscribes to a server-side destination and receives messages that a Producer component sends to that destination. For more information on messaging, see Using the Messaging Service.

BlazeDS uses a message-based framework to send data back and forth between the client and server. BlazeDS uses two primary exchange patterns between server and client. In the first pattern, the request-response pattern, the second pattern is the publish-subscribe pattern where the server routes published messages to the set of clients that have subscribed to receive them.

To send messages across the network, the client uses channels. A channel encapsulates message formats, network protocols, and network behaviors to decouple them from services, destinations, and application code. A channel formats and translates messages into a network-specific form and delivers them to an endpoint on the server. 

Channels communicate with Java-based endpoints on the server. An endpoint unmarshals messages in a protocol-specific manner and then passes the messages in generic Java form to the message broker. The message broker determines where to send messages, and routes them to the appropriate service destination.
BlazeDS includes several types of channels, including standard and secure Action Message Format (AMF) channels and HTTP (AMFX) channels. AMF and HTTP channels support non-polling request-response patterns and client polling patterns to simulate real-time messaging. The streaming AMF and HTTP channels provide true data streaming for real-time messaging. 

 Configure an existing J2EE web application to support BlazeDS by performing the following steps: 
 1, Add the BlazeDS JAR files and dependent JAR files to the WEB-INF/lib directory. 
2, Edit the BlazeDS configuration files in the WEB-INF/flex directory. 
3, Define MessageBrokerServlet and a session listener in WEB-INF/web.xml.