A BlazeDS application consists of two parts:
a client-side application
and a server-side J2EE web application.
A BlazeDS client application is typically an Adobe Flex or AIR application. Flex and AIR applications use Flex components to communicate with the BlazeDS server, including the RemoteObject, HTTPService, WebService, Producer, and Consumer components. The HTTPService, WebService, Producer, and Consumer components are part of the Flex Software Development Kit (SDK).
The BlazeDS server runs in a web application on a J2EE application server.
The main features of BlazeDS:
the RPC services and the Messaging Service.
RPC services
The Remote Procedure Call (RPC) services are designed for applications in which a call and response model is a good choice for accessing external data. RPC services let a client application make asynchronous requests to remote services that process the requests and then return data directly to the client. 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).
Use RPC components when you want to provide enterprise functionality, such as proxying of service traffic from different domains, client authentication, whitelists of permitted RPC service URLs, server-side logging, localization support, and centralized management of RPC services.
A client-side RPC component calls a remote service. The component then stores the response data from the service in an ActionScript object from which you can easily obtain the data. The client-side RPC components are the HTTPService, WebService, and RemoteObject components.
Messaging Service
The Messaging Service lets client applications communicate asynchronously by passing messages back and forth through the server. A message defines properties such as a unique identifier, BlazeDS headers, any custom headers, and a message body.
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.
Service adapters
BlazeDS lets you access many different persistent data stores and databases including JMS, and other data persistence mechanisms. A service adapter is responsible for updating the persistent data store on the server in a manner appropriate to the specific data store type.
When to use RPC / Messaging Services
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 client sends a request to the server to be processed. The server returns a response to the client containing the processing outcome. The RPC services use this 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. The Messaging Service uses this pattern to push data to interested clients. The Messaging Service also uses the request-response pattern to issue commands, publish messages, and interact with data on the server.
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 also impose an order to the flow of messages sent to the server and the order of corresponding responses. Order is important to ensure that interactions between the client and server occur in a consistent, predictable fashion.
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.
Channel types
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.
The main features of BlazeDS:
1> Proxy service : Enables communication between clients and domains that they cannot access directly, due to security restrictions, allowing you to integrate multiple services with a single application. By using the Proxy Service, you do not have to configure a separate web application to work with web services or HTTP services
2> Publish and subscribe messaging | Provides a messaging infrastructure that integrates with existing messaging systems such as JMS. This service enables messages to be exchanged in real time between browser clients and the server. It allows Flex clients to publish and subscribe to message topics with the same reliability, scalability, and overall quality of service as traditional thick client applications. |
| 3> Software clustering | Handles failover when using stateful services to ensure that Flex applications continue running in the event of server failure. The more common form of clustering using load balancers, usually in the form of hardware, is supported without any feature implementation. |
A destination is the server-side code that you connect to from the client.
services-config.xml configuration file defines the destinations and channels that the client application uses to communicate with the server.
The Remoting Service is one of the RPC services included with BlazeDS. The Remoting Service lets clients access methods of Plain Old Java Objects (POJOs) on the server.
Ex: Create a Java Class that sends output to client .Compile the java class and place it under WEB-INF/classes/ directoryName.
Define a destination, and reference one or more channels that transport the data. Configure JavaClassName.class as a remoting destination by editing the WEB-INF/flex/remoting-config.xml file.
<destination id="javaDestination" channels="my-amf">
<properties>
<source>DirectoryName.JavaClassName</source>
</properties>
</destination>
The source element references the Java class, and the channels attribute references a channel called my-amf.
Define the my-amf channel in WEB-INF/flex/services-config.xml, The channel definition specifies that the Flex client uses a non-polling AMFChannel to communicate with the AMFEndpoint on the server.
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"
class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>false</polling-enabled>
</properties>
</channel-definition>
The Flex client application uses the RemoteObject component to access JAVACLASSNAME. The RemoteObject component uses the destination property to specify the destination.
// Send the message in response to a Button click.
private function echo():void {
var text:String = ti.text;
remoteObject.javaMethodName(parameters);
}
<mx:RemoteObject id="remoteObject"
destination="javaDestination"
result="resultHandler(event);"
fault="faultHandler(event);"/>
Compile the client application into a SWF file by using Flex Builder or the mxmlc compiler, and then deploy it to your web application.
Messaging Service example
The Messaging Service lets client applications send and receive messages from other clients. In this example, create a Flex application that sends and receives messages from the same BlazeDS destination.
Define the messaging destination in WEB-INF/flex/messaging-config.xml, as the following example shows:
<destination id="MessagingDestination" channels="my-amf-poll"/>
Define the my-amf-poll channel in WEB-INF/flex/services-config.xml, as the following example shows:
<channel-definition id="my-amf-poll" class="mx.messaging.channels.AMFChannel">
<endpoint
url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpoll"
class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-seconds>1</polling-interval-seconds>
</properties>
</channel-definition>
This channel definition creates a polling channel with a polling interval of 1 second. Therefore, the client sends a poll message to the server every second to request new messages. Use a polling channel because it is the easiest way for the client to receive updates. Other options include polling with piggybacking, long-polling, and streaming.
The following Flex client application uses the Producer component to send a message to the destination, and the Consumer component to receive messages sent to the destination. To send the message, the Producer first creates an instance of the AsyncMessage class and then sets its body property to the message. Then, it calls the Producer.send() method to send it. To receive messages, the Consumer first calls the Consumer.subscribe() method to subscribe to messages sent to a specific destination.
<?xml version="1.0"?>
<!-- intro\intro_messaging.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
width="100%" height="100%"
creationComplete="consumer.subscribe();">
<mx:Script>
<![CDATA[
import mx.messaging.events.MessageFaultEvent;
import mx.messaging.events.MessageEvent;
import mx.messaging.messages.AsyncMessage;
import mx.messaging.Producer;
import mx.messaging.Consumer;
// Send the message in response to a Button click.
private function sendMessage():void {
var msg:AsyncMessage = new AsyncMessage();
msg.body = "Foo";
producer.send(msg);
}
// Handle the received message.
private function messageHandler(event:MessageEvent):void {
ta.text += "Consumer received message: "+ event.message.body + "\n";
}
// Handle a message fault.
private function faultHandler(event:MessageFaultEvent):void {
ta.text += "Received fault: " + event.faultString + "\n";
}
]]>
</mx:Script>
<mx:Producer id="producer"
destination="MessagingDestination"
fault="faultHandler(event);"/>
<mx:Consumer id="consumer"
destination="MessagingDestination"
fault="faultHandler(event);"
message="messageHandler(event);"/>
<mx:Button label="Send" click="sendMessage();"/>
<mx:TextArea id="ta" width="100%" height="100%"/>
</mx:Application>
Compile the client application into a SWF file by using Flex Builder or the mxmlc compiler, and then deploy it to your web application.
