Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News More on RPC in Adobe Flex Applications with AMF, BlazeDS, and/or GraniteDS

More on RPC in Adobe Flex Applications with AMF, BlazeDS, and/or GraniteDS

This item in japanese

Last week, Adobe made a major change to the Adobe Flex Platform with the announcement that much of LiveCycle Data Services is being open sourced in the BlazeDS project, including the AMF specification and code. This change should eliminate one of the final cost and licensing barriers for those considering adopting the Flex Platform.

Adobe Flex applications deploy and run in the Flash Player with the backend logic accessed via RPC, in a client-server like architecture. There are a number of different RPC options in Flex including web services, HTTP, and AMF/Data Services. AMF is a binary protocol that offers a number of benefits over the more traditional RPC methods. Adobe’s James Ward highlights the performance and bandwidth benefits of AMF in his blog post “BlazeBench: Why you want AMF and BlazeDS.”

Adobe’s Ted Patrick details the basics of AMF in his post, “The ABC’s of AMF.” Including providing the following overview of the benefits:
1. File Size - AMF objects are very small and are compressed using zlib.

2. Fast Serialization/Deserialization - AMF is transformed using native C code in the player so it is blazing fast. The AMF format was designed to serialize and deserialize quickly under low memory and slower CPU conditions. As the AMF data is parsed directly to objects, there is no lag for interpretation or parsing of AMF and creation of objects is done on a single pass.

3. Native Types and Custom classes supported - You can serialize any object in Flash Player with the only exception being displayObjects. You can also map serialized objects back to custom class instances provided the custom class is in the Flash Player when things are deserialized.
Prior to Adobe’s announcement on the open sourcing of AMF and BlazeDS, developers did have a couple of open source options for utilizing the AMF protocol, which had been reverse engineered by the community. The open source projects include RubyAMF, AMFPHP, SabreAMF, OpenAMF, and Granite Data Services (GraniteDS). Having a published AMF specification should only help to improve these implementations. The Ruby and PHP projects will still be the primary options for utilizing AMF in applications using those technologies, as BlazeDS is remoting and messaging for Java applications.

Up until now, GraniteDS has been the primary open source option for Java developers to utilize the AMF protocol. When the BlazeDS announcement came down on Thursday, the GraniteDS founder, Franck Wolff, seemed a bit caught off guard and unsure what the future held for GraniteDS. He shared his thoughts via the GraniteDS mail list on the announcement:

Well...this is great news (even if I feel a little strange about that)!

The only possible future for GDS is to give some code (I'm mainly thinking about transparent externalization, lazy-loading support, code generation) for missing features in BlazeDS)...

For now, I think I'm just going to stop any further GDS developments... Comments welcome.

After some reflection, Wolff does see a future for GraniteDS. In a clear example of open source working, he believes that there are a number of features that can be contributed to the BlazeDS project, or continue to stand-alone in the GrainteDS project.
Hi all (here is my new thinking):
  1. A bit of history: GDS was created because FDS was too expensive and, much more important, because it didn't integrate well with well known persistence API (EJB3/Hibernate) and didn't provide any lazy-loading mechanism. That's why, from the very beginning, I have created this "transparent externalization" feature (especially the HibernateExternalizer one) that serializes and keeps private all persistent related bean's fields (id, version, etc). Then, gas3 (the GDS code generator) was designed in order to avoid the tedious task of writing manually Externalizable AS3 beans.
  2. How BlazeDS compares to GDS: surprisingly, from a strict remoting point of view, BlazeDS is exactly what GDS has always wanted to be: classical AMF3 remoting with RemoteObjects and a new Comet based channel with AMF3 objects exchanged between Producers and Consumers over HTTP (no RTMP). On the other hand, from a persistence point of view, BlazeDS does not include any data management features, so GDS brings a very important missing feature: EJB3 persistence with lazy-loading support.
  3. A bit of strategy: the first release of BlazeDS (LGPL3, with sources) is announced for early 2008 (no precise schedule...) The best strategy for us is to release GDS 1.0 as soon as possible (before the end of January) and to wait for BlazeDS public sources. Then, we'll be able to either copy-paste some BlazeDS nice code into GDS (same license!) or to contribute with externalizers+lazy-loading+gas3 to BlazeDS features (if Adobe is ok) or even to release GDS has a kind of BlazeDS plugin (no idea about how this will be possible). Comments (very) welcome!
GraniteDS does have some interesting features that benefit those integrating Flex applications with Java. In addition, BlazeDS is more than just an implementation of the AMF specification, as it provides push and messaging features lacking in GraniteDS. Regardless of the implementation, it is clear that Flex developers only stand to benefit from Adobe’s move towards open sourcing more of the Flex platform.

Rate this Article