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.
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.
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.
Developer tools (20.0%)
Client interface (10.0%)
Overall Score (100%)
|Laszlo Presentation Server 1.0, Enterprise Edition||5.0||8.0||5.0||5.0||5.0||9.0||6.0|
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Now that we're down to the wire, many upgraders report that the installer hangs. If this happens to...
Based on a technique created by a German blogger, here's how to stop wasting hours checking for Windows...
The Swift community offers a host of tools to help power Apple’s soaring programming language
It's all us techies' fault in creating robots and machine intelligence that can do a better job than...
Microsoft-Qualcomm deal puts Windows 10 and Win32 apps on ARM-based PCs, using several techniques