The conference program was quite balanced and beside the main stream topics about SOA (ServiceOrientedArchitektur – represented by the SOACon conference), Spring, Application Security and OSGi there was a huge number of different topics, which were addressed by several talks.

Most interesting from my point of view were following sessions:

• Keynote from Jonas Jacobi: Re-architecting the Web with HTML 5 Communication.
• Talk from Karsten Lentzsch: Efficient design of swing UI’s.
• Talk from Angelika Langer: Java programming in the age of multicore.
• Talk from Dierk Koenig: RESTful JEE with Grails.

Canoo was exhibiting on a booth, which gave the great opportunity to present and talk about our products UltraLightClient (ULC), the just released language application for the IPhone (using canoo.net), our demo for the new JavaFX platform and fancy UltraLightClient / Swing rich client applications. In addition Canoo members used the presence to keep in touch with existing costumers, contact new ones or presented the company to potential new staff members.

Canoo Online Quiz

All the visitors on the booth and all other interested software developers had and still have the possibility to join an online quiz. Its possible to win an iPod touch or one of ten ‘Groovy in Action’ books. The quiz can be found at www.canoo.com/quiz and will end at the 30.11.2008.

Dierk König, Canoo fellow and author of the ‘Groovy in Action’ book, was holding a groovy workshop and was giving a talk about RESTful JEE with Grails.

Why ULC (Part 3)

I’ll spare you the typical marketing speak about how we believe Canoo’s UltraLightClient will save you real money in terms of time for development and maintenance. Instead I’ll quote from an email that we received from one of our North American customers.

This development team decided to replace JSF by UltraLightClient halfway through the project. Despite this major change, the project deadline was not extended. Nevertheless, the team managed to deliver in time. Here’s what the Project Lead for Web and User Interface Development had to say on UltraLightClient:

1. JUnit testing With JSF, unit testing of the interface required much contortion and difficulty in order to make sure the html interface was rendering the correct html. With ULC and Jemmy, the process is as easy as naming the widget and testing its behavior or content. This made for not only easier testing, but far more and far better test cases as the developers had more times and better ease of implementation.
2. Extremely easy communication with the model. Eliminating the deployment descriptors of JSF, we could interact with the model by actually accessing attributes and calling methods directly on the actual objects. This eliminated the continual transformation between objects and beans, etc that JSF requires. I realize a lot of this can be facilitated with tools, but it seemed even better just to eliminate this needless transformation. Also, the performance was far better with this direct access to the model.
3. Deploying locally. This is the holy grail of ULC. The fact that I can hit in Eclipse and see exactly what I am working with, or even better, put a break point in the test case and play with the specific part of the interface from there without having to deploy the application! WOW! This reduces developer time by hours per day.
4. Rich functionality of ULC widgets. This may seem like just a perk to the interface but it is a development issue as well. The fact that the widgets are so feature rich allows the developer to spend less time trying to simulate rich features in DHTML or JavaScript and more time actually realizing the requirements of the application.

I believe these 4 points are the most important benefits we realized in developing in ULC. (…) We built a full fledged loan renewal system interface in 5 months (4-6 developers). This would have been impossible without the development ease of ULC.

Other corporate customers say similar things

Please feel free to contact the ULC sales team and ask for further references.

Further links:
Pricing
Case Studies

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

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