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?

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Laszlo Presentation Server 1.0, Enterprise Edition Laszlo Systems, laszlosystems.com/ Good  5.8 criteria score weight Integration 5 25% Developer tools 5 20% Administration 5 15% Client interface 8 10% Scalability 6 10% Setup 9 10% Value 5 10% Cost: Pricing typically starts at $10,000 per CPU. Enterprise edition can be tailored to suit individual customer needs. Platforms: Server: J2EE platform on Windows, Solaris, Linux, Mac OS X; Client: any platform supporting Macromedia Flash Bottom Line: Adept at building strong visual interfaces, thanks to Macromedia Flash support, Laszlo Presentation Server 1.0 has limited server-side enteprise integration and a poor development environment. As a result, this solution is better suited to building vanity Web site enhancements than mission-critical applications. About our Reviews and Scoring Methodology

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.

Upon receiving a client request, Laszlo’s compiler combines the LZX tags, scripts, media files, and Flash resources into executable bytecode, compresses it, and streams the Flash executable.

The initial client-side request pulls the fat-client application from the Laszlo server. The client can then make fresh calls for new data and update the interface accordingly.

Developers versed in XML and JavaScript will not have difficulty learning the Laszlo language. But with no internal editor or development environment, the product requires developers to resort to a third-party XML-aware editor.

The addition of a visual IDE would do wonders to enhance the efficiency of this product. Also missing is a good set of drop-and-go objects or applications to jumpstart development. And although JavaScript syntax is used for scripting, Laszlo doesn’t include exception handling, lacks several object types, and offers only limited Unicode support. So migrating existing code may require a good deal of tweaking.

The server can transcode a variety of static media types for real-time delivery, including JPEG, GIF, PNG, MP3 audio, and TrueType fonts. But it cannot yet handle PDFs or video content such as QuickTime or Windows AVI files.

LPS would also benefit from a richer set of tools for connecting the server to databases, files, and Web services on the back end.

The solution’s data-binding mechanisms are limited to XML, lacking support for JDBC and direct JMS integration, for example. Additional scripting and code maintenance, such as through JSP, is required.

LPS could also provide more help to system managers charged with maintaining and tuning production applications. Run-time reporting facilities are lackluster, offering little more than static log dumps, and server monitoring and diagnostic tools are absent.

I found it easy to compile and deploy my smaller sample applications, whereas managing and maintaining larger LZX applications proved taxing.

Laszlo’s dependence upon the availability of the free, third-party, nonstandardized Flash client, rather than a Laszlo-supported rendering engine, may also be of concern to the wary IT manager.

Dramatic changes in Flash or Macromedia’s revenue model could quickly alter the true cost and feasibility of Laszlo’s solution. The reliance on Flash should spur IT execs to consider carefully before committing to LPS for all but the lightest of applications.

To this reviewer, LPS 1.0 felt sluggish and performed like a first attempt, ultimately falling short of products from RIA trailblazers such as Altio.

Although LPS creates a nice programmatic alternative to Flash development and extensibility, it lacks the development, integration, and management capabilities required for heavyweight deployment. With Version 1.0, Laszlo has left itself room to grow.