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

Posted by Jon Rose on Dec 17, 2007

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Messaging ,

Ruby ,

Open Source ,

Java ,

Licensing ,

Rich Internet Apps ,

Rich Client / Desktop ,

Architecture

Tags

Adobe ,

Adobe Integrated Runtime ,

Apollo ,

Flash ,

Flex

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:

Hi,

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.

Regards,
Franck.

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!

Cheers,
Franck.

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.

1. Back to top

   GraniteDS Push & Messaging Features (experimental but available)

   by Franck Wolff

   Hi Jon,
   
   First of all, thanks for this good post about BlazeDS and GraniteDS.
   
   However, I would like to make a little correction about your "push and messaging features lacking in GraniteDS" sentence: GraniteDS does actually have this feature (though experimental) and a working chat demo: you may download daily build snapshots here. It will be fully documented in the next 1.0.0 release (scheduled for the end of january, while a 1.0.0_RC1 is coming before the end of this week).
   
   Finally, I want to thank Adobe for BlazeDS and I sincerely hope we would find a way to collaborate.

   Reply

2. Back to top

   Re: GraniteDS Push & Messaging Features (experimental but available)

   by Jon Rose

   Thanks for the update Franck. I have been working with the current 0.4.0 release, and I was unaware that development was so far along beyond that release. Also, thanks for GraniteDS, as it was/is an important alternative to FDS/LiveCycle DS.

   Reply

3. Back to top

   More on GraniteDS, BlazeDS & LiveCycleDS Data Managements Features

   by Franck Wolff

   Just to clarify few things:
   
   1. BlazeDS does not offer any data management features.
   
   2. FDS/LCDS has it own (proprietary and closed) data management system, offers (officially supported?) service factories for Spring and Hibernate (but without any lazy-loading support) and is, say, expensive.
   
   3. GraniteDS integrates with known enterprise J2EE persistence systems such as EJB3 (session and entity beans with full lazy-loading support) and with wildly used and open source frameworks such as Spring (with Acegi security) or JBoss/Seam (with conversation scope support - new, coming in the next release).
   
   4. GraniteDS provides a fast and powerful ActionScript3 code generator (Gas3): you just have to write your database model (EJB3 entity beans), Gas3 will generate corresponding ActionScript3 beans and Hibernate code generation tools will create your database tables.
   
   So, from an enterprise point of view, GraniteDS does not really compare to BlazeDS and, on the other hand, it seems to be still a powerful and free alternative to FDS/LCDS.
   
   Flex is an amazing technology and, IMHO, much more promising than any other Ajax framework, and I would be delighted if it was more opened to well known J2EE technologies on the server side (that's the very purpose of GraniteDS).

   Reply

• Older >