The ULCXML project on Java.net released the initial version of its UI design tool for thin-client Java applications. The project, sponsored by Canoo, is based on the ideas of SwiXML, but targets Canoo’s ultra-thin client platform instead. Canoo marketing director Sandra Wendland explained that,

This tool allows you to create user interfaces from an XML file. You can have an XML file, separated from the Java classes in your application, and prototype your UIs for the Canoo UltraLight Client, or ULC. You can use any XML editor that provides schema validation to make changes to your UI, without having to touch your Java code.

The sort of UIs that the ULCXML tool creates is neither pure Swing, nor JSF or Ajax. Instead, Canoo’s thin-client UI architecture provides a server-side programming model for Swing. To get a better understanding of this approach, Artima spoke with Canoo CEO Marc Domenig:

With the Canoo thin-client approach, the application deployment is server-side, and the execution is mostly server-side. The business logic, and even the presentation logic, is executed on the server-side.

On the client, the UI is rendered by native Swing. But that Swing client does not run just an individual application, but is an application-independent Swing-based presentation engine. You install that engine once on the client, and then you can execute any number of applications with this, just like with a browser... The difference from a full-blown rich-client Swing application is that you don’t need to install new versions of your application [on the client], since the application runs on the server.

The biggest difference between Canoo’s thin client approach and a full-blown client-side Swing application is that the former can take advantage of a server-side programming model. Here, again, is Marc Domenig:

You program as if you had Swing available on the server-side. You don’t have to think about object synchronization or communication between client and server. You have the same API as Swing, but the programming model is [what] you have available on the server.

The [Canoo] API is not exactly Swing, but is very similar to Swing. Instead of a JButton, you have ULCButton, or instead of a JFrame, you have ULCFrame. The names of the classes are different, but the APIs are very similar. Migration consists of moving from the Swing API to the ULC API, and once you’ve done that, you don’t have to worry about the client-server split...

ULC is just a library, and doesn’t have its own application server. With ULC, you develop servlets, and can integrate with existing Web platforms and fully leverage the entire J2EE stack. You can even share the servlet context with an HTML-generated implementation, and can deploy your application as a stateful session bean. If you need to cluster your application, you just use any J2EE clustering tool. At the same time, you’re developing fully functional rich-client Swing applications on the client.

Domenig explained that the ULC library provides more than just remote rendering for Swing components:

When a client starts up, the client sends a message to the server. The server then sends a user interface description over to the rendering engine on the client. That description includes only visible parts of the UI, not the complete UI. The model of the UI is stored on the server-side. The rendering agent on the client instantiates the corresponding Swing objects to display the visible parts of the UI. When the user executes a mouse click, for instance, the server sends over just the data required to display, say, a different tab or a window being requested.

The major difference from X11 or Citrix is that those technologies work on the level of frame buffers and pixels. The URL approach requires much less traffic, because you have a higher level of abstraction. Since the client is running Java and Swing, the client knows what a button is, and is able to render [that button]. The client also knows about skins, and so on. We take advantage of the client being able to process all that information.

Domenig highlighted the benefits of the server-side programming model in the context of a JTable with a large backing data model:

You instantiate that table once on the server, and then the built-on logic in ULC takes care of lazy loading the data, client-side caching, as well as synchronizing state between client and server...

You have the state of each session on the server side as well as on the client-side... This model is not completely stateless, and you have a slight memory overhead on the server-side compared with a purely stateless HTML-based solution. At the same time, you don’t generate as much garbage as with HTML applications, because you don’t create new HTML all the time just to throw that HTML away...

In addition [to the session,] the event model is synchronized, too, but only high-level events are forwarded to the server. Mouse tracking events are not sent, for example

Domenig believes that the ULC approach offers a way for enterprises that invested heavily in J2EE technologies to easily add rich-client capabilities to their applications. That’s because even if developers master the Swing API, Swing out of the box does not provide a solution to managing the client-server code split, and developers used to a server-side model don't have an easy way to extend server-side concepts, such as sessions, to the client.

If you developed enterprise applications with Swing, how did you handle the client-server code split? For example, how did you synchronize data between a Swing UI model, and the server-side model backing that data?