RIA Solutions and The Converging RIA Programming Model (Article 3)
This is the third post of Enterprise Rich Internet Application Series.
RIA Solutions Today
There are many RIA solutions available today. Each of them fits into one of the approaches mentioned above. Some of the solutions come with tooling that can simplify development and maintenance. The following table shows a list of solutions available today:
|
|
Runtime Solutions |
Tooling |
|
Java |
· Nexaweb · Thinlet |
· Nexaweb Studio |
|
.NET |
· Visual Studio |
|
|
AJAX |
· Open source: o Dojo, Apache Kabuki, Rico, DWR… · Close source: |
Nexaweb Studio |
|
Flash |
· Laszlo |
· Adobe Flex Builder |
General RIA Programming Model
Although there are many different RIA solutions based on different underlying technology platforms, the general RIA programming model is actually converging into a single common model.
Declarative UI Development
The general RIA programming model is centered on the usage of an XML-based UI markup language to create a rich user interface. The XML-based UI markup provides a much higher level of abstraction than HTML for building rich user interfaces. XML UI frees programmers to focus on the application’s core logic, and explicitly complements the roles of a typical enterprise development team (see reference “XML for Client-side Computing”).
Below we will show examples from a scripting-based approach (Laszlo Systems) as well as an OOP-based approach (Nexaweb). Both solutions are zero-install and thus can be run inside any popular Web browser today without any software download. On the client side, Laszlo requires the presence of a Flash engine (Flash 6 and above) while Nexaweb requires the presence of a JVM (JDK 1.1 and above).
Laszlo is a Flash-based RIA solution. It uses an XML UI markup language called “lzx” to describe UI and uses ActionScript to code application logic. The Laszlo server will automatically compile lzx files into Flash binary format (SWF), deliver the SWF files for rendering inside a Flash engine and thus execute the application.
<canvas height=”450″>
<window x=”10″ y=”10″ width=”300″ height=”200″
title=”my window”
resizable=”true” closeable=”true”>
<button x=”10″ y=”100″>Hello, World</button>
</window>
</canvas>
Example 1: Laszlo Code Example.

Figure 1: UI created by Laszlo code in Example 1.
In comparison, Nexaweb supports Java-based RIA (it support Ajax RIA too). Developers would use an XML-based UI markup to create rich user interface, and build client-side business logic by writing client-side Java objects (called “Managed Client Object”), which are standard Java program objects. Nexaweb Client runtime would dynamically render the XML UI markup to present a rich user interface, and dynamically download client-side Java objects to the client side for execution in a “on demand” fashion.
<xal xmlns=”http://www.openxal.org/xal”>
<window title=”New Window”>
<boxLayout orientation=”vertical” pack=”start” align=”stretch”/>
<tree>
<column/>
<row expanded=”true”>
<cell text=”Tree Item 1″/>
<row>
<cell text=”Sub Tree Item 1″/>
</row>
<row>
<cell text=”Sub Tree Item 2″/>
</row>
</row>
<row expanded=”true”>
<cell text=”Tree Item 2″/>
<row>
<cell text=”Sub Tree Item 3″/>
</row>
</row>
</tree>
<button text=”OK”/>
</window>
</xal>
Example 2: A simple Nexaweb UI that defines a tree and a button, managed by a layout manager.

Figure 2: Example 2 UI Display, created by Nexaweb code.
As shown from the above two examples, though Nexaweb uses Java and Laszlo uses Flash, RIA UI development is conceptually identical between these two different RIA solutions.
Application Logic Development
RIA solutions enable a wide range of options for application logic development. In typical HTML applications, most of the logic has to be on the server side. In typical desktop applications, most of the logic resides on the desktop. RIAs offer significant flexibility so that developers can choose to put logic either on the client side or server side. They also have the ability to adjust the location — ranging from very limited logic on the client side all the way to almost 100% logic on the client side, as shown in Figure 3.

Figure 3: RIA Enables Flexibility in Application Logic Partitioning.
The flexibility in partitioning application logic brings significant benefits. Some applications are best suited to have all logic centralized on the server side while other applications require running logic on a local desktop. Traditionally, developers must make tradeoffs depending on whether they choose to build the application as Web application or a desktop application, and bear with the problems associated with a particular choice. RIAs combine the best of both worlds, enabling developers to meet different application requirements without making costly tradeoffs.
In contrast to UI development, the choice of a particular RIA approach — Java, Ajax, .NET or Flash — has direct impact on, and creates significant differences in, application logic development. Choosing a scripting-based solution requires that logic be written as scripts, which limits the amount and scope of logic to be developed and maintained cost-effectively. An OOP-based RIA solution gives maximum flexibility of logic development and maintenance, but requires a higher level skill set than scripting.
Here is a code sample of logic development using Laszlo (source: Laszlo systems):
<canvas debug=”true” height=”200″ width=”400″>
<script>
<![CDATA[
// Add a find method to Array
Array.prototype.find = function (what ) {
for (i in this ) {
if (this[i] === what) {
return i;
}
}
}
sneaky = {example: ‘sneaky’};
tryit = ['foo', 42, sneaky, Math.PI, false];
Debug.write(“42 is at: ” + tryit.find(42));
Debug.write(“false is at: ” + tryit.find(false));
Debug.write(“‘bar’ is at: ” + tryit.find(‘bar’));
Debug.write(“{example: ‘sneaky’} is at: ” + tryit.find({example: ‘sneaky’}));
Debug.write(“sneaky is at: ” + tryit.find(sneaky));
]]>
</script>
</canvas>
In contrast, OOP-based approaches use an object oriented true programming language for application logic development and typically enforce separation between logic and UI markup. For example, Nexaweb uses standard Java for application logic (called “mco”). Further, Nexaweb enforces a clear separation between UI and logic, preventing mixing UI with logic in the same document for better application maintenance:
<xal>
<mco:declarations xmlns:mco=”http://nexaweb.com/mco”>
<mco:mco id=”myMco” src=”com.nexaweb.test.MyTestMco”/>
</mco:declarations>
<dialog title=”Login Dialog”>
<boxLayout orientation=”vertical” pack=”start” align=”start”/>
<label text=”Username:”/>
<textField height=”25″ text=”enter username here…” width=”200″/>
<label text=”Password:” />
<textField height=”25″ text=”enter password here…” width=”200″/>
<panel height=”25″ width=”100″/>
<button height=”25″ text=”Button” width=”100″ onCommand=”mco://myMco.handleOnCommand()”/>
</dialog>
</xal>
Example 3: Nexaweb Separates UI from Application Logic.

Figure 4: UI from Example 3.
/**
*
*/
package com.nexaweb.test;
import com.nexaweb.client.ClientEvent;
import com.nexaweb.client.ClientSession;
import com.nexaweb.client.mco.AbstractMco;
import com.nexaweb.client.mco.McoContainer;
/**
* @author cwei
*
*/
public class MyTestMco extends AbstractMco {
public void handleOnCommand() {
ClientSession clientSession = McoContainer
.getClientSessionFromMco(this);
ClientEvent clientEvent = clientSession.getEventHandler()
.getClientEvent();
//additional business logic here…
System.out.println(“Hello, you clicked the button!”);
}
}
Example 4: Nexaweb enables application logic to be written using standard Java.

Comments are closed.