Granite Data Services: Open Source Flex DS Alternative

Posted by Jon Rose on Feb 05, 2008 12:56 PM

Community

Java

Topics

Rich Internet Apps ,

Web 2.0 ,

Open Source ,

Rich Client / Desktop ,

Web Frameworks ,

Data Access

Tags

Adobe Integrated Runtime ,

Adobe ,

Flash ,

Flex

Granite Data Services (GDS)is an open source alternative to Adobe’s LiveCycle Data Services andthe recently open sourced Blaze Data Services. Last week, GDS reachedproduction status with their 1.0 release. GDS is available under theLGPL license. InfoQ.com spoke with the GDS project founder, FranckWolff, 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 DataServices with a special emphasis on integrating with JEE technologies,including well known Java EE persistence systems (such asEjb3/Hibernate, with full lazy-loading support). GDS lets you usestandard Flex 2+ RemoteObjects, providing full benefits from the AMF3serialization. In addition, GDS provides support for a number oftechnologies:

• 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, GDSalso comes with an ActionScript3 code generator (Gas3), which greatlyaccelerates Flex application development. GDS, together with the FlexBuilder IDE, or the free Flex SDK, provides developers with a completeand powerful framework for Flex application development and deployment.

On the project status:

The historical part of GDS (Ejb3, Spring, Pojo and Gas3) has beenwidely used and is production ready, which is why we were able to jumpdirectly from the 0.4 to the 1.0 version. The new features recentlyintroduced in GDS 1.0 (Seam, Guice services, and Data Push) should beconsidered beta software.

GDS is actively developed by two Adequate Systemsdevelopers (William Draï and myself). In addition, many other peoplefrom the Open Source community have contributed to GDS developmentsince 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 thatensures uniqueness (only one instance of each entity is present in theFlash VM). One important feature of this repository will be totransparently initialize lazy associations when they are required onthe Flex side. This feature is loosely inspired by Cairngorm.

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

The final goal would beto create a full data management system on the Flex side, withautomatic form creation (entity edition panel) and validation (thatreplicates 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 servicewith AMF3 messages sent over HTTP (no RTMP, no specific internet port),and is freely based on the Bayeux protocol. This implementation isavailable for Tomcat 6.0.14+, JBoss 4.2.2+, and Jetty Continuations6.1.15+. Gravity also provides JMS adapter support as described in Flexdocumentation here.

In the client code, we couldn't use standard mx.messaging.Consumer andmx.messaging.Producer because the Consumer class was removed from theFlex 3 SDK. So, we implemented our own Consumer/Producer ActionScriptclasses, with the same properties and methods, with only onedifference: the "subtopic" property has been renamed "topic" (to ensureboth Flex 2 and Flex 3 compatibility). We also created a specificchannel (org.granite.gravity.channels.GravityChannel) that must be usedin services-config.xml files for data push destinations. In short, thischannel encapsulates two flash.net.URLStream instances (command andtunnel) 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. LetGas3 generate ActionsScript3 beans that replicate your entity beansproperties (Flex client side model beans), and have Hibernate toolsgenerate 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 EJB3persistence layer and brings a very important and unique feature (whicheven LCDS doesn't seem to provide): when using object/relationalpersistence tools like Hibernate, you may face the risk of loading yourentire database if you don't use any lazy fetching strategy. GDSsupports both proxy (single-valued association) and lazy fetching forcollections.

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

The BlazeDS documentation states that ithas an "open adapter architecture" that lets you "easily integrate withJMS, EJBs, ColdFusion components, and other data sources." From thispoint of view, there are no big differences between GraniteDS andBlazeDS, 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 controlover every part of the serialization process, and support for specialtypes.

Surprisingly, BlazeDS and GDS data pushimplementations are both based on the same kind of Comet-likearchitecture. GDS announced this implementation choice during thesummer of 2007 on the GDS site, long before any BlazeDS announcement.So, the data push implementations are likely very similar (BlazeDSsource code is not yet available), but GDS brings unique support forJetty (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 technologiessuch as Hibernate, you will certainly feel the importance of aframework that takes great care of your lazy fetching strategy. One ofthe most important features of GDS (and one of the main reasons of itscreation) was the possibility to use exact ActionScript3 copies ofHibernate detached objects on the client side, just like if we were inthe web layer of a classical Java EE application. This does not seem tobe possible at all with BlazeDS, and that means that you cannot justreplace GDS with BlazeDS. Additionally, you'll be able to use Gas3 codegeneration 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 tokeep a clear functional separation between BlazeDS and LCDS (no datamanagement in BlazeDS). On the other hand, GDS tries to give analternative implementation providing missing features, based on wellknown and widely adopted Java EE technologies. The only thing I can sayfor now is that if Adobe wants to put some or all GDS specific featuresin BlazeDS, I will certainly consider merging as a good option. In thiscase however, the problem for us (and for many GDS users I guess) willbe to get some guarantee that future BlazeDS developments will fit ourneeds.

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