I am a Web application developer. That can mean a number of things these days, but in my case, it means I write code on both the client and the server to make a complete "application." For many of us, the client-side code is JSP - JavaServer Pages. Perhaps, like me, you find JSP to be awkward with its mixture of languages and styles. I also find developing large applications to be ever more complex as I add packages such as Struts and Tiles, which are intended to make using JSP easier.

A few years ago I started to learn and use Macromedia Flash because I read it had the ability to send and receive information via HTTP. I saw Flash as a way to avoid using JSP to write Web applications. This turned out to be a good idea. However, it quickly became obvious that using Flash was not going to enable the other members of my group to easily join me in creating a new generation of applications. This is because Flash has a steep learning curve. While most business-like applications do not require animation, you still have to learn the Flash IDE and become familiar with how application development is done with Flash. The Flash MX release included a set of predefined UI components (such as combo-boxes, lists, and buttons) to speed application development. Even with the newest version, Flash MX 2004, there is still a learning curve issue. For instance, to build a respectable application, you have to understand how Flash movies are produced with their layers of movie clips and timelines.

For a while I resigned myself to the fact that my team members might have to become Flash developers. I met some resistance to this idea, but there didn't seem to be any alternatives. I had been reading about Macromedia's new product, Flex, and for a while considered joining the beta effort, but I was too busy writing Flash applications to take part. Once I got a trial copy of the first release, Flex changed how I view Web application development.

What Is Flex?
Macromedia Flex is a new product designed for the development of enterprise-level applications that are delivered to end users via Web browsers. Flex has a much softer learning curve than Flash and comes chock-full of user-interface components. You develop your Flex applications in much the same way you develop JSP or HTML applications. Flex solves the problems I had using Flash while still delivering on its promise.

If you are familiar with JSP technology, Flex will not seem too dissimilar. Just as with JSP, server-side technologies are employed to deliver information to the end user; raw "source" files exist on a server and are converted on-the-fly by server-side components into a form presentable by a browser. But the similarities between Flex and previous technologies end there.

Macromedia Flex delivers Macromedia Flash applications, not HTML, to the end-user's browser. The Flash player, a plug-in to the Web browser, renders the Flash application.

Figure 1 shows the Flex process in detail. Notice how similar it is to how JSP operates.

1. The developer creates Flex source files. These are text files that contain a flavor of XML known as MXML. No specialized editors or environments are required.
2. The end user enters the URL to this MXML document into their browser's address bar.
3. The server, detecting the MXML extension, looks for a corresponding SWF file. This is the Flash application.

   Tip: If the SWF file does not exist, or if the MXML file is more recent than the SWF file, the Flex engine recompiles the MXML into a new SWF file.

4. The SWF file is packaged within a simple HTML wrapper (so the browser can display it) and sent back to the user's browser.

The browser loads the Flash player plug-in and displays the Flash application.

As the user interacts with the Flash application, calls are made from the Flash application to remote objects - via either Web services, XML documents, or JavaBeans, residing on servers.

Flex produces "smart client" code. Thin clients, such as Web browsers, place most of the processing duties on the server. Data validation (which is possible with JavaScript on the client), calculations, localization, and such are best done at the client's computer and make the most of the processing power there. With Flex, the client can sort their data, have it formatted to their liking, print reports, and interact in new and meaningful ways that were not possible with previous Web technologies.

Examples

• Rather than simply list data values, draw a graph. Allow the user to interact with the graph by providing sliders that control the bounds of the data.
• Allow the user to click on column headings to sort the data.
• Include short movie clips of experts explaining how tools work or connect to media servers and chat live (video and audio) with the expert.
• Use animated controls, such as dials, gauges, and meters, to provide visual feedback of real-time events (e.g., price-ticks).

The JSP Way
One of the issues I have with JSP is that it is possible to have a single file that contains a mixture of languages and programming styles. For example:

• JSP tags: Refer to beans that execute on the server, be they plain JavaBeans or Enterprise JavaBeans. Some of these tags may be specially written for a project and are designed to mask the underlying Java code from a Web page designer.
• Java code: Translated into a servlet that executes on the server, producing HTML to be rendered by the client's browser.
• HTML: Rendered by the client's browser.
• JavaScript: Code executed by the client's browser (typically to do simple data validation or modify the HTML controls on the page).
• VBScript: Code executed by the client's browser (in a similar way to how JavaScript is used).

Tip: JSPs must be tested on a variety of browsers to make sure any JavaScript or VBScript, as well as HTML, is compatible. Developers often have to place a lot of conditional code within the files to account for the differences.

It is hard to have a clean separation of client-side (or user interface) code from server-side (or business) code. For example, it is possible with JSP to write a JavaBean that produces HTML in the course of executing business logic.

A lot of effort has been put into making JSP development more palatable. Business logic developers can create tag libraries for Web developers to use when coding JSP files. This supposedly helps separate the user interface code from the business logic code.

One of the more common packages developed for this purpose is Struts from the Apache Software Foundation. Struts is an attempt to apply some software methodologies to the complexity of JSP development. The business logic developers create a series of forms and actions that process input from the JSPs and forward the results to other JSPs; this is put together with configuration files written in XML.

In addition, for user interface code reuse, there is the Tiles package, also from Apache. This allows a Web page to be broken into rectangular sections ("tiles") described by configuration files and implemented with JSPs.

Nonetheless, with all of this effort you can create pretzel-logic Web code that can be difficult for project newcomers to untangle.

The Flex Way
In contrast, all of the code within a Flex MXML file is destined for the client. It is not possible to write code, such as opening database connections and processing result sets that would wind up running on the server.

There are several benefits to this:

• There is a clear separation of client-side and server-side code as in a Model-View-Controller architecture. The user interface developer concentrates on presentation and interaction with the end user.
• Server-side components of the application are cleanly written without the possibility of doing anything that involves the client. With Flex, the separation is more dramatic - your business logic does nothing else but the business operations.
• Flex comes with a large assortment of helper classes to preserve this separation. For example, in a JSP application, code may format dates and times for presentation to the user. In Flex, the data arrives in the Flash application as raw as possible and is formatted at the client - with the ability to localize the display (for numbers and dates).

Developing for Flex cleanly divides the tasks of the team: business logic developers create business code; user interface developers create the user's experience. The two sides come together to agree on the interfaces and data types, but both are free to implement their parts the best way they know how.

Sample Application
This is a small example to compare an application using both JSP and Flex. Both applications use the same JavaBeans on the server.

JSP Example
In Listing 1, notice how the Java (in red) is intermixed with the HTML. The flow of HTML is broken by Java, making it hard to read even in this simple example. As programs grow more complex, some of the Java code would be replaced by specially created tags, but you can see how easily this can become corrupted by sloppy coding habits.

To make this program work, the "Get Employee List" button (see Figure 2) submits the form data (the combo-box selection) by invoking itself. I find this self-referencing logic to be confusing, especially on large projects.

Flex Example
The Flex code isn't necessarily smaller than the JSP, but you can see how the user interface is laid out within the Application container. The RemoteObject declaration connects the application to the server-side JavaBeans. When the "Get Employee List" button is clicked, the JavaBean's method is invoked. The result is dynamically bound to the DataGrid using the dataProvider attribute. There is no obvious procedural call here; the implication is that all remote method invocations are asynchronous and the results bound to their destinations when they arrive.

If you have ever written a JSP to produce a table that the end user can sort, you know how complex this can be. HTML provides no way to sort a table, nor any way to indicate that a table has been sorted.

The power of Flex lies in its ability to create applications that can run independent of the server (see Figure 3). For instance, to sort the data in a table the user just clicks on a column heading. The Flex DataGrid is more powerful than an HTML table: it has the capacity to sort its data without needing to contact the server.

Flex makes it easier for developers to add features to applications, such as sorting a table; with JSP, features like this may take days to complete.

Comparison Chart
Table I compares JSP and Flex using common development issues.

Not a Panacea
As much as I like Flex, there are times when using JSP is appropriate. I've come to think of Flex as an application builder and JSP as a Web site builder. For example, the Flash Player is not good at rendering lots of HTML text as it must draw each of the characters as vector graphics. Macromedia has included in the Flex package a JSP tag library that lets you include your Flex application on a Web page. Ironically, you can use the Flex tag library to generate the MXML on-the-fly, just as HTML would!

Keep in mind, then, that Flex and JSP can happily coexist.

Conclusion
While JSPs will continue to be used, the impact that applications developed with Flex can have is greater. Not only does the user have a better and more productive experience, so does the application developer. By allowing server-side application developers to create the business logic, it frees them from being client-side developers and makes their jobs easier and more disciplined. Likewise, user-interface developers can concentrate on bringing a more meaningful and richer application to the end user.

Consider also that JSPs were once the "new technology" and were, in fact, created to fill the need of bringing dynamic content to the Web. I feel Flex is the next step in the evolution path of Web-based applications. Flex extends this path by bringing richer applications to the Web in a way that is easy to develop and maintain.

The return on investment with Flex is higher than with JSP (and Java applets) because more time is spent developing useful applications than is spent resolving compatibility issues.

Resources
For examples of Flex applications, visit my Web site at www.keaura.com/flex. Here are some other references for further reading.

Macromedia Flex Product Description: http://macromedia.com/software/flex

Macromedia Flash Player Distribution: www.macromedia.com/software/player_census/flashplayer/

Best practices for building Flex applications: http://macromedia.com/devnet/flex/best_practices.html

Flex Performance Brief: A Comparison of Flex and JavaServer Pages Applications. May 2004. Click Here

• Figure 1
• Figure 2
• Figure 3
• Source Code