WEB 2.0 User Interface technology detailed

Suppose you need to create a new application that is suitable for the WEB 2.0 environment. Some users like the html-based user interface very much, while other users want each application they use to behave like Excel desktop applications. Your boss requires an efficient user experience, but the CIO does not allow you to develop anything that needs to be manually deployed by the user. You know HTML does not achieve this goal, but how do you meet the requirements? This article discusses a series of WEB 2.0 user interface technologies that allow you to build applications that have a better user experience than browsers.

In terms of user interface, today's enterprise application developers are under double pressure from the user and the Operations department. On the one hand, the business unit that represents the user wants the application to have a rich user interface to maximize user productivity. They want all applications to behave like Microsoft Excel or other client applications. You want your application to provide instant response. In addition, if you have multiple views of the same data (for example, a table view and a graphical view), you also want to make changes in one of the views so that other views can immediately reflect this change.

On the other hand, IT operations prefer a purely server-based delivery model. Although they know that the HTML user experience is not as robust as the user interface based on the native operating system (OS), they believe that the cost of installing, configuring, and managing client code is too high to improve the user experience.

Many in the IT organization have experienced the client/server deployment model of the the 1990s and are unwilling to repeat that experience. In fact, many Java 2 Enterprise Edition (Java EE) applications may not be built if there are client components, because costs are too high for the business goals of the application. The server-delivered deployment model provides IT organizations with low-cost and efficient deployments, a dream for IT organizations in the 90 's. Most organizations are aware of the economic advantages of Java EE applications deployed by the server, and therefore do not consider deploying code that must be installed on each client, unless it is a last resort.

So what should enterprise developers do? Users do not want to reduce productivity by a few seconds of server response time, and the IT department disagrees with the old approach of deploying and managing code on the client. How can these seemingly conflicting needs be met to the satisfaction of both parties?

Fortunately, the existing technology allows you to provide a better user experience than the browser, without having to manually install code on the client. Applications built with these technologies are sometimes referred to as WEB 2.0 applications. In Tim O ' Reilly's article "What is Web 2.0?" Design Patterns and Business Models for the Next Generation of Software ", he noted:

We are entering an era of unprecedented user interface innovation, and Web developers are finally able to build Web applications that are as rich as local PC applications.

WEB 2.0 applications also offer the benefits of two environments: a low-cost and efficient server-based deployment model, and a user experience that is almost comparable to client applications.

For today's Java EE applications to provide a rich user experience, there are several technologies to choose from:

· Flex and OpenLaszlo

· Ibm®workplace™managed Client and IBM lotus®expeditor

· Faces Client Components

· Ajax

· Html

Flex and OpenLaszlo

Flex and OpenLaszlo are very similar declarative ways to create a better user experience for Java EE applications than for browsers. Flex is provided by Adobe/macromedia, and OpenLaszlo is open source software that was originally created by Laszlo Systems INC. In both environments, a unique xml-based syntax is used to lay out and create a user interface.

For example, to use a button in Flex, you could write the following code with MXML (multimedia XML):

For OpenLaszlo, you can write the following code with LZX (LasZlo XML):

To allow different UI elements to interact and communicate with the server, script can be written in ActionScript (Flex) or JavaScript (OpenLaszlo).

Although there are many similarities between the two technologies, the key difference is the run-time infrastructure they need. For clients that need to exchange data with the server, Flex needs a flex data Services Server that communicates with the client running in the Flash Player plug-in. In essence, this server provides intermediaries for all communication and data exchange between the client and the server components of the application.

The latest version of OpenLaszlo has done some run-time improvements that make it more appealing to developers. One improvement is that version 3 introduces a SOLO development model that makes Laszlo presentation Server no longer needed in some deployment configurations. Another major improvement is the client's run-time environment. The latest version (Openlazlo 4) is in beta testing, enabling Laszlo based applications to run without Adobe/macromedia Flash Player plug-ins. Many companies do not want to be limited to some proprietary plug-ins (such as Flash Player), and they will welcome this improvement.

How can you tell which product is more suitable for your organization? The main advantage of flex is that you can get full product support from Adobe/macromedia, but pay for the license for Flex Data Services Server. For some companies, it is worthwhile to pay a licence fee in exchange for a fully supported product. Adobe Flex 2 applications also require Flash Player plug-in V9. Although Flex can create a rich user experience, some companies are unwilling to accept cost and plug-in restrictions.

OpenLaszlo Technology was originally released as a commercial product, but in 2004 Laszlo Systems opened the source code for the technology, using the Common public License (V1.0) licensing method. Laszlo Systems offers support subscriptions, and because it is an open source project, you can choose to support it with free resources. For OpenLaszlo, costs are not a big problem, but some organizations ' corporate policies do not allow open source software, so it may not be possible to use OpenLaszlo.