For several years, I worked in technical sales for Adobe France. Consequently, I met a lot of large account managers who wanted to adopt the Adobe Flash Platform to rapidly build and maintain first-class RIAs. Orange, a leading telecom provider in Europe, adopted the platform few years ago. Then MAAF, a major insurance company, chose Flex and LiveCycle Data Services (LCDS) three years ago to use Flex+Java as the IT standard for all future applications developed in the group. MAAF is migrating hundreds of client-server applications into Rich Internet Application with the support of Adobe. It was exactly the same case for Banques Populaires (a French bank), Geodis (the French FedEx) and MMA (insurance company), and that’s why they’ve also invested in Flex and LCDS. A few days ago, Crédit Agricole, the biggest French bank (7000 branch offices, more than 20 million of customers), just invested in the Adobe Flash Platform and LCDS after a year of study. They needed to define the IT standard architecture for the next generation of ebanking applications: Flex and J2EE. These companies invest in LiveCycle Data Services to leverage the advanced data services enabled by the LCDS Java libraries, develop online/offline rich applications, and also get professional support from Adobe. For these companies, the presentation layer is as strategic as the database, or the application server. That’s why they invest in the Flash Platform, and see Adobe as a technical partner as strategic as IBM or Oracle for instance.
Nevertheless, I know that Flex is successful everywhere, and not only in large organizations. A lot of software companies, small and medium businesses, and start-ups use Flex and Java to enable rich experiences. The big majority of these organizations use BlazeDS, a free and open-source subset of LCDS. Those who need more advanced mechanisms than just Remoting start looking for open-source libraries to enable deeper integrations with the Java business layer, and GraniteDS is for sure the most popular project. You may be surprised to hear that GraniteDS was created by two French Java guys, who still maintain the project: Franck Wolff and William Drai. We met few weeks ago and started chatting OVER some cheese and a bottle of Pommard 2004 (an authentic and pleasant cliché). They explained the origin of GraniteDS and the differences with LiveCycle Data Services, and they showcased the new features of the last release. Again, GraniteDS is one of the numerous projects that proves the openness of the Adobe Flash Platform and the special relationship it has with have with the Java world. Here is a summary of my meeting with Franck and William:
Hi Franck and William, can you introduce yourself, your background and your daily work?
We have been working together for about 10 years, mostly with Java / Internet technologies. We met in a start-up, later bought by Vivendi Universal, and had the opportunity of creating our own company – Adequate Systems – in late 2003. Since then, we have built and sold Internet application (Saas), using a large array of open-source software (Linux, MySQL, JBoss, Hibernate, JSF) and now the Flex framework.
Can you describe what GraniteDS is and why you started this project?
GraniteDS is a full-featured Flex development and deployment framework that integrates with the most popular J2EE frameworks (such as EJB3, Spring and Seam) and JPA engines (such as Hibernate, OpenJPA and EclipseLink). It also features advanced persistence mechanisms such as “lazy-loading”, data push connectivity (Comet-based), a complete client-side (Flex) development framework and several ActionScript3 code generation tools (Apache Ant or Eclipse plug-in).
In 2006, when Flex 2 was first released, we were looking for an innovative RIA technology and Flex seemed to be the most promising one. At that time however, Adobe only offered “Flex Data Services” (now renamed to “Live Cycle Data Services”) and this solution was outside our budget, not open-source and didn’t fit our needs in terms of architecture: we wanted to be able to reuse our existing server software and our knowledge of the J2EE stack, and Flex Data Services seemed too “client-centric”, promoting its own concepts of persistence and services deployment. Basically, we wanted to go from JSF/HTML to Flex – and not from the J2EE world to a brand new Flex world.
So we decided to build a Flex server solution that would be exactly what we were looking for, that let us build new commercial applications the way we wanted to build them and we decided to release it from the beginning under an open source license (LGPL) in order to benefit from the dynamics and the contributions of an open source community.
What are the last features implemented in GraniteDS ?
We are going to introduce three main new features in GraniteDS 2.2 (July): an ActionScript3 reflection API, an ActionScript3 implementation of big numbers (Java BigInteger / BigDecimal equivalent) and a JSR-303 (“Bean Validation”) ActionScript3 framework for form validation.
The reflection API is roughly based on the Java one and allows easy ActionScript3 class scanning for properties, methods and annotations. It also provides some advanced features with namespaces and application domains (Flex equivalent of Java class loaders).
The big numbers implementation reproduces most of the functionalities of the java.math package classes. You may now use ActionScript3 numbers with arbitrary scales and precisions, and do calculation with deterministic rounding methods. Furthermore, BigInteger and BigDecimal are correctly serialized from Java to Flex and vice-versa: you don’t face the risk of losing significant parts of your numbers because they have been approximated to the Flash Number type.
The new validation framework is a specific adaptation of the JSR-303 (Bean Validation) specification to Flex: like its Java counterpart, it relies on validation annotations placed on bean properties and provides an engine API that lets you validate your forms without writing by hand a specific validator for each of your input fields. Furthermore, it is fully integrated with the code generation tools provided by GraniteDS so that when you write your Java entity bean with validation annotations, they are automatically replicated in your ActionScript3 beans. All concepts of the JSR-303 specification are supported, such as groups, sequences, traversable resolvers, resource bundles resolution, etc.
Who do you target and what are the main differences with LCDS?
We are mostly targeting companies like us, developing and selling Java Internet software, that want to improve their existing solutions or create new RIA solutions, without renewing all their expertise and rewriting all their software. The problem with LCDS is mainly that it promotes a strict “client / server” architecture, with – roughly speaking – a heavy Flex client application connected to a server almost reduced to a database frontend. This architecture may of course be the best option for some applications and actually allows a disconnected mode, which is a key feature of LCDS.
On the other hand, you cannot quickly port an existing J2EE application to Flex with this architecture (you must rewrite almost everything) and you are tightly bound to the Flex technology: providing alternate interfaces (for some specific devices for example) or migrating to another technology requires that you duplicate entirely what you have done in your Flex application in another language and framework.
An important part of developing a Flex application with GraniteDS is “Java-centric”: you write your business model with entity beans (annotated with validation instructions), you write your server-side components with the framework of your choice (EJB3, Spring, Seam), and you let the code generation tools write their ActionScript3 equivalent on-the-fly. The Flex interface development may then use advanced features of the GraniteDS client framework (“Tide”) based on a dependency injection container and providing client-side data caching, data paging with lazy-loaded associations, etc.
Another very important feature of GraniteDS is its open source license, which may be a requirement for some companies. LCDS is now mainly targeting key accounts that need to be confident with the support and consulting offered by Adobe for strategic, long term and large-scale IT developments. With GraniteDS, we are just starting to offer support and consulting, and we are mostly targeting middle-size accounts, confident with the open source model and wanting, as far as possible, to reuse existing software and knowledge.
How do you develop and support GraniteDS, and who can contribute ?
Since GraniteDS 2.0, we have an almost full featured professional solution, and developments are now mainly guided by user requests and new specifications or technologies emerging in the J2EE world. William and I are the main contributors (at least 90% of the code) but many people have contributed important features (early Spring and Seam support, Flex web compiler, OSGi support, Grails support, JDK 1.4 port, code generation extensions, etc.) or simple patches.
Everybody can contribute and there is no hard process to get in. People usually write a patch or a new feature, send it to us, and we commit it if we feel it will be useful. If somebody that contributed this way wants to participate more actively, we give him a SVN write account. Java and Flex
developers are very welcomed to contribute, for example by providing new J2EE framework support, various improvements or even by giving good ideas.
Because of the growing recognition of GraniteDS, the growing number of commercial support requests and a first significant customer, we are now thinking of creating a dedicated company for GraniteDS. This should be done before the end of 2010 with a European and US presence.
Franck and William, thanks a lot for your time !!! I hope to see you soon guys.