Introduction

This article talks about how Laszlo's Serverless deployment can help .NET applications leverage the power of RIAs - Rich Internet Applications as they exist today. The article presents solutions on doing so and also refers to their shortcomings.

Laszlo has recently released a version of their product that provides the ability to deploy Laszlo applications without the presentation server. This effectively means that though building applications with Laszlo requires its server, which is tightly coupled with J2EE environment, it is not needed to be installed on a deployment server unless certain specific runtime features are required. There are shortcomings with this approach that are discussed in here, but it solves the problem of having a RIA for companies that are already using .NET for their existing applications.

Problem

The problems facing the .NET based applications that want to leverage the power of RIA today are:

  • The "presentation-server-required" nature of the deployment. The RIA providers require additional Java deployment for these presentation servers.

  • Additional overhead of security for these presentation servers. The complex/high-scale infrastructures will be wary of going for an extra layer/tier.
Solution

Laszlo Systems has just released their version 3.0 beta that decouples the presentation server during deployments. Laszlo uses Flash Player as the client. Earlier Laszlo versions required that Laszlo Presentation Server (LPS) should run during deployment to proxy request/response through it. LPS tried to do what the client could not - essentially, features that could not be available in the client. LPS would proxy every request/response and interpret responses before compiling then into binaries (swf files) that could be understood by the client.





The client, when using Laszlo version 3, is the Flash 6 player. Flash 6 player is now ubiquitous in internet explorers, more so after being bundled with XP SP2. Laszlo now uses the server that it ships to do the regular edit-compile-debug cycle while the actual deployment is done independent of LPS - without requests to servers being proxied by LPS. This saves us from the situations where companies do not want additional (Java) application servers to deal with since LPS is a Java application that executes in a J2EE servlet container.

The implementation will now be a two-step process:

Compilation



Deployment without LPS



Sample Implementation

In Laszlo, applications are written using LZX - a language similar in spirit to XUL, or the XML UI Language. The dynamic parts in the LZX can come from "datasets". The datasets are basically xml files that parsed in the LZX application using XPath. These xmls that datasets refer to, can be generated during run-time. Laszlo says that any server technology that is capable of writing an xml can be used for this - a jsp, asp, cgi-bin etc. The dataset as it looks in LZX

<dataset name="dset" src=http://users.aspx />


The source for the dataset could be an aspx page. This aspx should write out the xml, which would be the dataset for the LZX application, into the output stream of the http response. The aspx page could in turn get the data using the existing .NET architecture in place. Effectively, the aspx page would act as an "eventHandler" to get the data to the LZX application. The Laszlo application uses the standard XPath technology to parse the data thus got from aspx page. Laszlo uses UI components like "grid" and "view" to render the xml data. These components utilize "datapath" as an attribute to point to a node with multiple instances - thus the component is automatically replicated to display the value of each node.

<view datapath="dset:/phonebook/employee" layout="axis: x" ... >

<grid datapath="contactsData:/*" sizetoheader="false" ... >



Note: This means that the work involved in integrating Laszlo RIA with the existing .NET code would be to the extent of the Presentation Layer (code-behind classes) of the existing .NET application. The Business Logic and the rest of the Layers would not be affected in any way.

Actual Deployment using Laszlo v3 on IIS

Compilation of LZX

Once the LZX application is written using the approach shown above, it is ready of deployment using "precompilation". The LZX application would refer to all the dynamic parts using aspx pages. The application can be pre-compiled by using the following approaches:
  • Precompiling the application by invoking the compiler from the command line . The Laszlo v3 download provides the precompiler (lzc.exe) that can be found at $LPS_HOME/bin . This can be invoked with the following command: lzc filename.lzx . This generated filename.swf that can be placed on IIS. This approach sometimes gives "out of memory" error which could be because of the beta release of Laszlo. A better way would be to following the other approach, as mentioned below.

  • Compiling the application using LPS and specifying unproxied deployment . This is done by using the "lzproxied" query parameter to the lzx request type in the URL, for example http://localhost:8080/lps-3.0b2/my-apps/sample.lzx&lzpproxied=false . This approach also generated the swf file at the same location as the lzx file.


Using FlashControl to embed the generated swf file in ASPX page.

The Visual .NET studio can be used to write the ASPX page. There are FlashMovieControls available on the internet that can be used to embed swf files in aspx page.

Deployment on IIS

The generated swf file and the aspx page that it refers to for the dataset can be deployed as part of a web project in IIS. The aspx page that has the swf embedded can then be viewed in a browser window.

The swf file is embedded in an aspx page for it to be part of the web project - for generic purposes of session and timeout tracking. Otherwise, the swf file, as placed in IIS, can be directly viewed in the browser.

Summary


Laszlo v3 can be used to generate binaries (swf files) from LZX code independently, thereby avoiding the use of Laszlo Presentation Server. The binaries can directly be used with .NET code on IIS. The SWF in the browser will communicate with XML and media sources directly, with no intervening presentation (proxy) server. Avoiding the LPS removes the related overheads that were discussed earlier in this article. As a result, it will improve the performance, reduce security risks and improve scalability of the deployment of RIAs in .NET environment.

References


  • http://www.openlaszlo.org/download/
  • http://www.openlaszlo.org/download/notes/b2.html
  • http://www.davidtemkin.com/mtarchive/000007.html
  • http://www.laszlosystems.com