How to use BlazeDS Messaging

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:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="consumer.subscribe()">
    
    <mx:Script>
        <![CDATA[
        
            import mx.messaging.messages.AsyncMessage;
            import mx.messaging.messages.IMessage;
            
            private function send():void
            {
                var message:IMessage = new AsyncMessage();
                message.body.chatMessage = msg.text;
                producer.send(message);
                msg.text = "";
            }
                            
            private function messageHandler(message:IMessage):void
            {
                log.text += message.body.chatMessage + "\n";    
            }
            
        ]]>
    </mx:Script>
    
    <mx:Producer id="producer" destination="chat"/>
    <mx:Consumer id="consumer" destination="chat" message="messageHandler(event.message)"/>
    
    <mx:Panel title="Chat" width="100%" height="100%">
        <mx:TextArea id="log" width="100%" height="100%"/>
        <mx:ControlBar>
             <mx:TextInput id="msg" width="100%" enter="send()"/>
             <mx:Button label="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.