graniteds.orgCommunity Documentation
The main value of GraniteDS is to provide integration with other frameworks, both client and server side, so there really are lots of different possible combinations of deployment types and usage scenarios. This chapter will describe various options, and 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 very 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, PureMVC or Parsley. 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. The Tide framework is comparable in features to Swiz or Parsley but brings its own unique features and concepts (conversation contexts, centralized exception handling, data management...).
On the server there are mostly two options :
If you use the RemoteService API, just choose the GraniteDS service factory depending on your server framework.
This will additionally bring you the GraniteDS support for externalization of lazily loaded JPA entities/collections, and support for scalable 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 Spring security or integration with CDI events.
This section describes some classic technology stacks used with Java applications and GraniteDS.
This is one of the most common use cases and allows for easy development and deployment. You can furthermore benefit from the extensive support for serialization of Java objects and JPA detached objects, and of NIO/APR asynchronous support of Tomcat 6.0.18+ or Jetty 6 continuations.
This is another common use case and it provides roughly the same features than Spring/JPA. The main difference is that it requires a full EE container supporting EJB 3.
This is an extension of the first case, with the additional use of the Tide remoting and data management 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 authorization that for example allow to easily hide/disable buttons for unauthorized actions. This is currently the most popular technology stack.
It's also similar to the previous case, but using EJB 3 instead of Spring.
Well this is not really a "common" stack but at least it is a fully Java EE standard6. If you are on a Java EE 6 compliant application server and can live without Spring, it is definitely the best option.