The Evolution of Flex Data Services

The definition of rich applications developed with Flex entails far more than just a slickly implemented user interface. A good deal of the magic happens to sit behind the scenes, at the application’s backend. The core of an app’s beauty is oftentimes its real-time nature, and it’s the way that the actual app talks to the server that makes all the difference. However, apps are not created inherently equal (which is good, because they are functionally heterogeneous).

The distinction basically refers to large-scale enterprise applications and their humble real-world fellow apps, which is in terms of talking to server is LifeCycle Data Services versus BlazeDS, which in turn set themselves apart against open-sourceness.

The data services department of the Flash platform has not suffered an excess of attention on the web, even more than that, the state of documentation available as of now turns out so disappointing that it happens to work in a somewhat intimidating fashion.

A quick Data Services taxonomy should probably start with Flex Data Services, which went on to become LifeCycle Data Services, proprietary. An open source flavor was then made available with BlazeDS, a subset of the impressive LCDS feature array. This subset is best described as made up of two critical components, i.e. data remoting via RPC services that invoke remote Java objects and real-time client-server messaging for Flex and Ajax apps making use of the open source AMF protocol. Apart from that, there is also a single-CPU free version of LCDS (formerly LCDS Express Edition that could be integrated into ColdFusion 8), and a paid subscription offering for BlazeDS that provides certified builds with ongoing support on the part of Adobe (LCDS Community edition). ColdFusion 9 beta, by the way, includes BlazeDS.
In enterprise settings, LifeCycle DS can do some impressive heavy-lifting in managing large sets of data. It’s a costly solution that will pay off when applied against costly challenges, but is surely not always appropriate. It is here that BlazeDS might be able to step in (providing there is a suitable server configuration available) to enable push messaging. At the outset, one may get the erroneous impression that BlazeDS is a heavily clipped LifeCycle DS, but there’s certainly more to the story.

In fact, hands-on experience has revealed that with BlazeDS and LifeCycle DS messaging acquires certain variations in meaning which makes implementation decisions not as obvious as it might seem at the outset – as usual, the devil is to be located in the details. The pub-sub environment achievable with BlazeDS is strictly speaking not quite data push – although when applied with due care and by due means, the long-polling/data streaming approach can live up to the push messaging task at hand.