|
|
The second reason why all developers should be considering the adoption of Flex is the maturity of the framework. The first major release of Flex was introduced in March 2004. Flex initially entered the market as an Enterprise application server. Since that time, Flex has undergone a number of changes both from a technology and market placement perspective. Flex 2.0 was released in June 2006 along with major improvements to the Flash Runtime, the ActionScript language, and server components. In April, Adobe announced the open sourcing of the Flex framework, which will officially come with the Flex 3.0 release due out late this year or early next year. Flex has had the time to mature and offers all software developers a robust, open source framework for delivering extraordinary user experiences.
There are, however, more specific and compelling reasons for my Java brethren to adopt Flex. Flex builds on the advances made in the Java/J2EE community over the last decade. New Java converts to the Flex programming model will find the framework, language, and tools easy to learn, as there is a familiarity in the Flex IDE and the language structures, like the Flex Collections API. The Flex development tools offer the clearest link for current Java developers. The Flex IDE is built on Eclipse, which can be used as the stand-alone Flex Builder product or as an Eclipse plug-in. Virtually all Java developers have had some exposure to the Eclipse development environment. This is a huge benefit that speeds and enhances the learning process.
In addition to the IDE, Flex also has Ant Tasks for automated builds of Flex applications, whether they are integrated with a Java application or stand-alone. Once again, Ant is a technology Java developers have all been exposed to in the Java community. With Adobe's comprehensive suite of tools, integrating Flex into your skill set is natural and enjoyable.
The Flex community has built much of the other infrastructure we are used to having when building production applications. There are frameworks ranging from testing to MVC. A good example of this is the Cairngorm MVC framework. Cairngorm is written in ActionScript 3.0 and follows many of the Core J2EE patterns. It provides Flex developers with an MVC framework for structuring their Flex presentation code and the interactions with the business services. Flex also provides API's for multiple methods of integrating with backend services, including LiveCycle Data Services ES (Data Services), Web Services, and HTTP.
LiveCycle Data Services ES deploys in a Servlet/J2EE container and provides significant server-side infrastructure to Flex applications. Data Services offers a number of features, including remoting, publish/subscribe messaging, and data management (client-server synchronization, paging, notification, Hibernate adapter, etc). The simplest use allows a Java developer to expose Plain Old Java Objects (POJO's) as back-end services via a simple configuration. Objects are transferred to the client in a compact binary format called AMF3 and converted to ActionScript 3.0 classes, which is far more efficient in the transferring and rendering time than other implementations, like XML. Combining Data Services with the popular Java POJO-based frameworks, like Hibernate and Spring, creates a truly powerful combination for building enterprise applications.
Clearly, Flex is a robust, mature framework for building rich Internet applications. With the familiarity, tools support, and ease of integration with the Java platform, it is an option that the Java developer community should seriously consider to provide end users with "richer" experiences.
In this article, I explain how Java users can use Flex to develop compelling RIAs and I guide you through building your first sample application, so you can see it in action for yourself.
Requirements
Adobe Flex Builder 2.0.1
Try
Buy
Get the Census Flex application code
Download
Why not just Java?
But, at this point in the discussion, many ask, "Why not stick with just Java?" There are many compelling reasons for the Java community to look outside of Java for better technologies for building user interfaces, besides the strong value proposition offered by Flex. Bruce Eckel has dubbed this idea, "Hybridizing Java," where we keep the good parts of Java and replace the weaker ones with non-Java technologies (see his Blog for a more in-depth discussion).
Sun did recently announce Java FX. Although Java FX is a move towards RIA for the Java platform, it does not have a release date announced as of yet. In addition, details on crucial things like deployment are still foggy at best, and early indications are a deployment model that looks strikingly similar to Applets. The Java FX example applications run in a stand-alone JRE without any apparent way to integrate them with existing browser technologies.
The premature rush to announce Java FX can be taken as little more than an acknowledgement of the industry's need to move beyond thin-client frameworks, and an endorsement by Sun of the work being done in the RIA space. With the current shortcomings of the user interface technologies in Java, the Java community should be open to looking outside of the Java family of technologies for better user interface technologies. From my review of the current RIA landscape, Flex is the most obvious and elegant solution currently available to Java developers.
Developing in Flex
Adobe Flex 2 is a user interface development framework. There are a number of technologies associated with the framework, the free Flex SDK (SDK), the Flex Builder IDE (IDE), and LiveCycle Data Services ES (Data Services). The core Flex framework can be thought of as primarily a client side technology, as Data Services is an independently licensed Adobe product that is not required for deploying a Flex application. Applications built in the Flex framework compile to the SWF format (Flash movies). Developers can use either the free Flex SDK or the Flex Builder IDE to build and compile a Flex application for deployment to the Flash Player.
The Flex development framework is written in ActionScript 3.0. ActionScript 3.0 is an object-oriented language, compliant with the latest ECMAScript standard. Flex applications typically use ActionScript 3.0 to implement the client-side domain model and client implementations for making RPC calls to the server-side components.
The Flex framework also introduces MXML, which compiles into ActionScript 3.0 classes. MXML is a mark-up language that allows developers to declaratively lay out user interfaces in their Flex applications (the "view"). Using MXML is similar to using JSP pages and tag libraries, as MXML components are typically used to implement an application's presentation logic.
Flex offers a number of different RPC methods for interfacing with server side resources. The core Flex API's do not offer any methods for direct database access. Access is abstracted through business services that can be exposed in a number of different ways including web services, HTTP, and through Data Services. This creates a natural division between the presentation and business logic, which is a best practice in the Java community.
LiveCycle Data Services ES are the easiest and most common way to expose your server-side Java objects, replacing typical RPC methods like web services for remote integration. Along with the typical RPC-like features, Data Services supports data pushes without any client-side polling and publish/subscribe messaging that integrates with JMS. An important benefit of the AMF3 binary transfer format utilized by Data Services is that it far outperforms more traditional RPC methods (see James Ward's benchmarks).
As noted above, Adobe LiveCycle Data Services ES is a separately licensed product from Adobe, but does have a free express license for single CPU deployments. Also, there are open source projects that provide similar functionality to Data Services and utilize the AMF3 format (see "Granite Data Services Overview" and "OpenAMF: Java Flash Remoting"). However, they do not have the more advanced features of LiveCycle Data Services ES, like data push. On the positive side, the client-side Flex implementation will be similar regardless of how the business services are exposed.
RIA applications built using the Adobe Flex framework are essentially in the client-server model from the past, but with a much improved deployment model than the industry faced in the early 1990's. This model allows Java developers to take advantage of the strengths and maturity of the Java platform for implementing the server-side business logic, thus allowing us to make use of our current knowledge of technologies like Hibernate, JMS, EJB, etc., while replacing the less attractive Java user interface technologies with the Flex framework. This gives us a powerful and complete set of tools with which to develop attractive, productive, rich Internet applications. How do you beat that?
Flex code in the Census sample application
Hopefully, you are excited about Flex and ready to begin learning how to incorporate it with your current skills. So, let's do what we do best and start looking at some code!
James Ward developed his Census Flex application to provide performance benchmarks for the different RPC methods in the mainstream RIA technologies. The application also ends up serving as a decent reference implementation for the multiple RPC options in Flex. You can download the full application from SourceForge under the "Flexapps" project. Please refer to the complete source code to see the fully working implementation and for examples of the other approaches to handling remote calls in Flex.
Below, I dig into James' implementation for using LiveCycle Data Services ES to manage the client-server integration of a simple database call through a Java POJO. We will take a look at code snippets for the major pieces that make up a Flex application using Data Services at the client and server application layers.
Java server-side implementation—WAR file
Data Services is deployed within a J2EE WAR file. With some simple configuration, Java POJO's are exposed to the Flex interface. As you see below, the configurations are fairly standard looking deployment descriptors.
Within the web.xml, the Flex MessageBrokerServlet is mapped to handle the Data Services requests and to load the Flex specific configuration.
