Laszlo builds flashy Web apps

A Web browser is fine for viewing static Web pages, but for interacting with back-end applications, it leaves a lot to be desired. Constant browser refreshes and the inability to work offline are inconvenient for end-users, and handling all data processing and presentation at the back end imposes a huge burden on servers and networks. Isn’t there a better way?

Vendors of RIA (rich Internet application) platforms, including Altio, Curl, Droplets, and Versalent, claim to have one. RIA platforms place the burden of data processing and presentation on the client, by employing a fat client that consists of a database and interface-rendering engine, and a middleware server that shuffles data between the client and back-end applications in response to user queries.

Among RIA’s benefits is an end-user experience more akin to a desktop application than browsing HTML pages. Another benefit is richer, highly distributed application availability without sacrificing a consolidated code base on the back end. RIA solutions also reduce server load and often provide additional bells and whistles — such as data compression streaming between client and server — to enhance performance in low bandwidth situations.

Joining the growing list of RIA solution vendors is Laszlo Systems, with its rollout of LPS (Laszlo Presentation Server) 1.0, a Java-based server application that capitalizes on the ubiquity of Macromedia Flash clients. LPS 1.0 pulls live data from back-end sources, creates on-the-fly Flash executables, and streams them to the client desktop.

With a reported market penetration topping 90 percent of desktop users, Flash makes for a readily available client component. Laszlo’s proprietary markup language will present a modest learning curve for some developers, but LPS 1.0 hides the underlying intricacies of building data-driven Flash interfaces.

I found the Laszlo Presentation Server capable of producing a very “flashy” user experience. However, I also confronted shortcomings in its development environment, data-binding facilities, and integration of Web services standards and security. When it comes to reaching into a variety of back-end data sources, LPS falls short of offerings from competitors such as Altio and Curl.

Laszlo’s built-in push mechanism, its ability to dynamically adapt look-and-feel according to device and processor type, and the sizeable installed base of Macromedia’s Flash client mustn’t be dismissed. But on balance, at this time LPS 1.0 is better suited to creating boutique, marketing value-adds to Web sites rather than delivering mission-critical enterprise applications.

Connecting With Flash

As with other RIA solutions, developers use LPS to build client-side applications, including interface elements and data connectors, that communicate information requests back to the proxy server for fulfillment. LPS enables developers to integrate the fluidity of the Flash UI while hiding the complexity of developing and scripting data-rich Macromedia interfaces.

As a result, LPS applications can be built without knowledge of Flash or Macromedia’s ActionScript Remoting APIs.

Installing to any servlet 2.2 container, such as Jakarta Tomcat, BEA WebLogic, or IBM WebSphere, the LPS system uses a Java infrastructure to compile Laszlo’s proprietary LZX files and stream the resulting SWF Flash application. The LZX language uses JavaScript and XML tags that supply an object-oriented foundation class for event management, XML data binding, and interface layout.