Flex for J2EE Developers: The Case for Granite Data Services
Join the DZone community and get the full member experience.
Join For FreeFor developers having worked on J2EE web applications for many years, getting into Flex will seem both very fun and familiar of the simplicity and power of ActionScript and the UI framework, and quite tedious and frustrating when it comes to developing the core application logic and the server integration.
In some ways, developing Flex applications with widely used frameworks like Cairngorm and BlazeDS involves a lot of plumbing code (business delegates, service facades, conversions between JPA entities and value objects,...) and will remind you of the days of Struts and EJB2.
Data is King
Let’s not pretend like data isn’t and won’t continue to be a nearly invaluable tool that companies and individuals alike can use to make a lot of progress towards their end goals. If we look at things objectively, it is clearly possible that data is the most valuable resource known to man at this time.
It seems like a good idea to both invest in data services and to build up one’s knowledge about what they are and why they are so important to the development of many projects at this time. If we can all learn a little more about this topic, then we stand a very good chance of being able to use data in the ways that it was designed to be used.
The Granite Data Services project was started with the (ambitious) goal of providing Flex with the same kind of development model we were used to with modern J2EE frameworks. The GDS remoting functionality has been designed from the beginning to support the serialization of JPA/Hibernate detached entities and to easily connect to the most important J2EE frameworks (EJB3, Spring, Seam, Guice).
In most cases, this removes the need to write and maintain service facades and value objects on the J2EE layer. In fact, that finally means that a Flex client can consume the exact same set of server services as a classic web application.
Another repetitive task is to build the ActionScript model classes. GraniteDS provides the Gas3 tool that can automatically generate the ActionScript model classes from the Java data model.
With the latest GraniteDS 1.1 release, the process is still improved by the Granite Eclipse builder plugin, which regenerates on the fly the necessary ActionScript classes whenever JPA entities are created or modified in the Eclipse project. You just have to write your JPA data model, and you can directly make use of the generated AS3 classes in the Flex UI layer.
This is already a big step towards a more simple server integration in Flex, but GDS 1.1 brings an even simpler programming model. It targets only JBoss Seam for now but integration with Spring and EJB3 are already on the way.
The Tide project aims at providing the same simplicity to build Flex/AIR applications that JBoss Seam has brought to J2EE. Tide requires almost no configuration during development and automates most of the plumbing code generally found for example in Cairngorm business delegates or service locators.
Contrary to other Flex frameworks whose goal is to put all business logic on the client, Tide client/server interactions are exclusively done by method calls on exposed services, allowing to respect transaction boundaries, security, and validation rules defined by these services.
Tide mainly consists of a Flex library that provides data-oriented functionality :
An entity cache ensures that all managed entity instances are unique in a Tide context. This allows in particular to maintain correct data bindings between calls to remote services.
A collection wrapping mechanism that enables transparent initialization of lazy collections.
A Flex collection component integrated with JBoss Seam’s paged query component that can be used as a data provider for Flex UI components and supports remote sorting and filtering.
Complete integration with Seam’s events, both synchronous and asynchronous, allows a Flex client to observe events raised by the server.
Flex validators integrated with server-side Hibernate validator, allowing validation messages either on the fly, or after remote calls.
Client support for Seam conversations.
A lightweight component-based Flex framework that is deeply integrated with the other features and can advantageously replace Cairngorm or PureMVC.
Let's have a look at a very simple example to see how this works.
Seam component (simply extracted from the Seam booking sample):
@Stateful @Name("hotelSearch") @Scope(ScopeType.SESSION) @Restrict("#{identity.loggedIn}") public class HotelSearchingAction implements HotelSearching { @PersistenceContext private EntityManager em; private String searchString; private int pageSize = 10; private int page; @DataModel private List hotels; public void find() { page = 0; queryHotels(); } ... private void queryHotels() { hotels = em.createQuery( "select h from Hotel h where lower(h.name) like #{pattern} " + "or lower(h.city) like #{pattern} or lower(h.zip) like #{pattern} " + "or lower(h.address) like #{pattern}") .setMaxResults(pageSize) .setFirstResult( page * pageSize ) .getResultList(); } ... public List getHotels() { return this.hotels; } public int getPageSize() { return pageSize; } public void setPageSize(int pageSize) { this.pageSize = pageSize; } @Factory(value="pattern", scope=ScopeType.EVENT) public String getSearchPattern() { return searchString == null ? "%" : '%' + searchString.toLowerCase().replace('*', '%') + '%'; } public String getSearchString() { return searchString; } public void setSearchString(String searchString) { this.searchString = searchString; } @Remove public void destroy() {} }
MXML application:
<mx:Application creationComplete="init();"> <mx:Script> [Bindable] private var tideContext:Context = Seam.getInstance().getSeamContext(); // Components initialization in a static block { Seam.getInstance().addComponents([HotelsCtl]); } [Bindable] [In] public var hotels:ArrayCollection; private function init():void { tideContext.mainAppUI = this; // Registers the application with Tide } private function search(searchString:String):void { dispatchEvent(new TideUIEvent("search", searchString)); } </mx:Script> <mx:Panel> <mx:TextInput id="fSearchString"/> <mx:Button label="Search" click="search(fSearchString.text);/> <mx:DataGrid id="dgHotels" dataProvider="{hotels}"> <mx:columns> <mx:DataGridColumn headerText="Name" dataField="name"/> <mx:DataGridColumn headerText="Address" dataField="address"/> <mx:DataGridColumn headerText="City" dataField="city"/> </mx:columns> </mx:DataGrid> </mx:Panel> </mx:Application>
Tide Flex component:
import mx.collections.ArrayCollection; [Name("hotelsCtl")] [Bindable] public class HotelsCtl { [In] public var hotels:ArrayCollection; [In] public var hotelSearch:Object; [Observer("searchForHotels")] public function search(searchString:String):void { hotelSearch.searchString = text; hotelSearch.find(); } }
Of course, this is an overly simple example but there is close to no code which seems unnecessary while having a clean separation of concerns between the UI, the client component, and the remote service. Building Flex applications could hardly be easier.
There are a lot of choices out there today for creating rich Internet applications, each with its own set of advantages. When making the decision on which path to take, you want to get started easily but without sacrificing the ability to create a robust, scalable, and maintainable application. GraniteDS maintains this balance.
Opinions expressed by DZone contributors are their own.
Comments