Unleashing the power of Flex,BlazeDS, and Java applications

First of all, Flex and BlazeDS are open sourced and free, which is important for many IT shops even those from filthy rich Wall Street companies. Typically, an enterprise IT group has a limited budget, and even though a more advanced LiveCycle Data Services component offers you more options and better scalability than BlazeDS, for most of the applications using BlazeDS installed in any Java Servlet container is a very solid way of building RIA that are a lot more superior to those built on plain HTTP let alone SOAP Web Services.

The main power of BlazeDS is its binary AMF protocol that seamlessly serializes strongly typed data between Flex and Java. Just think of the typical use case described below.

A POJO on the server side gets a bunch of Customer.java records (say, ArrayList) from a data source and needs to display them as a grid in a Web Browser. With a regular HTML/JavaScript Web application you’d need to convert the customers’ data into some kind of text representation (losing the data types information of customer data), then GZip the data, send them to the client, and using JavaScript manipulations convert the data into appropriate data types for further processing.

You don’t need to do any of these while sending the data from Java on the server to Flex on the client. The ArrayList of customers gets serialized/deserialized into an ActionScript ArrayCollectoin of strongly typed data transfer objects defined in the class Customer.as.

HTTP batching and streaming is a combination of few technologies with a close resemblance to how car traffic is controlled on some highways. There are dedicated lanes for high-occupancy vehicles (HOV) that move faster during the rush hours. Such HOV lanes can be compared to the
HTTP channels opened for streaming. For example, you can program network communications in such way that one channel allows only two data pushes per second (a guaranteed QoS), while the other channel will try to push all the data, which may cause network congestion, delays, and queuing.

With AMF, the data gets loaded faster than with nonbatched requests/responses. And it plays nicely with the typical infrastructures that use firewalls as it piggybacks on the existing browser HTTP requests.

However, for critical HTML/JavaScript applications a problem remains: there is no QoS provided by HTTP protocol, which may become a showstopper. For example, think of a financial application that sends real-time price quotes to the users. The server keeps sending messages, regardless of the current throughput of the network, which in case of network congestion will be causing problems with queues overruns or lost packages.

Recently released LCDS 3 has introduced features to support reliable messaging and throttling, while BlazeDS won’t have it. This is when opensourceness of Flex and BlazeDS becomes handy, because it allows you to customize communication protocols to perfectly meet all the needs of your application and squeeze out a lot more performance from BlazeDS than it’s advertised by Adobe.

How do you even start customizing network protocols? Even the idea of doing this sounds scary, right? It won’t be, if you’ll attend our Master Class in Brussells, Belgium in March: http://www.eventbrite.com/event/527934065. We are planning to run a couple of more if these events in the USA too. Let me throw in some technical terms now since not everyone can appreciate the quality of the Belgium beer yet.

If you open the server-side configuration file services-config.xml that comes with BlazeDS, you’ll find declarations of several communication channels there, for example:

<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"/>

This is an example of configured AMF communication channel. There are three important notions to understand here.

1. AMF operates using messaging under the hood. When you make an RPC call to a remote Java class (a.k.a. destination). Flash Player sends messages to the server, and you can change the way messages are being formed or processed.

2. On the client side (Flex) the ActionScript class a.k.a. channel can be customized, if need be. In the example above this would be the class mx.messaging.channel.AMFChannel.

3. On the server side, there are two Java classes that can be customized: an endpoint (see above flex.messaging.endpoints.AMFEndpoint) and adapter.

Let’s say, you want to ensure that every message header includes a userID that has been authenticated during the logon process, you can do it by customizing the channel and the endpoint classes. This way you won’t need to pass the user ID with every application-specific RPC call.

Two years ago, one of our financial clients was concerned with potential out-of-sequence messages in a trading workflow. Back than it was the application based on LCDS 2.5, which didn’t offer any support in this area. We’ve customized the channel and adapter to provide this functionality. We’ve also implemented throttling to slow down the message pushes in congestion situations. The same things can be implemented with BlazeDS.

Or let’s take another real-world situation when an extra security is required: the client’s workstation has to be automatically logged off and disconnected, if the server didn’t respond during a specified time interval. To put it simple, we need to implement some kinds of heartbeats. Yes, you can customize the AMF protocol so it’ll process heartbeats between the Flex client and Java server.

Didn’t respond to my heartbeat within 20 second? You’re a dead man! The user get’s logged out of the system.

Need better performance with BlazeDS? Introduce a non-blocking I/O.
How about an idea of a reverse RPC call? I mean what I mean. A Java server calls a specified function on the user’s (Flex) application passing whatever arguments are required by the function.

“You may say, I’m a dreamer. But I’m not the only one”, sang John Lennon.

For some reason, most of the RIA developers are into flashy UI as it’s considered to be uber cool. But don’t underestimate the power of the networking protocols in general and of AMF in BlazeDS in particular. At least I know, where the power of Flex and Java EE application is hidden.

Yakov Fain

6 thoughts on “Unleashing the power of Flex,BlazeDS, and Java applications

  1. Hi Yakov,

    Great post! We just had this question come up this week about LCDS and whether to use AMF vs RTMP. We are sticking with RTMP for now. I’ve read many posts comparing and discussing the different channels. Do you see any issues with this?

    Laurie Hall

  2. As opposed to AMF, RTMP is a duplex channel that works great… if you can afford it. It’ll also require you to open a dedicated port, which may present challenges if you have customers sitting behind the firewall and can’t use any ports other than 80.
    Read Chapter 6 of our book “Enterprise development with Flex” – it has detailed comparison of protocols and a lot more goodies: http://my.safaribooksonline.com/9780596801465.

  3. Privet Yakov,

    It’s true what you say about lim ited budgets. I’m currently in a big bank and we use Blaze DS. In a former (much smaller) company, we were using LCDS…

    Concerning LCDS, have you implemented something for the case where you need to detect changes performed on the database by a process and broadcast this change ? Jeff Vroom was suggesting to use a database trigger, send a JMS message to the LCDS and from there, using some helper Java classes provided by Adobe, broadcast the change to clients through RTMP. But we never got to the point of implementing it. This is something not doable just with XML configuration files. Also, did you have this case in Blaze DS too, using Flex messaging instead ?

    Best regards,

  4. @Karl

    We’ve implemented data synchronization in our Clear Data Builder that works with BlazeDS and sends notifications to all users who work with this piece of data when its changed by one of the users. If you have a case of an independent (not Flex) process changing data, your database has to somehow notify a POJO (a trigger with JMS is one of the ways), and then have BlazeDS push the data from the server to your Flex clients. All this is doable without the need to have LCDS.

  5. I am curious if you have ever considered or evaluated wiring Red5 (the open source RTMP server) and BlazeDS together…

Comments are closed.