Developing Internet applications with J2EE servers today usually consists of a

presentation layer such as Struts, Tapestry, WebWork, or Spring. These tools

generally follow Model-View-Controller (MVC) architecture and output HTML to a
browser. The typical programming model for web development is to allow users to
issue requests to an application server for each action in the application. For every
action the user requests in the application, the server generates a new response
that allows the user to submit a new request for more information. A browser
typically is used to render the user interface to the user. However, browsers are thin
clients with limitations that affect both development and the end-user experience.

Rich Internet Application (RIA) technologies are emerging to handle the limitations
of the presentation layer. This article will take a pragmatic approach to
understanding what a Rich Internet Application is and how to integrate an RIA into
your architecture. It will also identify potential challenges when integrating with
some popular open source frameworks.

Browser Limitations

At one time or another, however, most web developers have complained about the
limited capabilities when using a browser as a client. Here are some current
limitations when developing web applications using a browser:

* Browsers interpret scripting languages, such as JavaScript, in an inconsistent

manner. This forces developers to write the same code multiple times to
accommodate each browser.

* Simple user interface effects such as tabbing, wizard-based forms, and large
tabular data set handling, can be cumbersome to develop and require a lot of extra
coding on a browser.

* HTML is a limited, static markup language that cannot be extended.

* Event handling within the user interface can be challenging. Because the
rendered HTML pages can only be displayed one at a time, events cannot update
another page without going back to the server.

* Serialization of application state can be achieved only through cookies, which

do not support objects.

* It is nearly impossible to develop occasionally connected clients using a

browser.

These examples reiterate what most web developers already know: current toolsets
have limitations. Developers have to find workaround solutions for some of these
challenges when working through a browser. Developers and users are outgrowing
the current capabilities of a thin client.

Rich Internet Applications

As a way to overcome some of the limitations defined above, consider Rich Internet
Application development. An RIA gives the user a thick client with extended
capabilities not available in browsers today. The most common RIA clients for J2EE
are Java and Flash. When it comes to developing large, data-centric applications,
RIAs are generally strong. Several solutions are available for developing Rich
Internet Applications including JDNC (JDesktop Network Components), Laszlo,
Thinlet, Java Web Start, and Adobe Flex.

Rich Internet Applications can help address the limitations described in the previous
section. Here is a list of features that RIAs can provide:

* RIAs offer the same UI components as browsers, plus they provide new native,
richer components. Examples include a numerical stepper, a slider control, an inline
data grid component, and a menu bar.

* Sophisticated RIA applications allow layout manager components such as tab

navigators, accordions, trees, and other layout controls comparable with AWT and
Swing development.

* RIAs provide drag-and-drop capabilities.

* Languages within the RIA are consistent across all clients and do not have to be
rewritten for different implementations.

* The request/response model is not required for every action in the user
interface. With Rich Internet Applications the user interacts with the UI and only
makes requests to the server when necessary. RIAs have the ability to post data to
the application server using HTTP protocol methods. Usually, however, the preferred
mechanism with RIAs is remoting, which is supported in different ways depending
on the RIA used. RIAs typically provide expanded sets of protocols that can
communicate over HTTP.

* Event handling across multiple components is possible.

* RIAs allow you to store more information on the client instead of using the
HttpSession. This reduces memory on the application server.

* Serialization of state, usually in the form of objects, provides the potential to

create occasionally connected clients.

Rich Internet Applications are fairly new technologies and introduce new concerns
for those developing these types of applications. They are not a silver bullet solution
for all applications, and depending on the implementation, can be experimental.
However, if you think your application can benefit from a richer UI design, then an
RIA might be for you.

Adobe Flex
Adobe Flex is a commercial presentation layer server that produces Rich Internet
Applications. The Flash plug-in is required to be installed since this is the runtime
environment for Flex applications. Most browsers already come equipped with the
Flash plug-in, which helps justify using Flex for RIA. We will discuss what it means to
use the Flash plug-in instead of a Java plug-in to communicate with a J2EE
application server.

Developers use two core languages to create Flex applications. The first core
language is MXML, the Adobe Flex Markup Language, which includes a rich set of
XML tags that allows developers to layout user interfaces. MXML can also be
referred to as an XUL, or XML UI Language. These tags can be extended, unlike
HTML, with additional capabilities that the application requires. Other MXML
constructs allow you to call remote objects, store data returned in a model, and
customize your own look and feel to MXML components.

The second core language for Flex development is ActionScript 3.0, which is an
ECMA-compliant language similar to JavaScript. ActionScript elements are coded
inside MXML pages. This is a strongly typed object-oriented language that should be
familiar to Java developers. ActionScript also has robust event handling capabilities
to allow the application to respond to dynamic user interactions. Because
ActionScript runs inside the Flash plug-in, there is no need to rewrite several
versions of the same code to support different browsers. This may not be the case
with JavaScript code in a browser.

Both MXML and ActionScript are text-based languages and can be written in a
simple text editor, an IDE tool such as Eclipse, or a more sophisticated tool like the
Flex Builder from Adobe. If you have experience with Java, XML, and a scripting
language such as JavaScript, you will experience a small learning curve to Flex
development.

The Flex server is responsible for translating the MXML and ActionScript
components into Flash bytecode in the form of .SWF files. This process is similar to
compiling JSP files into servlets by a Java

web application container. The SWF file is executed on the client in the Flash
runtime environment. The Flex server provides other services such as caching,
concurrency, and handling remote object requests.

About the Existing MVC Presentation Layer

The presentation layer in a web application is designed to render a user interface

for users, handle requests to backend services, and store data models of
information. Developers who are new to RIA development have an initial natural
tendency to want to reuse existing Struts components. However, products like Flex
provide their own MVC architecture within them.
Presentation frameworks such as Struts operate by transmitting HTML requests over
HTTP. While it is possible to use the HTTP protocol with a Flex client, developers are
encouraged to use remote object invocations over HTTP as opposed to posting HTTP
requests for performance and object-oriented gains. Therefore, using these two
presentation frameworks serially can provide a protocol mismatch. Unless you have
a specific need to integrate Struts directly with an RIA, avoid this.

Developers should utilize the RIA client for what it was intended to do. This is
definitely a shift in thinking for traditional web developers for whom the page
request/response paradigm has been familiar. RIA products like Flex are not request
or response driven like Struts. The RIA client is responsible for updating the UI
without having to go back to the server in all instances.

Integrating Flex with the Business Layer

Flex is an extensible RIA framework that provides several ways to communicate

with your J2EE components. Flex offers HTTP communication, Web service
communication, and Adobe's proprietary AMF (ActionScript Messaging Format)
gateway. The AMF gateway is a high-performance binary protocol that is
synonymous with the Flash remoting protocol. Remote objects that are sent through
the AMF gateway use the HTTP protocol. Flex offers MXML tags for each of these
communication protocols, which significantly reduces the coding complexities.
Furthermore, Flex allows you to invoke remote calls to your business tier in either an
asynchronous or synchronous manner. By using an asynchronous remote call, the
user has the ability to perform some action on the client and not be blocked as
happens in traditional web applications. You can block the user from interacting with
the UI using synchronous calls where appropriate.

Integrating Flex with the Persistence Layer

In applications that use a well defined decoupled architecture over the Web you do
not communicate with your persistence layer directly. Using Flex should not change
this architecture. The integration layer typically will communicate to your
persistence layer in most cases. This is usually done using a Data Access Object
(DAO) that is responsible for accessing data in a persistent store such as a
database. The Flex client should not communicate directly to the persistence layer
or even know about this layer because it forms a tight coupling. Let's use Hibernate
as an example of our persistence layer.

Authentication

Typical J2EE web applications have some kind of authentication scheme. This might
be a container-based authentication scheme or it might be some custom code that
authenticates the user. RIA servers such as Flex allow you to use custom
authentication forms on the Flash client and container-based authentication in most
application servers.
Summary

Whether you use Flex or another RIA implementation, there are major
considerations to take into account when architecting an application with this
technology. When evaluating an RIA framework make sure it is extensible enough to
meet the demands of the application. Furthermore, carefully evaluate integration
issues that might need attention when transmitting objects between and RIA and a
Java backend.

Implementing at CAT

At CAT implementation of Flex integrated with different main stream technologies

namely java, .Net, Php, etc. is a significant development in the recent days. We are
successful in implementing the RIA using Flex.