Granite Data Services: Open Source Flex DS Alternative

Granite Data Services (GDS) is an open source alternative to Adobe’s LiveCycle Data Services and the recently open sourced Blaze Data Services. Last week, GDS reached production status with their 1.0 release. GDS is available under the LGPL license. InfoQ.com spoke with the GDS project founder, Franck Wolff, to learn more about the open source project.

Wolff provided InfoQ.com readers an overview of GDS:

Granite Data Services is an alternative to Adobe LiveCycle Data Services with a special emphasis on integrating with JEE technologies, including well known Java EE persistence systems (such as Ejb3/Hibernate, with full lazy-loading support). GDS lets you use standard Flex 2+ RemoteObjects, providing full benefits from the AMF3 serialization. In addition, GDS provides support for a number of technologies:

• Interoperability with popular web framework services
• Call server side Ejb3 session beans (with or without JBoss Seam extensions)
• Spring beans with Acegi security
• Google Guice services (with Warp persistence)
• Support for POJO services

Data Push support is a new feature in GDS 1.0. In addition, GDS also comes with an ActionScript3 code generator (Gas3), which greatly accelerates Flex application development. GDS, together with the Flex Builder IDE, or the free Flex SDK, provides developers with a complete and powerful framework for Flex application development and deployment.

On the project status:

The historical part of GDS (Ejb3, Spring, Pojo and Gas3) has been widely used and is production ready, which is why we were able to jump directly from the 0.4 to the 1.0 version. The new features recently introduced in GDS 1.0 (Seam, Guice services, and Data Push) should be considered beta software.

GDS is actively developed by two Adequate Systems developers (William Draï and myself). In addition, many other people from the Open Source community have contributed to GDS development since it was publicly launched one year ago (see GDS documentation). GDS is intended to be the server-side core of our future Flex based solutions architecture.

Wolff on the GDS roadmap and RIA architecture:

We are currently working on a client side entity repository that ensures uniqueness (only one instance of each entity is present in the Flash VM). One important feature of this repository will be to transparently initialize lazy associations when they are required on the Flex side. This feature is loosely inspired by Cairngorm.

Another important development in the road map is to improve GDS and JBoss Seam integration. I think that with the new RIA developments we face the risk of going back fifteen years ago from an architectural point of view, when the client/server paradigm was dominant. This trend could bring us to stateful clients interacting with stateless servers (i.e. a simple database front-end). While this architecture may be possible and viable for small Flex applications, I think this is not the best choice for large applications. In GDS, I want to work on the concept of stateful server components, as defined for example, by the Seam conversation and task concepts.

The final goal would be to create a full data management system on the Flex side, with automatic form creation (entity edition panel) and validation (that replicates on the client-side Hibernate validation annotations).

Wolff was asked to share more details on Data Push in GDS:

Data Push in GDS (named Gravity) is implemented as a Comet-like service with AMF3 messages sent over HTTP (no RTMP, no specific internet port), and is freely based on the Bayeux protocol. This implementation is available for Tomcat 6.0.14+, JBoss 4.2.2+, and Jetty Continuations 6.1.15+. Gravity also provides JMS adapter support as described in Flex documentation here.

In the client code, we couldn't use standard mx.messaging.Consumer and mx.messaging.Producer because the Consumer class was removed from the Flex 3 SDK. So, we implemented our own Consumer/Producer ActionScript classes, with the same properties and methods, with only one difference: the "subtopic" property has been renamed "topic" (to ensure both Flex 2 and Flex 3 compatibility). We also created a specific channel (org.granite.gravity.channels.GravityChannel) that must be used in services-config.xml files for data push destinations. In short, this channel encapsulates two flash.net.URLStream instances (command and tunnel) and supports long-polling transport.

If you are currently using mx.messaging classes, you should only have to make a few modifications:

1. Rename all your "mx.messaging.Consumer" imports to "org.granite.gravity.Consumer" (same for the Producer class).
2. Rename all "subtopic" calls to "topic".
3. Change the channel definition in your services-config.xml.

Wolff was asked to explain the Gas3 feature:

The idea with Gas3 is to:

1. Design your database model by writing Ejb3 entity beans.
2. Let Gas3 generate ActionsScript3 beans that replicate your entity beans properties (Flex client side model beans), and have Hibernate tools generate your database schema (tables and indexes creation).
3. Write your business logic with session beans, Spring, Guice, or Pojo services.
4. Write your Flex application (mxml).

Additionally, you may write your own Gas3 code generation templates and fully customize generated ActionScript3 classes.

InfoQ asked Wolff to compare GDS with BlazeDS:

BlazeDS is mainly a subset of LCDS and does not directly provide any data management features (see this picture). GDS is designed in order to provide a full integration with an EJB3 persistence layer and brings a very important and unique feature (which even LCDS doesn't seem to provide): when using object/relational persistence tools like Hibernate, you may face the risk of loading your entire database if you don't use any lazy fetching strategy. GDS supports both proxy (single-valued association) and lazy fetching for collections.

This feature is based on another unique serialization feature: Externalizers. With standard Flex AMF3 serialization (BlazeDS or LCDS), only non transient, non static public properties may be serialized. You may not serialize and keep private in your ActionScript3 beans what should be kept private (such as a versioning number, etc.). The only way to achieve this with BlazeDS or LCDS is to write your Entity Beans as Externalizable (but you must implement consistent readExternal/writeExternal methods on both Java and AS3 sides, see here). This is very tedious work, and the source of many potential and hard to find errors (and it is not even possible if you don't own the entity beans source code). With GDS Externalizers, you don't have to write your Java beans as Externalizable, and you let Gas3 generate your AS3 beans (strongly typed, with private fields kept private and lazy loading support).

The BlazeDS documentation states that it has an "open adapter architecture" that lets you "easily integrate with JMS, EJBs, ColdFusion components, and other data sources." From this point of view, there are no big differences between GraniteDS and BlazeDS, as GDS is also based on an "open adapter architecture." Developers have contributed Spring, Seam and Guice service adapters. GDS lets you customize many other things as well, including control over every part of the serialization process, and support for special types.

Surprisingly, BlazeDS and GDS data push implementations are both based on the same kind of Comet-like architecture. GDS announced this implementation choice during the summer of 2007 on the GDS site, long before any BlazeDS announcement. So, the data push implementations are likely very similar (BlazeDS source code is not yet available), but GDS brings unique support for Jetty (only Tomcat is supported in BlazeDS as far as I know).

Wolff provided an example of where it would make sense to use GDS over BlazeDS:

If you are a software provider using Java EE persistent technologies such as Hibernate, you will certainly feel the importance of a framework that takes great care of your lazy fetching strategy. One of the most important features of GDS (and one of the main reasons of its creation) was the possibility to use exact ActionScript3 copies of Hibernate detached objects on the client side, just like if we were in the web layer of a classical Java EE application. This does not seem to be possible at all with BlazeDS, and that means that you cannot just replace GDS with BlazeDS. Additionally, you'll be able to use Gas3 code generation features which are real time savers.

InfoQ asked Wolff about the possibility of ever merging with the BlazeDS project:

I haven’t had any talks with Adobe about that. I guess Adobe wants to keep a clear functional separation between BlazeDS and LCDS (no data management in BlazeDS). On the other hand, GDS tries to give an alternative implementation providing missing features, based on well known and widely adopted Java EE technologies. The only thing I can say for now is that if Adobe wants to put some or all GDS specific features in BlazeDS, I will certainly consider merging as a good option. In this case however, the problem for us (and for many GDS users I guess) will be to get some guarantee that future BlazeDS developments will fit our needs.

In closing, Wolff offered his thanks to the Open Source community:

I would like to thank again the people from the Open Source community for their great contributions to GDS.

Learn more about GDS on their site at: http://www.graniteds.org/.