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
So what is the problem with the current solutions? Maybe nothing is wrong if the application behaves correctly and allows the user to be productive. 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 problems 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 Macromedia Flex.
Rich Internet Applications can help address the problems 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. This article will now focus on one RIA solution, Macromedia Flex, and will discuss integration concerns.
Macromedia Flex
Macromedia 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 Macromedia 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 2.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 Macromedia. 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.
Introducing an RIA Framework to Your Existing Architecture
Now that you have an understanding of some RIA concepts, let's look at how to introduce an RIA into your existing architecture. This will include a discussion about how an RIA should behave in a layered application with an emphasis on decoupling. Furthermore, this discussion will highlight some potential pitfalls when developing with Flex in combination with some popular open source frameworks. These examples should help identify potential concerns when introducing an RIA within your architecture.
Let's begin by identifying a layered architecture. An example of this architecture might include the following layers: presentation layer, business delegate layer, business integration/service layer, and persistence layer. Here is a potential implementation for these respective layers:
Flex + Business Delegates + Spring Framework + Hibernate The remainder of this article will concentrate on integration with each of these layers.
What About My 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. Do you really need to maintain a presentation layer that consists of two MVC frameworks?
Let's look at a practical example of what happens when a Flex client makes a request through a Struts component to a Java service on the application server. A request made from the Flex client is sent to the Struts presentation framework before being received by higher layers in the application. Figure 1 shows an example of what not to do:
Figure 1. How not to integrate Flex and Struts with other Java components.
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. Figure 2 shows a better solution when using Flex and Struts:
Figure 2. Introducing Flex and Struts in parallel with other Java components.
Figure 2 suggests how to have separate Struts components and Flex components coexist. This satisfies a need when the application requires parallel RIA components and lighter-weight Struts-like components.
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.
Struts will not be the only thing you have to think about when using an RIA. It will take a while to become familiar with this type of technology. Following this learning curve, the biggest issue is integration of the Java server-side components. The bottom line is not to fight against the Rich Internet Application concepts.
(by onjava.com)
