1. Usage Scenarios

 Documentation Summary

The main value of GraniteDS is to provide integration with other frameworks, both client and server side, so there really are a lot of different combinations of deployment types and usage scenarios. The following chapter will describe various options, and then common combinations of technologies.

On the client there are two main choices :

• Use the standard Flex RemoteObject API. This is the easiest if you migrate an existing application from BlazeDS/LCDS/whatever AMF provider. Note however that GraniteDS does not support the standard Consumer and Producer Flex messaging API. It brings its own client implementations of these classes org.granite.gravity.Consumer and org.granite.gravity.Producer that provide similar functionality.

• Use the Tide remoting API with the GraniteDS/Tide server framework integration (supporting Spring, Seam, EJB3 and CDI). It provides the most advanced features and greatly simplifies asynchronous handling and client data management. It should be preferred for new projects or if you want to benefit from all GraniteDS functionalities.

The Tide remoting API is only a part of the Tide client framework (that supports dependency injection, conversation management, ...) so you can also choose between using the complete Tide framework or only Tide remoting mixed with any other Flex framework such as Cairngorm or PureMVC. Obviously we recommend using only the Tide framework as it will greatly simplify the overall architecture of your application, but you will still able to use Tide even if higher powers force you using another particular framework.

Finally it's also possible to use the Tide client framework independently of the GraniteDS AMF provider. We really cannot recommend doing this if your server is Java-based but you can use Tide with AMFPHP, RubyAMF or any other server technology, and Tide is comparable in features to Swiz or Parsley.

On the server there are mostly two options :

• If you use the RemoteObject API, just choose the GraniteDS service factory depending on your server framework. This will bring you the GraniteDS support for externalization of lazily loaded JPA entities/collections (but not automatic loading), and support for messaging though Gravity.

• If you use the Tide API, choose the GraniteDS/Tide service factory for your server framework. This will bring the full feature set of Tide data management and further integration with data push through Gravity. The Tide server integration also provides more specific features depending on the server framework, for example complete support for Seam security or integration with CDI events.

Spring/Hibernate on Tomcat 6 or Jetty 6

This is one of the most common use cases and is similar to what can be done with the Spring-BlazeDS integration project. You can benefit from the extensive support for serialization of Java objects, and of NIO/APR asynchronous support of Tomcat 6.0.18+ or Jetty 6 continuations.

EJB3/Hibernate on JBoss 4/5

This is another common use case and it provides roughly the same features than Spring/JPA.

Tide/Spring/Hibernate on Tomcat 6

This is an extension of the first case, with the additional use of the Tide remoting API on the client. This will enable the most advanced features such as data paging, transparent lazy-loading of collections, real-time data synchronization... Tide also provides advanced client-side support for Spring Security authorizations that fpr example allow to easily hide/disable unauthorized buttons.

Tide/EJB3/Hibernate on JBoss 4/5 or Tide/EJB3/EclipseLink on GlassFish v3

It's also similar to the previous case, but with EJB3 instead of Spring.

Tide/Seam 2/Hibernate on JBoss 4/5

This is the most natural option if you want to connect your Flex application to a Seam 2 backend. Compared to Tide/Spring, it provides an even deeper integration with Seam including support for Seam events, Query, Seam application framework...