 Ward and Shashank Tiwari on Jun 01, 2008 04:12 PM
Applications that run on the desktop with Adobe AIR or in the browser with Flash Player usually connect to a server when they need to load or manipulate data. Developers building these applications with tools like Adobe Flex and Flash CS3 have a variety of options for enabling their applications to communicate with servers. The servers themselves can be running Java, ColdFusion, .Net, PHP, Ruby or any number of other server-side technologies. Regardless of the server-side technology in place, some sort of network communication is needed when the client-side application running in Flash Player or Adobe AIR needs to communicate with the server. Usually this communication happens over HTTP - the same protocol used by the web browser to load web pages and applications. But differences in how data is passed over HTTP can dramatically reduce application performance as well as developer productivity.
Download the Free Adobe® Flex® Builder 3 Trial
Adobe® Rich Internet Application Project Portal
Adobe® Rich Internet Application Project Portal
Download the Free Adobe® Flex® Builder 3 Trial
Adobe® Flash® Platform Overview PDF
Many applications running in Adobe AIR or Flash Player use XML-over-HTTP technologies, such as SOAP or REST, to move data between the client and server. This method is simple and fairly easy to set up. Every server technology can easily speak XML since it is a text-based protocol. XML is perfect when protocol transparency is necessary. For instance, Flickr's web services use RESTful-style XML over HTTP. This allows any developer using any technology to easily interact with Flickr by sending simple text-based requests to Flickr. Flickr then responds with simple XML, which makes it easy for developers to easily parse and use the data. One downside to text-based protocols like XML is that the additional layer of data abstraction is usually cumbersome to write and maintain. In addition, this data abstraction layer consumes resources on the server-side and client-side when the data is serialized and deserialized (see Figure 1).
Figure 1. AMF reduces the layers for marshalling data over the wire
For some time, Flash Player has supported a transport protocol that alleviates the unnecessary bottlenecks associated with text-based protocols and provides developers a simpler method of communicating with servers. Called Action Message Format (AMF), this binary protocol for exchanging data can be used over HTTP in place of text-based protocols that transmit XML. Applications using AMF can eliminate an unnecessary data abstraction layer and communicate more efficiently with servers. To see a demonstration of the performance advantages of AMF, check out the Census RIA Benchmark application..
BlazeDS includes a Java implementation of AMF which is used for remotely communicating with server-side Java objects as well as for passing messages between clients. BlazeDS remoting technology allows developers to easily call methods on Plain old Java objects (POJOs), Spring services, or EJBs. Developers can use the messaging system to easily send messages from the client to the server or from the server to client. BlazeDS can also be linked to other messaging systems such as JMS or ActiveMQ. Because the remoting and messaging technologies use AMF over HTTP they gain the performance benefits of AMF as well as the simplicity of not having to deal with an additional data abstraction layer. BlazeDS works with a wide range of Java-based application servers, including Tomcat, WebSphere, WebLogic, JBoss, and ColdFusion. In addition, BlazeDS can easily be used in Flex applications for the web (running in Flash Player) and the desktop (running in Adobe AIR).
Developers can begin using BlazeDS today by downloading the prerelease version from Adobe Labs. To get started, simply deploy the blazeds-samples.war file in any servlet container. This web application contains a number of preconfigured sample applications that can be accessed at (The port may vary depending on your application server and server configuration).
To begin using the BlazeDS Remoting Service in your applications, follow these simple steps:
To use the BlazeDS Messaging Service, follow these simple steps:
That is all you need to do to efficiently make remote requests to your back-end Java objects and utilize the messaging system with BlazeDS! Let's walk through those steps in more detail using Eclipse and Flex Builder. You will need the following software installed:
To create a simple Remoting Application:
public class HelloWorld {
public String sayHello(String name) {
return "hello, " + name;
}
}
<destination id="HelloWorld">
<properties>
<source>HelloWorld</source>
</properties>
</destination>
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:
<mx:RemoteObject
<mx:TextInput
<mx:Label
</mx:Application>
Explanation: The Flex application is using the RemoteObject library to communicate with the BlazeDS-enabled server. When the user enters text in the TextInput box, the change event causes the RemoteObject to make a request to the server. The server then makes a request to the Java Class specified in the remoting destination configuration. This could also call a Spring service or EJB session bean, however this example just calls a POJO. In this example, the POJO's return value is simply the name string passed to it appended to "hello, ". When the object returns a value, that value is serialized into AMF and returned to the Flex application. The RemoteObject library then sets the
ro.<method name>.lastResult property to the value that was returned. (In this case
ro.sayHello.lastResult.) The result can also be obtained through a result event on the RemoteObject. Data Binding triggers the Label to display the string which was returned from the POJO. BlazeDS also supports passing typed Java objects back and forth.
Next we will build a new Flex application that uses the BlazeDS messaging system.
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:
<mx:Script>
import mx.messaging.messages.AsyncMessage;
</mx:Script>
<mx:Producer
<mx:Consumer
<mx:TextArea
<mx:TextInput
<mx:Button
</mx:Application>
Explanation: The Producer object allows Flex applications to send messages into the message system. There is also a Java API (not used in this example) which allows messages to be sent into the message system on the server. With a custom adapter or the out-of-the-box JMS adapter you can also connect the message system to other messaging systems, however by default the message system runs standalone. When the user clicks the send button a new message is created using an anonymous object to set the msg property on the body of the message to the value in the TextInput. Because, the message type is an AsyncMessage, that class must be imported. The Consumer object allows Flex applications to listen for messages. When the application has initialized, it subscribes to the message system. Then when a message is received the event handler on the Consumer takes the chat message out of the body of the message and appends it to the TextArea.
Using BlazeDS and AMF will help to reduce your development time and will help your applications run faster. Give BlazeDS a try and let us know what you think! You can find out more about BlazeDS and the open AMF specification from the BlazeDS page in Adobe Labs. its frameworks beginning in the late 90's. Today he primarily uses Flex to build beautiful front-ends for Java based back-ends. Prior to working at Adobe, James built a rich marketing and customer service portal for Pillar Data Systems. James Ward's blog can be found at.
Shashank Tiwari is of languages, including Java, ActionScript, Python, Perl, PHP, C++, Groovy, JavaScript, Ruby and Matlab. He is a popular blogger on the O'Reilly Network. These days he is busy building web 2.0 applications using Flex and Java. More information about him can be obtained at.
Nice Article for Blaze ds starters. I have already taken an initial look at Blaze DS, but I am not sure if Blaze ds supports server push, if yes please provide some links or examples. Because I read in one of the blogs that this is what (RMTP supprt) Blaze DS lags compared to LCDS. Thanks Siva. My Blog:
Hi, BlazeDS provides push functionality through HTTP (not RTMP). You can have a look at BlazeDS documentation. IMHO, and after using it on a real project, the problem with BlazeDS is that it lacks a Hibernate Adapter (provided by LCDS). Without it, you *cannot* send any persistent bean to Flex client side. In other words, BlazeDS is useless when integrating a real JavaEE application server !
Hi Bruno,
You might want to look into the dpHibernate project.
You could also just use a Spring or Pojo layer between Hibernate and Blaze.
-James
Whoops. Screwed up the dpHibernate link. Here it is:
Hi James,
Well, my opinion is not neutral : I already worked on the subject (cf.)
But I still think that Adobe should provide the Hibernate Adapter as they do with LCDS.
Regards
Bruno
Hmm there seems to be a problem, There is no direct Java Producer provided by Blase ds, which can simply produce the messages and send them all clients subscribed, only JMSproducer is provided which may not be of "Great use", I think the only other way of doing this is via MessageBroker.
Let me know if there is any direct way of creating a producer on the Java side (Server).
Thanks.
Siva Prasanna Kumar
Hi. Any plans on having Hibernate lazy loading supported? Until that, if you use hibernate and BlazeDS your must eagerly load all attributes and objects, which is a tremendous waste of bandwidth and local resources.
Not a problem with blaze ds, it happens when you try to serialize persistent objects and send them because you've bought into the persistent objects are same as POJO's myth. You have to decide what data you need on the other side and send it accordingly.
Hi. Any plans on having Hibernate lazy loading supported? Until that, if you use hibernate and BlazeDS your must eagerly load all attributes and objects, which is a tremendous waste of bandwidth and local resources.
dpHibernate and LCDS support lazy loading of Hibernate objects.
-James
and i would caution against using this. how is this any different from sending a remote object across which makes a network roundtrip every time it wants to load a relationship, transparently to the caller? regards deepak
You need to be careful about performance of AMF... I suspect it is much faster than XML...