Sunday, April 22, 2007

State of Rich Client Development

What is a “Rich Client”?

A “rich client” is an interactive application user interface, which employs dynamic controls that are updated immediately in response to user input. For example, the contents of a list may change in response to selection from another drop-down list, or validation messages are displayed in response to user input. A “rich client” is usually contrasted with a traditional HTML-based client, which can only update the state of the page in response to a form submission or following a hyperlink. The fact that we refer to screens as pages is because the browser was never designed as an application development environment. It was designed to navigate unstructured content.

Introduction

Rich clients are not new. The Client-Server platforms of the 1990's employed rich clients whereby the user interface ran as an application on the user's computer and communicated via a network with a central application or database. The Client-Server architecture suffered because at the time, the (rich) client applications were difficult to deploy and update. With the advent of the (World Wide) Web, application developers traded user interface functionality for ease of deployment.

Expectations do not stay satisfied for long. Users began to expect more functional and dynamic user interfaces, while IT managers expected the deployment capability of the web.

As a consequence, the Rich Client Platform (RCP) has been reborn to utilise the deployment benefits of the web.

The purpose of this paper is to discuss and evaluate the types of rich client platforms available today. As with the early stage of any new technology, there currently exists a range of options and architectures for implementing rich clients.

Rich Client Platform Types

Desktop Application

Desktop applications are the original rich clients and still the best in terms of functionality and responsiveness. They have improved in terms of look and feel, and graphics performance. They have also improved in terms of deployment options. While enterprise solutions such as Citrix have been around for some time, at a cost; the modern platforms – Java and .NET provide their own automatic deployment mechanisms – “Java Web Start” and “Click Once”. These enable applications to be automatically installed and updated each time the application is used from a web site using the ubiquitous HTTP protocol.

During the period of Client-Server technology, desktop applications were compiled for the desktop operating system. Modern platforms use a Virtual Machine and runtime environment, installed on the desktop machine, which provides application services.

A disadvantage of these runtime environments (e.g. Java Runtime Environment and .NET framework) is that they must first be installed on the desktop machine, and they are large downloads.

Some rich client platforms, such as the Eclipse RCP, employ another level of “container” for application services, which can support additional deployment scenarios, such as user-initiated update. However, the concept is the same, with the disadvantage of an additional download.

Desktop applications provide the state-of-the-art in what is possible with user interface design.

Desktop applications have been perceived as more difficult to build than HTML-based user interfaces. While this is still true when compared against traditional page-orientated web user interfaces; the difference has narrowed with AJAX user interfaces. The usability and productivity of tools to build desktop application user interfaces, using a “drag and drop” approach, has dramatically improved; e.g. NetBeans Matisse, and Microsoft Visual Studio.

Desktop applications have also suffered from a lack of a higher level application framework for integrating the user interface with server-side code; unlike web applications, which have enjoyed a multitude of frameworks. However, higher level frameworks for building desktop applications are now available; e.g. Eclipse RCP, Spring RCP, and JSR 296.

The most popular argument against desktop applications has been that they are more difficult to deploy and maintain. Customers are often not aware of deployment options such as “Click Once” for .NET, and “Web Start” for Java, which support automatic deployment and update over the Internet.

“Mini container” Rich Client Application

The title of this type of rich client platform is a made up one. It encompasses Flash and Microsoft's soon to be released Windows Presentation Foundation Express (WPFe). These are browser plug-ins that can display rich, interactive content including charts, animation effects, sound, and video. Flash technology has been around since 1996. According to one survey (http://www.adobe.com/products/player_census/flashplayer/), a Flash Player is installed on up to 98.3%[1] of Internet-enabled PCs in mature markets (defined as US, Canada, UK, France, Germany, and Japan for the purposes of the survey). WPFe hasn't been released out of beta but will be packaged with Windows Vista when ready.

I refer to them as “mini containers” because their download size is much smaller (1.1 MB for Flash Player 9) compared to the Java Runtime (7 – 13MB) or .NET Framework (22.4 MB).

The main advantage of this type of rich client platform is that because the application runs within a virtual machine embedded in the browser, the application is guaranteed to run, using the same code, across all browsers that support the “mini container”, which in the case of Flash is the majority of browsers in common use. In addition, since Flash was devised to display visually appealing dynamic content, the richness of the user interfaces is equivalent to that of desktop applications.

AJAX Application

AJAX stands for Asynchronous Javascript And XML, and is based on a feature of modern browsers which enables Javascript to make a web request and dynamically update the displayed page with the result, without forcing a complete page refresh. This feature enables an HTML page within a web browser to behave like a desktop application.

This feature has been employed for some time; since at least 2000 when I first remember exploiting the technique, which was based on the lessons of earlier work. The biggest problem with this approach was ensuring compatibility across browsers; each browser requires a slightly different implementation, which led to code repetition and increased maintenance.

The main advantage of this type of rich client application is that the only dependency on the user's machine is that a modern browser is installed. However, there are potential issues which require experienced developers to be involved in AJAX development. These issues include security, network bandwidth and utilisation, performance, and scalability. AJAX development is potentially more complex than development of desktop applications.

Over the last few years, AJAX frameworks have emerged which attempt to abstract the implementation details concerned with working across browsers, and provide standard controls such as data grids, trees, validating text boxes, etc. These frameworks have led to using AJAX for building complete user interfaces.

There is now a multitude of AJAX frameworks, which fall into these types.

Client-side Programming

Programming is done in Javascript or using a Builder Tool to build the user interface. Interaction with the server is achieved through consuming Web Services containing XML or more compact JSON (Javascript Object Notation) message. Examples include: Dojo, Prototype, and TIBCO General Interface.

Server-side Programming

There are two main sub-types of framework within this type.

  1. Established web application frameworks have been enhanced to render AJAX-enabled controls. Examples include: Java Server Faces with Ajax4Jsf, ICE faces, or Apache MyFaces, Struts2, and ASP.NET. Builder Tools are typically used to provide a “drag and drop” environment for rapidly constructing user interfaces.
  2. In the second sub-type, AJAX applications are developed using an Application Programming Interface (API) similar to that for building desktop applications. Examples include: Google Web Toolkit (GWT), and Echo2. In the case of Google Web Toolkit, all programming is done in Java, which is compiled into Javascript and certified to work across a range of browsers.

[1] Flex 2 – Adobe's rich client development platform requires the latest Flash Player Version 9 installed on around 55-65% of Internet-enabled PCs. However, a Flex 2 application can be configured to automatically upgrade the Flash Player to the required version.

Evaluation

Score: 1 (lowest) – 3 (highest)

Criteria

Desktop Application

“Mini Container”

AJAX

Runtime (Local Installation) dependency

1

2

3

The only requirement is a modern browser, but with Javascript enabled. Some AJAX frameworks support the ability for the application to fallback gracefully to traditional web behaviour, i.e. the display is updated only when the entire page is refreshed, when Javascript has been disabled.

Level of Richness/ Interactivity

2

The developer has complete control over the user interface.

3

Flash applications look polished by default.

2

AJAX applications depend on Dynamic HTML, which can create animated effects and use images to render buttons and backgrounds; however the developer will need to be proficient in CSS to achieve the same polish as Flash or desktop applications.

Developer Productivity

2

Builder Tools have improved substantially (e.g. Matisse), and frameworks are available (e.g. Eclipse RCP, Spring RCP, JSR 296). However, desktop applications, perhaps due to their flexibility, are still more complex.

3

Productive builder tools are used. Event handling is done using a scripting language.

2

Available Controls

3

A multitude of commercial and open source controls exist. Custom controls may be created by extending existing ones.

3

Controls are limited to those provided by the application framework, but are extensive.

2

Controls are mainly limited to common types, though more are expected to be added as the various frameworks mature, and the facility typically exists to create custom controls.

Support for occassionally connected clients

2

Desktop applications can be built to run standalone. A database system has been bundled with the Java 1.6 runtime environment (since Build 88). Commercial data synchronisation libraries exsit.

3

Abobe provide a data synchronisation library for its Flex 2 development platform. It is sold separately.
I am not aware of the data synchronisation capabilities of WPFe.

1

Offline use is not supported by most AJAX frameworks. The Dojo framework has introduced a Javascript API to enable various storage providers to store data on the user's machine. Only one provider is currently included which uses Flash.

The next version of Firefox 3 will have the three key components needed to support offline Web applications: DOM Storage; an offline execution model; and synchronization.

Use of proprietary technology (risk of lock-in or investment in dead-end technology)

3

Java desktop applications depend on the Java Runtime Environment (free and open source). Windows desktop applications depend on the .NET Framework (free but proprietary).

2

The Flex 2 Builder Tool is proprietary. Similarly, the WPFe tools and runtimes are proprietary.

2

Many of the popular AJAX frameworks are open source. Some are commercial products. The APIs are typically unique to the framework. The OpenAjax Alliance is defining a common API to enable customers to mix and match solutions from different providers.

Cross Browser Compatibility

N/A

3

2

Performance and Security

3

2

1

Proven Enterprise Deployment

3

1

1

Ease of Deployment

2

3

3

Possible Future Scenarios

  1. Desktop applications make a come-back as new deployment options become better understood. For example, Sun or the open source community release a modular Java runtime environment, whereby a minimal runtime library can be downloaded. (The current Java download size is between 7 – 13 MB depending on the features selected. By comparison, the current Flash Player 9 download size is 1.1 MB. However, Apollo, Adobe's new virtual machine for running Flash and HTML-based applications outside the browser with off-line support is 6 MB.) The Java runtime environment web based installer is improved to enable Java Web Start applications to initiate an automatic version upgrade if required.
  2. AJAX Frameworks consolidate and improve in terms of “out of the box” controls and polish.
  3. Flash finally reaches mainstream based on the developer productivity benefits of Flex 2. Corporate application suites such as SAP and Oracle Fusion adopt Flash to display rich, interactive content (http://www.oracle.com/corporate/press/2006_oct/openworldsf06-06.html).

Conclusion

Rich Internet Applications will become more predominant driven by user expectations.

While desktop applications deserve more attention; in the short term, browser-based applications are more likely to be commissioned. In particular, the e-GIF standard in New Zealand (Government Interoperability Framework http://www.e.govt.nz/standards/e-gif) will direct Government applications to be HTML-based. This restrains development as dual-mode user interfaces: rich (requiring Javascript or Flash to be enabled) and standard are cost prohibitive.

Business applications are likely to evolve from the current HTML-based applications to add rich features using Javascript (AJAX) or Flash. Entire applications are unlikely to be developed using Flash; instead specific features, such as dynamic charting may be Flash based, while other features such as mapping (using a Google Maps mash-up) may be AJAX based. AJAX and Flash is likely to coexist. This architecture is also consistent with Adobe’s recommendations.

In the Microsoft world, the choices are more straightforward: ASP.NET utilising AJAX features initially and perhaps WPFe.

In Java, there are many choices. Java Server Faces (JSF) is the Java Enterprise standard for HTML-based applications. Using AJAX frameworks that integrate with JSF is a safe choice. However, JSF is hard to love from a developer’s perspective (http://icoloma.blogspot.com/2006/10/myfaces-emperor-has-no-clothes.html http://timshadel.com/2006/01/19/jsf-the-7-layer-burrito-i-wont-eat-again/). It adds complexity to do some things that should be simple, such as page navigation. These complexities can be addressed with a framework such as JBoss Seam (http://labs.jboss.com/portal/jbossseam/).

In fact, the JBoss application stack appears compelling, largely due to the Seam framework enabling a clean integration between the presentation (JSF), services (Workflow using JBoss BPM and Rules using JBoss Rules), and data access (EJB 3 or Hibernate) layers, to provide a complete enterprise application framework.

If your application needs do not require a rich user interface, then the following web application frameworks have proven robust:

  1. Spring MVC, part of the Spring Framework (http://www.springframework.org/).
  2. ASP.NET (http://www.asp.net/).

What would I use? It is frustrating that at this time, this is a difficult question to answer.

If the application is large and the need for immediate feedback in a screen is limited to a few controls, I would probably play it safe and stick with a framework such as Spring MVC, and look to develop those controls using Flex or an AJAX toolkit, such as DWR (Direct Web Remoting http://getahead.org/dwr). I would also feel comfortable using Struts2 (ex WebWork).

In addition, since many of my current customers are in Government, accessibility and interoperability guidelines mean that public facing applications must support a lowest common denominator environment; e.g. applications must be able to operate without Javascript enabled and across a wide range of browsers. This leads to a traditional HTML-based application.

If the application required rich features combined with complex server-side logic, such as multi-page forms, long-running transactions, or volatile business rules, then I would consider using JBoss Seam with JSF.

If the application was small then I would consider using Adobe Flex with the Flex Builder. I would use Flex 2 over WPFe at this time given the maturity of Flash.

These conclusions may change as the technologies and customer needs evolve.

Technology Watch List


  1. Adobe Flex 2 (http://www.adobe.com/products/flex/).
  2. JBoss Application Stack, with JBoss Seam in particular (http://labs.jboss.com/portal/jbossseam/).
  3. JBoss Ajax4jsf to add AJAX capabilities to the JBoss Application Stack (http://labs.jboss.com/portal/jbossajax4jsf/).
  4. Google Web Toolkit (http://code.google.com/webtoolkit/).
  5. Instantiations GWT Designer as a Builder Tool for the Google Web Toolkit (http://www.instantiations.com/gwtdesigner/).
  6. Microsoft Expression Blend Design Tool for building WPFe applications (http://www.microsoft.com/Expression/products/overview.aspx?key=blend).

1 comment:

markmo said...

Adobe has announced that it will open source the Flex SDK (http://labs.adobe.com/wiki/index.php/Flex:Open_Source). This may be a defensive move against Microsoft's competing platform (WPFe) still in beta. It may also attract a larger group of developers.