Coach Wei

Subscribe to Coach Wei: eMailAlertsEmail Alerts
Get Coach Wei via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: RIA Developer's Journal, Web 2.0 Magazine, Apache Web Server Journal, SOA & WOA Magazine, Java Developer Magazine, AJAX World RIA Conference

RIA & Ajax: Article

AJAX, Java, Flash, and .NET

Enterprise Rich Internet Applications (RIAs) are the next evolution of business application development

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 developers put the logic either on the client side or server side. They can also 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.

The flexibility in partitioning application logic brings significant benefits. Some applications are best suited to having all their logic centralized on the server side while other applications require that the logic run on a local desktop. Traditionally, developers have to 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 that 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 a direct impact on and creates significant differences in application logic development. Choosing a scripting-based solution requires that the logic be written as scripts, which limits the amount and scope of logic that can be developed and maintained cost-effectively. An OOP-based RIA solution gives maximum flexibility to logic development and maintenance, but requires a higher-level skill set than scripting.

There's a code sample of logic development using Laszlo in Listing 1.

By contrast, OOP-based approaches use an object-oriented true programming language for the application logic development and typically enforce separation between the logic and the UI markup. For example, Nexaweb uses standard Java for the application logic called mco. Nexaweb also enforces a clear separation between the UI and logic, preventing the mixing of the UI with the logic in the same document for better application maintenance. (Figure 4) Nexaweb separates the UI from the application logic:

<mco:declarations xmlns:mco="http://nexaweb.com/mco">
   <mco:mco id="myMco" src="com.nexaweb.test.MyTestMco"/>

   <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()"/>

Nexaweb enables application logic to be written using standard Java:

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
     ClientEvent clientEvent = clientSession.getEventHandler()

     //additional business logic here...

     System.out.println("Hello, you clicked the button!");


Choosing the Right RIA Solution
Given the various RIA approaches and solutions available, selecting an RIA solution can be confusing. There's no universal "right" RIA solution. It depends on the application's requirements.

Enterprise Application Requirements
For the purposes of this discussion, it's useful to categorize the full spectrum of software applications that enterprise IT departments build, deploy, and maintain across two related dimensions: business criticality and application complexity.

  • Business criticality concerns the degree to which an application is critical to running the business or meeting business objectives. Disrupting access to a business-critical application, or even unacceptable performance, has an immediate and significantly negative impact on the business. Other applications are less critical to operations; if there's a problem, the user can wait a few minutes to perform a task without major consequences.
  • Application complexity refers to its feature richness and sophistication from a user's perspective. Some enterprise applications have thousands of screens, with usage metaphors characterized by multi-path, non-linear state transitions. (In other words, you might rarely use them exactly the same way twice.) Other applications have rather linear state transitions and fixed usage paths - using them is comparatively routine.
Classified as either "high" or "low" across both these dimensions, an application falls into one of four categories as Figure 5 illustrates.

The applications in quadrant A are business-critical and less complex. Users rely on these "helper" applications to do simple but highly important business operations (e.g., an employee portal, partner extranet, or e-commerce Web site). These applications are used less frequently and/or for shorter durations ("casual usage level") than more complex applications. The workflow is typically linear; users do the same tasks in roughly the same order each time they interact with the application. From a development perspective, the client-side development team typically comprises fewer developers than a more complex application would require.

A classic example of a high-criticality/low-complexity application is an airline's online ticketing application. Most users interact with it only occasionally, for a short duration, and in a step-by-step fashion.

Applications in quadrant B are both business-critical and complex. These applications are used for many hours each day to do complex non-linear tasks that are central to business operations. The performance, availability, and scalability of these applications are extremely important. From a development perspective, maintenance is important and may cost more than the initial development. The development team comprises many developers who require close collaboration.

Examples of high-criticality/high-complexity applications include the trading applications used by portfolio managers, call center applications and banking applications accessed by tellers.

The applications in quadrant C are complex but less business-critical. As a result, they are managed much more cost-consciously. High-complexity/low-criticality applications include some legacy applications in which companies wish to minimize further investments, as well as some corporate R&D projects.

The applications in quadrant D are less complex and less business-critical. They are typically written by a small development team of one or two people. Developers' individual experimentation would fall into this category.

Different RIA Technology for Different Applications
Seen against the backdrop of business criticality and UI complexity, different RIA technologies are appropriate for implementing or re-architecting the various classes of enterprise applications.

As Figure 6 illustrates, the applications in quadrants B and C are much better suited to OOP-based RIA development approaches like Java and .NET, because these technologies offer better maintainability and support for team development. Scripting-based approaches are more suited for applications that fall into quadrants A and D where programming tasks are simpler, development teams are smaller, and maintainability is a less mission-critical concern.

Table 3 provides details on how different RIA approaches fit with different enterprise requirements for application profiles and developer skill sets.

The diverse nature of enterprise application requirements, combined with the clear strengths and weaknesses of different RIA technologies, lead to the inevitable conclusion that "one size does not fit all."

No single RIA development approach is ideal for all enterprise environments. Some requirements are better met by scripting-based RIA approaches, while others require OOP. And in these two categories, a particular application need will be better served by AJAX versus Flash, or by Java versus .NET. In short, all four of these RIA technologies are likely to co-exist in many enterprise environments for the near future.

Interesting New Developments
All RIA solutions are fundamentally constrained by their underlying technology - AJAX, Flash, Java, or .NET. If a developer picks Flex to develop his RIA, he has to live with the pros as well as cons of Flash. Likewise, if a developer picks an AJAX toolkit to develop his RIA, she must live with the various challenges associated with DHTML and JavaScript. As we mentioned earlier, among the four technologies, each has its strengths and weaknesses. One of the major goals of enterprise IT departments is "common flexibility" - providing standardization and simplification across different business applications and initiatives, while enabling flexibility for innovation within business units. Different business units have different programmer skills and therefore need different types of applications. As a result, dictating the use of one RIA technology across a large organization is unlikely to work well.

There's been a very interesting development in the RIA marketplace recently: cross-technology RIA solutions. Both Laszlo Systems and Nexaweb recently announced that their products are supporting more than one technology so that the same application can be delivered and rendered on different technology platforms. Laszlo supports both Flash and AJAX (DHTML). Nexaweb supports Java and AJAX. With this development, developers don't have to fight the "religious war" of JavaScript versus Java, Java versus .NET, or .NET versus Flash. Such development accommodates not only different developer skill sets, but also opens the door to combining the benefits of scripting-based approaches with those of OOP-based approaches, delivering optimal results.

Figure 7 shows cross-technology RIA solution architecture.

Listing 2 is a sample application written using a cross-technology RIA solution. It is an RSS reader that would read RSS feeds from Yahoo and display all the feeds in a table. The code is Listing 2 and the UI screen display is shown in Figure 8.

More Stories By Coach Wei

Coach Wei is founder and CEO of Yottaa, a web performance optimization company. He is also founder and Chairman of Nexaweb, an enterprise application modernization software company. Coding, running, magic, robot, big data, speed...are among his favorite list of things (not necessarily in that order. His coding capability is really at PowerPoint level right now). Caffeine, doing something entrepreneurial and getting out of sleeping are three reasons that he gets up in the morning and gets really excited.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Jeff 06/14/06 01:52:44 PM EDT

Coach, please look more into the Flash technology from Adobe in regard to Flex and ColdFusion, Java, .Net backend. It is 100% OOP. Please do a bit more research before you write something in regard to a technology such as ActionScript/Flash and it's capabilties. IMHO Flex 2.0 will leave AJAX, a RWA (Rich Web Application) solution behind due to its abilities to run outside the browser as well as in, a characteristic of a true RIA. Good luck to you.

David Bolsover 06/14/06 05:58:19 AM EDT

A facinating article; I have worked with both web and desktop Java applications I'm presently working with Swing clients and taking advantage of some of the new work coming out of the SwingLabs projects (JDNC, Databinding etc.) - but this article has given me considerable pause for thought.

It looks like we are in for some interesting times ahead - and making the right choice of technology today will bring significant rewards for the future.

One thing is certain if Java is to maintain it's share of the marketplace, it must continue to grow and work such at that underway on JSR 295: Beans Binding and JSR 227: A Standard Data Binding & Data Access Facility for J2EE will become increasingly important.

Mark 06/09/06 01:23:25 AM EDT

I'm sure that you are going to receive hundreds of emails from people all letting you know which framework that you missed. Ajaxian does a framework review periodically and I think that they are well over 100 different frameworks...

I do think that you neglected to mention some of the next generation frameworks that are emerging to address the hodgepodge of technologies that you have to manage and integrate in the enterprise RIA space.

Probably one of the latest example is going to be the Google Web Toolkit that was recently announced. Basically this is a framework for AJAX based RIA's where everything is developed in Java (Servlets) on the server which emit javascript/DHTML/AJAX to the browser.

For internal development, the GWT is an excellent option, but if you are looking for an open source solution, you should check out Echo2. (http://www.nextapp.com/platform/echo2/echo/). Essentially the same thing, interfaces can be built on the server in Java and rendered into the browser with AJAX, etc. I believe the UI can be tweeked with CSS as well. Check out the demos.

Finally, for a commercial framework, the Tibco product from IBM is a very powerful framework. UI development is done using an AJAX IDE, written using the framework of course. There are several javascript components that speak SOAP so you can quickly participate in an SOA. Very heavy on the browser because significant heavy lifting is done using javascript in the browser.

Unfortunately I'm unsure of any .Net frameworks... I believe that Atlas is supposed to be the GWT / Echo2 alternative for .Net AJAX developement...

Thanks for a great article!

AJAXWorld News Desk 06/08/06 03:52:33 PM EDT

Enterprise Rich Internet Applications (RIAs) are the next evolution of business application development. There are four different approaches to RIA development - AJAX, Java, Flash, and .NET - and many different RIA solutions available today. This article answers the following questions: What are enterprise RIAs? Which approach should you use? Which solutions are appropriate for you? And how are RIAs being adopted today?