Rich Internet Applications

In this blog post series, I am revisiting some of the arguments for a Java-based RIA library such as UltraLightClient. Please leave a comment and share your views. Read Part 1 here.

Why ULC? (Part 2)

Within UltraLightClient the programming model and the execution model are server side based. ULC applications are installed and run on the web server. On the client side, a small, browser-like presentation engine, that is generic for all applications, links up with the server to display the corresponding user interface component.

Fair enough. But how will your business web application project benefit?

Consider the following reasons:

1) Faster development - re-use instead of re-invent

UltraLightClient was designed for complex web applications in the business world, such as typical data entry applications with tonnes of data, tables, table trees, tabs, forms, charts. The library offers a full range of user interface components to build better web interfaces for enterprise applications.

From a developer’s angle, UltraLightClient takes care of the client/server environment. It handles distribution between the two very efficiently, and as a developer, you do not need to worry about the client/server split. All the application code, presentation and domain logic are run on the server. Development tasks such as distributing the logic between client and server are not required.

Another huge advantage during development time is that you can preview, test and debug without deploying the application. See Chapter 2 of the ULC Essentials Guide for a detailed description of the ULC DevelopmentRunner.

2) Re-use existing HTML application platform

ULC applications share the entire software platform with HTML applications and are easy to integrate with HTML applications. ULC has a typical web application architecture and can be easily used alongside many excellent tools and libraries (e.g. Spring, Hibernate)

3) Better security

In general, ULC applications are easier to protect against security attacks than AJAX-based applications. Java is less vulnerable than JavaScript. ULC applications are secure from cross site scripting (XSS) attacks.

No application code is shipped to or run on the client. The presentation engine is generic and is less susceptible.

4) Profit from Java EE scalabilty options

Standard Java EE is supported. This means that all the scaling options available for Java EE can be used to deploy ULC applications.

5) Highly responsive applications

From the very start UltraLightClient was designed to develop web applications with a desktop-like user interface. The communication has been highly optimized for the web. This ensures fast responses and ensures an increase in user productivity in comparison to the sluggish performance of AJAX applications. ULC applications easily keep pace with the performance requirements of knowledge workers and supports this user requirement out-of-the-box, i.e. you will not need to spend extra time trying to make your web application more responsive.

Link summary:
Why UltraLightClient? (Part 1)
Top reasons to use ULC
Case Studies

At Canoo, we strongly believe in the benefits of a Java-based approach to build richer business web applications. In various service projects, our customers have greatly benefited from this strategy.

We would like to convince more companies to try out UltraLightClient for their web app projects. Within this context, I would like to start a new UltraLightClient blog post series discussing reasons how the Canoo RIA library will benefit your upcoming web project.

Obviously I will be listing the reasons for UltraLightClient. Please feel free to list your comments. In fact, I would like to encourage you to list your doubts and questions. After all, this is a blog. And between you and me, we are a company that likes a good discussion.

One of the first reasons we like to list is:

UltraLightClient is a “Single Technology” approach to building better interfaces for business web applications.

It is a lean Java library that can be easily integrated into your current web app infrastructure. It relies on the Java platform and delegates functions to Java EE and Java SE wherever possible.

What does this mean for your project?

1. Faster and simpler development, because your development team does not need to switch between various programming languages, development tools, or technology concepts.
2. The only language used to build rich user interfaces is Java. UltraLightClient follows standard Swing concepts and its API.
3. It is easier to find developers with the right skill set. Java is a well-established, proven language and you will be able to hire from a wider pool of developers. By selecting Java, you have access to a vast array of open source and commercial libraries and tools (e.g. excellent IDEs).
4. Debugging, testing and maintenance tasks are easier than within an AJAX-based project. Software defects within a single technology space can be tracked much more easily.
5. ULC’s single technology approach is more than skin-deep. With AJAX you might have a nice high-level JavaScript-only API. But as soon as you try to extend an AJAX library, you are exposed to all the ugly details of DOM, XML, CSS, etc.
6. The single technology approach substantially reduces configuration problems when trying to find the right combination of libraries and tools. In a multi-technology environment this is much more time-consuming.

And at the end of the day, these points will save you “real” time and money and reduce the overall risk that your business web application will fail.

Next post in this series: Server-side Architecture

About Canoo and its RIA Technology

Canoo is a solution provider for Rich Internet Applications (RIA) based in Basel, Switzerland. It offers consulting services and end-to-end development of Enterprise Web applications.

Canoo develops and maintains UltraLightClient, a library to create enterprise-class Rich Internet Applications. UltraLightClient bridges the gap between Java Swing user interface components and a Web architecture, providing a cost-efficient, single technology and mature alternative to AJAX.

See also:
“Top reasons to use ULC”
Stefan Ried’s Forrester Report

Here are some quick notes on the sessions I attended yesterday at Sihlcity. I believe Jazoon will be uploading videos and slides very soon:

First in my lineup was a talk on using Google Web Toolkit for a business application in a typical enterprise environment. This was kind of like a case study. Dmitry Buzdin talked about the experience his company gained and listed the various pros and cons.

Next, I listened in to Bruno Schäffer’s talk together with Christoph Henrici and Daniel Buffet of APG. The talk described the migration of an Oracle Forms application to Java forms for the advertising industry. Main requirement: development and application performance had to remain just as fast as with Oracle Forms. A requirement that the migrated application managed to over-fulfill.

Canoo’s Andreas Hölzl and Christian Stettler presented their Google Android experience report. They showed an application they developed for the Android Developer Challenge called Mobile Zoo. Their baseline: “What’s here looks promising. Let’s see the devices!”

Brian Sletten’s presentation on data-driven applications was very interesting. I particularly liked the analogy between resampling music and data.

This morning, I attended the second keynote at JavaPolis 2007 in Antwerp. Although it was not the “big” keynote (that one was held by James Gosling the day before), it was definitely the more interesting one to me. This is why:

First, the Java community was hit by two extremely cool Flex demonstrations: at the beginning, Bruce Eckel and his co-speakers showed a Flex-based data manager framework that allows transparent and smooth synchronization of client-side and server-side business data, even between multiple clients and with clustered server nodes. Data changed on one client gets synchronized to the server (for example: to all cluster nodes) and then back to all connected clients. Not only does it allow the application to determine the “transaction commit point”, but it also provides support for conflict handling (again, the conflict reconciliation handling can be fully controlled by the application). Whenever a client goes offline, data changes are locally tracked and synched back to the server as soon as the connection is re-established. Failed cluster nodes get updated as soon as they rejoin the cluster. In addition, the data manager can also be used with Ajax applications. Although the demo application looked quite “ugly” (for a Flex demo …), the technical brilliance led to spontaneous applause …

The second rocking Flex demo was Parleys.com beta: well-know for slick and smooth video and slide show streaming, Parleys.com is about to get a face-up. Well it’s more like a revolution. While it was based on Ajax in version 1.0, the new technology chosen is Flex. Of course, the visual effects are extremely slick and appealing. But what is way more interesting to me from a RIA point of view is the integration of the online, browser-based version with an offline Parleys.com client application based on AIR. When both clients are running, the browser-based one automatically gets enhanced by features available in the offline client - such as offline video availability - by smoothly adding new buttons and actions to the online client. That really rocks from a user experience and integration point of view! The new Parleys.com version is about to be released in Q1/2008.

But there is a fight-back from the Java side: also worth mentioning here is the Java approach of browser-based RIA that was demonstrated in the IRIS sample application. First showed to the public at the last JavaOne, this application does not stand behind the Flex-based ones in any way when it comes to visual effects. The IRIS approach smoothly integrates Java applets with an ajaxified Web application. It was almost impossible to say what feature was powered by the applet and what was done using Ajax - and what was done by tightly combining these two technologies even for a single user interaction. The revival of the applets!

To me, all these demos really show to me that RIA is still steadily increasing in importance. There is way more than just adding a few fancy Ajax effects to static web page - and the big vendors and technology owners are pushing the car forward. And the desktop is really moving back into the RIA world - it is no longer all about pure (and old) browser technologies, but about JNLP, applets, AIR & Co.

But there was also another unexpected “flasher” in that keynote: JavaME. JavaME? Isn’t it dead? No, it’s not! Sun showed up with the new Netbeans Mobility 6.0 that extremely simplifies the development of JavaME-based games. But not only games, also business applications are finally showing up in the JavaME space (and are supported in a graphical way by the mobility tool). Using the SVG-rendering facility available in the MSA (Mobile Service Architecture), these UIs now can really look awesome (forget these old and ugly “text-based” mobile UIs …). And by adding JavaFX Mobile to the scene, Sun is pushing the Java mobile stack even further. As with Google’s Android, Sun aims to provide a complete software stack based on a Linux kernel that offers Java-based APIs to all phone capabilities which are then used by all the device vendors, third party RIA software service providers and the community to develop new-class mobile RIA applications. It will be very interesting to see whether Sun or Google (or both?) will make the deal with their approach. In the end, I think the device vendors are going to decide this battle: every cool software platform is only worth noting if there are a big bunch of devices available that ship the software by default.

A few resources:

• http://meapplicationdevelopers.dev.java.net
• http://community.java.net/mobileandembedded

All this mobile stuff now really seems to shake a leg. Very exciting!

We just updated the Canoo events page and I would like to point to Dierk König’s impressive Autumn 07 schedule at: http://www.canoo.com/events.html

Dierk will be speaking at:

• iX Workshop in Zurich, Munich and Frankfurt.
• Grails eXchange 2007.
• W-JAX in Munich.

If you’re attending any of these events, stop by and say hello to Dierk…

He recently wrote a series of articles on Grails for iX magazine (in German).

The Flex-Ajax-Bridge is a library which exposes Flex application to scripting within the browser. As stated on the Adobe Labs wiki:

After you insert the library, essentially anything you can do with ActionScript, you can do with JavaScript.

We introduced the Flex-Ajax-Bridge in our talk Mixing Ajax, Flash and Swing. It seems Adobe has now decided how they want to distribute it: They moved it out of Life Cycle Data Service 2.5 (limited free use only) and into Flex SDK 3 beta. Which is certainly good news.

And there is more Ajax support: With Ajax Data Service Adobe provides Flex Data Management Services capabilities (pushed updates, conflict management, lazy loading, and direct integration with back-end domain models) for Ajax applications. Ajax Data Service is available in Adobe® LiveCycle® Data Services ES.

As mentioned in my previous post, the UltraLightClient team is working hard on a new release. Yesterday, a new milestone was published.

This is the last milestone leading up to the final release. To get a preview of the new testing framework and other features, feel free to download and evaluate it.

We really appreciate any feedback you can provide.

Resources on UltraLightClient

Here are some resource links I would like to highlight:

• Included in the download package are a number of sample applications, a great way to get started. The Installation Guide lists the steps required to set up your IDE and to run the samples.
• Here is an overview of all UltraLightClient-related user guides and API documentation.
• The community site offers further examples, extensions, integration plugins, and tips.

This is part 3 of 3 blog posts discussing the article “How to Choose an RIA Path: AJAX or Adobe?” by Jeffrey Hammond. Read part 1 and part 2.

Java is a third option to breakdown the barriers RIA faces in corporate environments.

In this final post, let’s turn our attention to the first point I listed in my comments on Jeffrey Hammond’s article (see part 1):

AJAX and Flex are not the only options for RIA. There is a third one to consider: Java (see for example Eclipse RCP, a rich fat client technology, or UltraLightClient, a Swing-based rich thin client technology).

Jeffrey identifies four barriers that prevent firms from introducing RIA (based on AJAX and Flex):

1. Both are not easy to integrate into an enterprise environment.
2. Both are in some way dependent on the client configuration (or a user’s willingness to change it). Although AJAX does not require any additional installation, JavaScript may be disabled and AJAX applications will not work. Adobe requires the Flash plug-in and users may not be willing to install or update it to for a RIA they find on the web.
3. The ecosystem for both approaches is not mature.
4. Both lack the support of extended development tools.

Reuse Existing Infrastructure

Java - on the other hand - has been in use as a server technology for Web applications for many years. The infrastructure to integrate applications into a corporate environment is available. This infrastructure is proven and there is a lot of experience on how to use it. As outlined in part 2, companies that operate HTML-based Web applications will not have to change the connection to data sources when migrating from these Web applications to Java-based rich thin clients.

Of course, a Java-based RIA requires a Java browser plug-in. Consequently, this barrier remains as high as before – at least for internet applications. But for applications with a limited user community, installation of a plug-in like the JRE or Flash is in many cases acceptable.

Java has a rich and mature ecosystem which has been evolving for more than ten years. A wide selection of proven commercial and non-commercial libraries, frameworks, and tools are available.

There are various extended tools supporting quality assurance such as testing tools, monitoring and measuring tools, as well as development and debugging tools. What is lacking is a comparable design and authoring tool support as offered by Adobe and third party vendors of Flash.

After having said this, I would refine Jeffrey’s recommendation regarding when to use AJAX and when to use Flex in the following way:

Jeffrey recommends using AJAX when time-to-market is critical and when frequent changes to an application are expected. I would add: Use AJAX if this application is published to the general internet at large and browser plug-ins are not tolerable. It is a good advice today to restrict AJAX to a minimum and to ensure that the application works even if JavaScript is disabled.

For large-scale user productivity applications, Jeffrey opts for Flex. I would add: yes, if besides functionality the visual appearance of the applications is critical, and as a result, advanced design and authoring tools are needed.

In all other cases, i.e., if I do not want to publish my application for casual internet users that are just passing by, and visual appearance would be nice, but functionality and integration into an enterprise information system is more important, then I would recommend using a Java rich thin client like UltraLightClient.

See also part 1 and part 2.

This is part 2 of 3 blog posts discussing the article “How to Choose an RIA Path: AJAX or Adobe?” by Jeffrey Hammond. Read part 1.

A second argument that needs some additional discussion is Jeffrey Hammond’s point that AJAX favors gradual re-factoring of existing Web apps.

AJAX favors gradual re-factoring of existing Web apps. AJAX is based on open and standard languages like JavaScript and XML. This makes it easy for developers to integrate AJAX widgets into existing Web applications that are written in HTML, DHTML, or server-side JavaScript.

I agree that this is a good way to improve existing HTML applications, i.e. adding some AJAX functions in a limited way to offer a better user experience, but without changing the application code substantially. In most cases the resulting application will work without JavaScript – it will only be a little less comfortable to use.

But if you plan to cut deeper into your application – especially if you plan to change the communication patterns with the server to retrieve data – then this might have impact on your backend software layers. In the worst case, these comparatively small changes at the user interface level might lead to unforeseen and unplanned changes in the data service layer.

Gradually introducing AJAX into your existing Web application may lead to unforeseen and expensive refactorings in lower layers

The above diagram shows common variants of Web application architectures. The right column shows the architecture of a traditional HTML-based Web application. With JavaScript and AJAX more parts of the application are being shipped to the client (first and second stack on the left). While in the traditional Web architecture data services have always been called locally within the server tier, an AJAX application might call data services directly from the client. For performance (and sometimes security) reasons the latter case requires that data service interfaces are tailored to the presentation needs (strictly speaking: only data that is displayed should be retrieved). This often contradicts reusability of services. In many cases, services used in traditional Web applications have broad interfaces designed for reuse.

By the way, a similar argument holds true for Flex as well, since Flex applications also call services directly from the client.

In a nutshell: be careful when starting to re-factor existing Web applications to add RIA functionality.

When should you use AJAX beyond polishing your application in a very limited way? Clearly, if you know that your target audience will not download an external plug-in to access your Web application, AJAX is currently your only option. To date AJAX is the only RIA technology that allows the whole internet world to use your application without extending the browser with additional plug-ins – provided JavaScript is not disabled.

Read part 1 and part 3.

This is part 1 of 3 blog posts discussing the article “How to Choose an RIA Path: AJAX or Adobe?” by Jeffrey Hammond.

Recently I stumbled across Jeffrey Hammond‘s article published in the May 2007 issue of AjaxWorld Magazine. Actually this article is a summary of a Forrester Research Report published in December 2006. The article (and the full-version report) helps readers to decide whether to choose AJAX or Adobe’s Flex for their RIA solution. It brings up some very crucial arguments - pros and cons - for both approaches from a project manager’s perspective that many others focusing on mere technical aspects leave out.

I can really recommend reading this article but I would like to add some comments because of two main reasons:

1. The article suggests that we have only two big options to select from – AJAX and Flex – ignoring the third option: using (plain) Java to build a RIA where especially this third option overcomes three of the four limitations that Jeffrey considers as the main obstacles to using RIA technology.
2. Jeffrey gives three arguments in favor of AJAX (vs. Flex):
   - shorter time-to-market,
   - incremental change of existing Web apps,
   - and speedy performance.
   The first two – although convincing at first glance – might become at least questionable when digging a little bit deeper.

I will start my discussion with this second point:

AJAX: The Fast Lane to a Better User Experience

In my opinion:
You are not necessarily faster developing with AJAX than with other RIA technologies.

Jeffrey claims that AJAX helps shops to meet time-to-market needs because the learning curve for developers is not as steep as with Flex. Two comments on this:

1. Knowledge of languages and frameworks is only one critical factor in determining time-to-market. Quality and functional richness of the libraries used, availability of development tools and IDEs that boost a developer’s productivity (Jeffrey mentions this issue in the list of cons), and the impact on overall architecture (I will come to this in a later post) will also determine time-to-market – and depending on the size of the project – are more important than the effort to learn a new language like mxml.
2. My own experience in applying AJAX technology (I must confess – from a manager’s perspective) is that no developer knows all required languages to build an AJAX application on the same level. Some have very deep knowledge in Java and XML but only beginner’s or medium level expertise in applying CSS or programming JavaScript. With AJAX, developers have to use new and swiftly evolving libraries that vary in the functionality they offer (ranging from very low level libraries like prototype to very high level like Ext JS) and programming model (some are more server- and Java-centric while others require heavy JavaScripting). Bringing all this together is normally a complete new experience for developers – even if the “traditional” ingredients of a Web application are well known.

In summary, a project manager who plans to develop a RIA should carefully think about the time-to-market argument and AJAX. For small projects that incrementally add some limited AJAX features to an existing Web application I can underline Jeffrey’s statement about time-to-market. We made this experience when we ajaxified our online dictionary Canoo.net. But when building large applications, especially to be integrated into a corporate environment, I would not subscribe to Jeffrey’s point of view.

To be continued in parts 2 and 3.