More on Granite Data Service's with Project Founder Franck Wolff

Posted by Jon Rose on Oct 20, 2008 04:51 PM

Community

Java

Topics

Web 2.0 ,

Rich Internet Apps ,

Rich Client / Desktop

Tags

Flex ,

Web 2.0 ,

Adobe Integrated Runtime ,

Adobe ,

Flash

Earlier this year, InfoQ discussed Granite Data Services (GDS) with project founder Franck Wolff. In this post, we follow-up with Wolff to learn more about the recent 1.1 release of GDS.

Wolff started by updating InfoQ on what's new in the latest release:

GDS 1.1 was released on October, 6 with three main new features:

1. Tide: This module is intended to be a full alternative for the Cairngorm + Flex Data Management Service stack. On the Flex side, we have found Cairngorm to be a good Flex development framework but somewhat tedious to follow (numerous files required for rather simple operations). On the Java side, Flex Data Management is only available in LiveCycle Data Services, and some features required for us aren't implemented at all or not the way we expect them: standard J2EE frameworks integration (such as JBoss/Seam, Spring or plain EJB3), client-side entity caching, collection paging, and transparent lazy loading. Tide addresses all those requirements and targets for now the JBoss/Seam framework (Spring and plain EJB3 will come soon).
2. Granite Eclipse Builder: This new Eclipse builder plug-in automatically runs Gas3 (the GDS ActionScript3 generator) each time you have created or modified a Java bean (likely an entity bean). When configured for your Java project via its graphical wizard or options panel, it replicates on the fly your entire Java model to its ActionScript3 mirror. Generated beans implement all required logic for strong typing externalization, lazy-loading support, and Tide integration.
3. MXML/AS3 Web Compiler: It has the same features offered by its Adobe equivalent (on-the-fly compilation of MXML files deployed in your war), but also brings the ability to compile code from any input stream (from a simple String or a database for example). This has been contributed by Sébastien Deleuze (author of the Igenko project ) and you may test it online here.

InfoQ asked about the state of the GDS documentation:

This is still a work in progress but we have added a new "Getting Started" section with detailed tutorials for people starting with GDS developments. The reference documentation still needs some improvements, but should be updated very soon.

InfoQ followed-up on the previous interview with Wolff, asking if his previous BlazeDS and GDS comparison still held true. BlazeDS was open sourced late last year by Adobe.

I had a quick look to BlazeDS code and played with it a few times... It is a great techno, but as far as I know, it still doesn't feature some important enterprise functionalities such as full EJB3/Hibernate support (lazy loading), code generation tools, and tight integration with the JBoss/Seam and Flex Data Management Service equivalent. All those features are available in GDS 1.1, and I would again say that GDS competes more with LCDS (that still doesn't have lazy loading features) rather than with BlazeDS.

Next, InfoQ asked about the long-term roadmap for GDS:

One of the most important feature in GDS roadmap is to offer a full client-side Data Management system that integrates with (almost) all J2EE framework solutions. This is the very purpose of Tide and, as I said before, besides its current JBoss/Seam support, we will make it available for Spring and plain EJB3 technologies. Furthermore, we are looking carefully to the emerging Web Beans specification (see JSR-299) and, hopefully, we'll make a Tide/WebBeans integration available as soon as the first implementations are available.

Another feature we are going to provide is a way to facilitate upload and download operations in GDS. Currently, if you use the standard flash.net.FileReference class with GDS, you must write a servlet to carry on upload/download operations. We are going to make this easier, at least by providing a standard dedicated servlet in GDS.

On the administration side, we are going to write a GraniteDS console that will enable runtime configuration management and services exploration (something like the AMFPhp Servcice Browser).

Other directions for the long-term are a set of Flex components for data management (such as an Entity Form that constructs a Flex form from a model metadata description, etc.) and maybe streaming.

Lastly, InfoQ asked about the GDS community:

It has been almost 1 year since the 1.0 release and I have seen a continuous growth of GDS forum members (from about 100 members to 300 by now). Download rate is now more than 100 a day, but it is hard to evaluate from this data the number of developers using GDS... Very good news for GDS is that we are seeing some major companies using GDS for production applications (unfortunately, I can't say their names by now).

GDS contributors (including myself) are about dozen, though most of them are very occasional (patches or small extensions). William Draï (my colleague at Adequate Systems) and I are of course the most active, but Cameron Ingram (see his blog here) and Sébastien Deleuze (GDS Web Compiler author) have contributed, on a regular basis, with original and significant features.

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

1. Back to top

   Quick correction on LC DS Features

   Oct 20, 2008 7:08 PM by Jeff Vroom

   LiveCycle DataServices does have client-side entity caching, lazy loading of referenced objects and paging of association properties.

   Reply

2. Back to top

   Re: Quick correction on LC DS Features

   Oct 20, 2008 7:44 PM by Emmanuel Bernard

   Yes but what Franck is talking about is transparent lazy loading. While transparent is not necessarily a desirable feature per se, avoiding metadata duplication is a big plus.

   Reply

3. Back to top

   Re: Quick correction on LC DS Features

   Oct 20, 2008 8:59 PM by Jon Rose

   Also, there is a large cost difference between LiveCycle and Granite. Hopefully, the EJB3 support will make it into BlazeDS one of these days...

   Reply

4. Back to top

   Re: Quick correction on LC DS Features

   Oct 21, 2008 4:48 AM by William Draï

   More than the cost difference, the architectures of the two solutions are also completely different (and probably complementary). With LCDS, the Flex client interacts almost directly with the database through Data Services, and the business logic is on the client, one the goals being not to have a service layer at all. LCDS itself manages the persistence of the data model, and requires lots of configuration for each managed entity to do this, partly duplicating the Hibernate entity mapping. With GDS, you keep the business logic in the J2EE services, and the Flex client can just use these services by exchanging Hibernate/JPA detached objects without having to write any service wrapper. Except for lazy loading, GDS never accesses Hibernate/JPA directly and does not need any particular configuration for persistence. Each approach has its pros and cons but we think that supporting detached entities with a clean J2EE service layer brings significant value for Flex/J2EE users.

   Reply

5. Back to top

   Re: Quick correction on LC DS Features

   Nov 7, 2008 11:58 AM by Jeff Vroom

   Another clarification on the LCDS features: * All client interaction is mediated by an object which implements the Assembler interface. This exposes the create, update, delete, and query operations. We provide a hibernate assembler which by default just handles the persistence operations but you can easily extend that to intercept the calls, perform additional security or validation of your model before or after the persistence code. I think that for queries, it is easy to expose services directly but if you want to manage updates you need to establish more structure for your server objects. You can use LC DS just for queries and not for updates if you want. It is easy to mix and match remote object and data management use. * In LCDS2.6, the default data management configuration is pulled right from the hibernate configuration so you do not need to duplicate the entity configuration. You do still have to declare which entities you want exposed to flex clients for security purposes but that is all that is required. You can then selectively override the defaults to optimize how data is fetched: lazy fetching, paging of associations, on-demand loading of associations.

   Reply

• Older >