【Flex CookBook】 如使用BlazeDS消息机制

How to use BlazeDS Messaging 如使用BlazeDS消息机制

问题摘要

需要一个发布/订阅的消息架构来实现数据推送或是协作式的程序

解决摘要

通过BlazeDS消息服务支持发布/订阅消息，消息管理服务管理着FLEX客户端能够订阅或者发布的一系列目标消息

解释

Flex提供了两个组件，生产者消费者分别用来发布和订阅一个目标消息。要订阅一个目标消息应该使用consumer类的subscribe()方法，当一个消息被发布到你订阅的目标对象上，消息事件就会触发消费者consumer类。使用BlazeDS的发布和订阅功能非常简单。下面是一个例子

messaging-config.xml文件来配置，配置消息目标的一个关键就是配置用来在客户端和服务端之间交互的数据通道，使用BlazeDS，一个销售目标通常使用流或者轮询作为交互通道。

<?xmlversion="1.0"encoding="utf-8"?>

<mx:Applicationxmlns:mx=http://www.adobe.com/2006/mxml

creationComplete="consumer.subscribe()">

<mx:Script>

<![CDATA[



importmx.messaging.messages.AsyncMessage;

importmx.messaging.messages.IMessage;



privatefunctionsend():void

...{

varmessage:IMessage=newAsyncMessage();

message.body.chatMessage=msg.text;

producer.send(message);

msg.text="";

}

privatefunctionmessageHandler(message:IMessage):void

...{

log.text+=message.body.chatMessage+" ";

}

]]>

</mx:Script>

<mx:Producerid="producer"destination="chat"/>

<mx:Consumerid="consumer"destination="chat"message="messageHandler(event.message)"/>

<mx:Paneltitle="Chat"width="100%"height="100%">

<mx:TextAreaid="log"width="100%"height="100%"/>

<mx:ControlBar>

<mx:TextInputid="msg"width="100%"enter="send()"/>

<mx:Buttonlabel="Send"click="send()"/>

</mx:ControlBar>

</mx:Panel>

</mx:Application>

消息目标通过

使用流通道，那么服务端的响应直到通道关闭才关闭，使得服务端能够发送大量的数据到客户端，HTTP迎接通常不是双向，这意味着使用AMF或者HTTP通道传输数据需要两个HTTP连接完成双向的数据传输，一个链接负责从服务端到客户端的数据传输，另一个负责从客户端到服务端的数据传输，数据传输一完成这两个连接就立刻被释放到浏览器的连接池

. 如果数据对象不是马上能够获得（一次轮询无法完成传输），一个轮询通道可以配置一简单的间隔。在两种情况下每一次轮询都完成相应的传输请求，游览器的HTTP1.1连接通常缺省是永久的，所以游览器可能会回收现有的HTTP1.1连接来发送的轮询请求，减少了轮询所花费的时间

源文档

<http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=7765>

How to use BlazeDS Messaging

Problem Summary

You need a publish/subscribe messaging infrastructure to build data-push or collaborative applications.

Solution Summary

Flex supports publish/subscribe messaging through the BlazeDS Message Service. The Message Service manages a set of destinations that Flex clients can publish and subscribe to.

Explanation

Flex provides two components, Producer and Consumer that you use to respectively publish and subscribe to a destination. To subscribe to a destination, you use the subscribe() method of the Consumer class. When a message is published to a destination you subscribed to, the message event is triggered on the Consumer.

Using the BlazeDS publish/subscribe capability is easy. Here is an example of a simple chat application:

<?xmlversion="1.0"encoding="utf-8"?>

<mx:Applicationxmlns:mx=http://www.adobe.com/2006/mxml

creationComplete="consumer.subscribe()">

<mx:Script>

<![CDATA[



importmx.messaging.messages.AsyncMessage;

importmx.messaging.messages.IMessage;



privatefunctionsend():void

...{

varmessage:IMessage=newAsyncMessage();

message.body.chatMessage=msg.text;

producer.send(message);

msg.text="";

}

privatefunctionmessageHandler(message:IMessage):void

...{

log.text+=message.body.chatMessage+" ";

}

]]>

</mx:Script>

<mx:Producerid="producer"destination="chat"/>

<mx:Consumerid="consumer"destination="chat"message="messageHandler(event.message)"/>

<mx:Paneltitle="Chat"width="100%"height="100%">

<mx:TextAreaid="log"width="100%"height="100%"/>

<mx:ControlBar>

<mx:TextInputid="msg"width="100%"enter="send()"/>

<mx:Buttonlabel="Send"click="send()"/>

</mx:ControlBar>

</mx:Panel>

</mx:Application>

Messaging destinations are configured in messaging-config.xml. A key element of a destination configuration is the channel used to exchange data between the client and the server. Using BlazeDS, a messaging destination typically uses a streaming or a polling channel.

Using a streaming channel, the server response is left open until the channel connection is closed, allowing the server to send down incremental chunks of data to the client. HTTP connections are not duplex. This means that a single streaming AMF or HTTP channel actually requires two browser HTTP connections in order to send data in both directions. One for the streamed response from the server to the client that the channel hangs on to, and a second transient connection, drawn from the browser pool only when data needs to be sent to the server. This second transient connection is immediately released back to the browser’s connection pool.

A polling channel can be configured with a simple interval or with a sever wait if data is not immediately available (long polling). In either case, each poll response completes the request. Browser HTTP 1.1 connections are persistent by default, so the browser will likely recycle existing HTTP connections to send subsequent poll requests which lowers the overhead for polling.