Flex, GraniteDS and the Future of RIA | Granite Data Services


News and Updates

Flex, GraniteDS and the Future of RIA

By Franck December 6th, 2011 GraniteDS 4 Comments

After the recent announcements from Adobe regarding the future of the Flex framework (see, for example, this ) and, unofficially, from Microsoft about Silverlight (see ), the RIA world have been deeply shaken up and it is now time to look at the viable solutions left to the developers.

Before digging into what we, at GraniteDS, think about the Flex and RIA future and how it is influencing our platform roadmap, let’s see who are the different players in this area:

  • Flex (Adobe / Apache Foundation): one of best RIA solution right now, based on the Flash plugin.
  • Silverlight (Microsoft): another very good RIA solution, based on the plugin of the same name.
  • JavaFX (Sun / Oracle): emerging, based on the Java plugin, could be a good alternative if it comes on time.
  • GWT (Google), ExtJS (Sencha) and a plethora of others: good or emerging RIA solutions, no plugin required, targeted at HTML / JavaScript and the pending HTML5 specification.

Now let’s see what Flex brings to the table that makes it such a compelling solution for enterprise applications: a very good IDE and tooling, a strong language (ActionScript3), very good performance and cross-browser compatibility thanks to the Flash Player runtime, a great UI framework with plenty of advanced features (sophisticated component lifecycle, data binding, modularity, skinning, media capabilities, etc.), a good set of built-in, open source and for-pay components, and recently the ability to build cross-platform iOS / Android mobile applications from the same source code with the AIR runtime. All things that made possible for us to build our GraniteDS platform on a strong foundation.

All those capabilities are at worst inexistent, at best very partially matched by the existing alternatives. Without Flex and Silverlight, enterprise RIA developers are left with good but (while at different extents) emerging or less featured frameworks. There is not any doubt that it is possible to build enterprise applications with them, but the development will be much slower than with Flex or Silverlight, less maintainable, missing many advanced features and will require long and extensive testing on the various target browsers. Moreover the landscape of client technologies is evolving at an extremely fast pace with new frameworks, JavaScript evolutions or replacements such as Google Dart or ECMAScript 6 (Harmony), announced almost every day, and it’s very difficult to make a perennial choice right now.

You might have noticed that we only marginally mention HTML5 as an alternative. Indeed we think that HTML5 as it currently exists really is more an alternative to the Flash Player than to the Flex framework. You will always need complementary frameworks and component libraries to get a really usable development platform, and a big issue is that there is no common standard component model that ensures that all this stuff will work happily together. And while some of these HTML5-based frameworks will certainly become strong RIA platforms in the future, they are right now simply not as feature rich and stable as Flex and Silverlight can be, and most likely won’t be in the coming years. There is simply nothing that can replace Flex today.

What Future for the Flex Framework?

According to Adobe, the entire Flex framework will be soon given to the Apache Foundation. This is great news, from an openness and licensing point of vue, but it could also lead to a slow death of this great solution if nobody is truly committed into its development and maintenance. While Adobe seems to be willing to bind some of its own resources on the framework future, we think that a large part of the Flex community should be involved and we are very exited with the idea of participating to the Flex framework evolution.

While a participation as simple contributors is very likely, we wish to take a bigger part in the governance of the project. Of course this is subject to the choices of Adobe and the Apache Foundation concerning the people involved in this governance but, as a significant player in the Flex area, the GraniteDS team should be one of the natural choices in this community selection process.

If Flex as an Apache Foundation project is widely open to community contributors, we believe that it will remain the most powerful RIA platform in the future and may lead the industry for years to come until HTML5 or one of its next iterations can finally provide a credible solution. Flex is not going to disappear in the foreseeable future and is still the better choice for developing rich enterprise applications.

LCDS, BlazeDS and GraniteDS

GraniteDS has been the main alternative to LCDS (Livecycle Data Services) from the beginning and, after more than 5 years of polishing and improvements, it is a widely used, stable, production-ready, open-source and feature-rich solution for enterprise Flex / Java EE developments. It is also known as offering many strong advantages over BlazeDS and you will find a detailed comparison between GraniteDS and BlazeDS here, as well as a step-by-step migration guide.

According to another recent , Adobe is unlikely going to publish any new major release of LCDS, speaking only about supporting existing customers and applications. LCDS isn’t anymore bundled as a standalone product but is now sold as a module of a much larger platform, the . From its part, BlazeDS hasn’t really evolved during the last 1 or 2 years, and its maturation as an Apache Foundation project is at least questionable.

From an architectural point of vue, GraniteDS has always promoted a strong server-side approach, based on remote services that implement the most significant part of the business logic and a client application that is mostly a presentation layer. The main advantages of this approach are the independence of the server application from the client-side technology (Flex or any other) and the ability to leverage the full power of existing Java EE frameworks such as Spring, JBoss Seam, EJB3 and now CDI. This clearly differs from the classical client-server architecture promoted by LCDS, where almost all the business logic goes to the client-side, the server being not much more than a database frontend.

Another obvious advantage of this approach is the ability to migrate an existing Flex application to another RIA technology without having to change anything on the server application. The same applies when there is a need to create multi-headed client applications, targeted at different platforms (Flex, Android, iOS, HTML5, etc.). Using GraniteDS makes your application as future-proof as possible in this quickly evolving technology environment, while still benefiting from all its advanced enterprise features (lazy-loading, paging, real-time data push, etc.)

GraniteDS Roadmap

After the recent release of the 2.3.0.GA version of our platform (see details here) and a new Eclipse wizard plugin that dramatically simplifies GraniteDS’ projects creation (see here), we are moving to a major evolution of the framework. Among several other new features and improvements, the next 3.0 version will focus on the following areas:

  • Client libraries for iOS (Objective-C), Android (Java) and HTML5 (JavaScript): the purpose of these libraries is to implement the most salient features of the Flex / GraniteDS client framework in other technological contexts. Remoting, real-time messaging and data management will be available for each of these targeted platforms, without changing anything to the server-side implementation of current GraniteDS / Flex applications.
  • Code generation improvements (Gas3): generated code won’t be only targeted at ActionScript3, but also at Objective-C, Java and JavaScript.
  • Clean separation between data management and dependency injection features (Tide): this will allow an easier integration of Flex client framework (Spring ActionScript, Cairngorm, Parsley, Swiz, etc.) with GraniteDS’ data management module, and greatly simplify the implementation of data management for other client technologies.
  • An improved implementation of the real-time messaging system (Gravity): support of clustered and durable JMS subscriptions, reduced data transfers and WebSocket support.
  • Full OSGi / Java EE 6 compliance: GraniteDS conforms to standard and popular specifications, in order to be compatible with all application servers.
  • New distribution model (Community Platform): packaged as a ready-to-run test drive, it will greatly improve the getting started experience of the framework.

Overall, these new features are aiming to improve GraniteDS ease of use, enlarge its features and target platforms perimeter and help users in leveraging today’s and tomorrow’s best technical solutions.

Moving Forward

From all of the above, we believe that the GraniteDS platform, with its enterprise-grade features, uncompromised Java EE integration, professional support and openness to a wide range of client technologies can be considered as one of the best available platform for perennial RIA developments.

Through its continuous move toward new client technologies, GraniteDS will stay open to strong partnerships with IDE and graphical components providers, and committed to offer an open-source, comprehensive and powerful solution for Java EE developers willing to leverage the best of this renewed RIA world.


  1. December 8th, 2011

    You want to be involved? Take a larger part of the governance? You should make sure and join spoon

    That is exactly what we are doing

  2. December 11th, 2011

    I’d like to add the following … “Where could Flash- and Flex-Coding be in the year 2050?�?:

    Please read and disagree ;)

  3. Brady
    December 19th, 2011

    Out of interest when is the likely release dates for 3.0

  4. dgesang
    July 27th, 2012

    Hi, short question: will this be available in the near future (couple of weeks):

    * Clean separation between data management and dependency injection features (Tide)

Post Comment

Your email address will not be published. Required fields are marked *