Java and Rich Internet Applications

Main menu

Post navigation

Data Management with GraniteDS

Introduction

Flex itself can’t access any backend Java logic. One could use HTTP Services to access backend systems but if you want to transfert data as quick as possible you should use something like Adobe BlazeDS or GraniteDS. BlazeDS is provided by Adobe and does not have several features the commercial product LiveCycle Data Services provides ( click here for a comparison chart ).

For our project we create at work two features were essential BlazeDS does not provide:

handling lazy loading

data management ( aka data-push)

LiveCycle Data Services is much to expensive so I looked around and found GraniteDS. GraniteDS is a open source solution which provides enough functionality to replace ( at least in our project ) Adobe Live Data Services.

Unfortunately the documentation for GraniteDS is not so comprehensive, one has to collect it’s information from various blogs and it is difficult for a beginner to get data management running ( at least it was for me ). Florian Müller wrote an good article about GraniteDS in the german Java Magazin June 2010 and July 2010 in which he gave an introduction to GraniteDS and data management for beginners.

But – I don’t like this but – Florian didn’t use my technology stack. He used J2EE, I use Spring and each backend technology needs it’s own configuration. So I decided to modify Florian’s example so it works with Spring on the server side. My example is not as stylish as Florian’s, but it works and should help anybody to get in touch with GraniteDS and Spring.

Examples

Often it is better to see an example before reading the details. The Video shows what data management means in practice.

If you prefer to explore the examples by yourself, please follow this link. I advocate to open the application in two different browsers ( or even on two different computers ) so you can be shure the data management is done by the server and not faked in the browser.

Preparations on the client side

To get GraniteDS and DataManagement running there must be things done in the Flex client code and on the server side. Let’s start with the client. GraniteDS uses the Tide framework to sync objects on Flex client and Java server side.

In the Flex client application there must be done two major steps.

Initialise Tide Spring context

The Tide context has to be initialised. There are several contexts available, in this example the Spring context is used because Spring is the framework we use on the server side. The preinit phase of the application is ideal to run the initialisation method:private function preinit():void
{
Spring.getInstance().initApplication();
Spring.getInstance().addComponent("myTopic", DataObserver);
Spring.getInstance().addComponentWithFactory("serviceInitializer", DefaultServiceInitializer, {contextRoot: "/granite-spring-tide"});
}

It is absolutely necessary to set the contextRoot of the application. In case of the example application this has to be “/granite-spring-tide” because the WAR file as the result of the maven build process is named granite-spring-tide.war and is automatically deployed in “/granite-spring-tide” (at least on a standard Tomcat installation).

Register to message channel

After the initialisation the tide spring context has to be register itself for messages on the message channel provided by the server side to be informed if a managed object changes. As the name of the method suggests this is done in the initialization phase of the application.
private function init():void
{
// client server synchronization init
tideContext.myTopic.subscribe();
}

Model Design

Model objects (aka ValueObjects aka Beans aka… whatever) used in the application like the Employee object have to extend an AbstractEntity object. This AbstractEntity contains some attributes which are required by Tide to recognize changes in the object. A generated AbstractEntityBase object generated by the GraniteDS Gas3 AS3 object generator could look like this:
/**
* Generated by Gas3 v2.1.0 (Granite Data Services).
*
* WARNING: DO NOT CHANGE THIS FILE. IT MAY BE OVERWRITTEN EACH TIME YOU USE
* THE GENERATOR. INSTEAD, EDIT THE INHERITED CLASS (AbstractEntity.as).
*/

If your development process is to implement the Java objects first, then you can generate all AS3 objects automatically using the Gas3 object generator. In this example this was done using maven (see example sources).

GraniteDS server side

The main steps are done on client side, now the server side has to be prepared.

Implement Java backend

The Java backend can be implemented as usual using the Spring framework. Feel free to express yourself! ;)
The only thing you have to do is to extend the AbstractEntity Java object in all your model objects. The AbstractEntity may look like this:
package org.graniteds.test.spring.model;

As you can see only the annotation “@EntityListeners({DataPublishListener.class})” is Tide specific, all the rest are standard Java persistence annotations.

In the service implementations (of course the services are implemented against interfaces in this example) need some special Tide annotations like theses:
@TideEnabled
@DataEnabled(topic = "myTopic", params = ObserveAllPublishAll.class, publish = PublishMode.ON_SUCCESS)

Personally I don’t like to have Tide dependencies in my backend Java logic but I didn’t find another working solution. Please leave a note if you have a more elegant approach which decouples Tide and the Java backend implementation.

Web Application

For the example I created a GraniteEmployeeService in the webapplication ( in hope not to be able to decouple Tide and the Java backend ). This service has the same Tide annotations like the Java services backend implementations and there is nothing special in this service.

Spring application context

To make the GraniteEmployeeService available in the Flex client you have to add this

in your spring application context file. I was not able to configure the flex-filter in this place so I was forced to add a services-config.xml in the /WEB-INF/flex webapplication folder (please see the content in the provided sources).

web.xml

In the web.xml you have to add a GraniteConfigListener beside the normal Spring ContextLoaderListener and you have to register a GravityServlet beside the Spring DispatcherServlet. For the example Tomcat was used so the GravityTomcatServlet listener.

4 thoughts on “Data Management with GraniteDS”

can you give some more information under which circumstances the datamanagement does not work? I tested my example application and datamanagement works.
If you built your own version from the sources and deployed it in a tomcat 6.x server it is absolutely necessary to install the tomcat native library.

Hi,
fine article – Thanks for your work. I am looking for a tutorial on how to set up the basic development infrastructure. I found a lot of information about implementing the data management, but unfortunately no ressource what I have to install on either client side or server side. Do you know any source for that ?
Regards