Frank Sommers: Java developers hear a lot these days about rich-client frameworks. Certainly, many of those attending JavaOne earlier this year were treated to several product releases in this space, including the 1.0 release of the Backbase Java Edition. What sets Backbase apart from other rich-client Java frameworks, and what are the key new features in your 1.2 release?

Jep Castelein: Backbase has been mainly a client-side Ajax toolkit and framework. Our client product runs on any platform, including Java, PHP, and .NET. In our Java Edition 1.0 release, we added a Java-specific server-side module to the client-side Ajax framework, using Java Server Faces. In addition, we also included a basic Eclipse plug-in to help develop rich-client Java applications.

All Backbase components are JSF components, and you can use more intelligence on the client-side via our client-side Ajax engine. That engine abstracts out a lot of repetitive functions and provides a browser compatibility layer. You don't have to write plumbing code or utility functions to get attractive Ajax functionality. Everything is there from animation, forward and back [button] support, asynchronous data loading, and sorting.

Since our 1.0 release, we improved the Eclipse plug-in, and now base it on the latest Eclipse 3.2 release. We also use the [Eclipse] Webtools project, adding wizards for new Ajax project creation. As part of our Eclipse plug-in, we now provide a wizard to create custom user interface controls. For us, these are steps toward creating a complete visual development environment, which we plan for next year.

In addition to the Eclipse improvements, we also added more user interface components, such as a context menu. And we improved validation, mainly by moving validation to the client side as well, providing a combination of client and server-side validation. That provides a more interactive experience for the end-user, since users don't have to press a submit button to see validation errors.

Frank Sommers: How does a combination of client- and server-side validation work?

Jep Castelein: Many Ajax applications are motivated by the need to provide a more interactive user experience. In a traditional Web app, a user has to click on a submit button to send form fields to the server, and then receive back validation messages from the server. A more natural user interaction is that the user receives validation feedback as he types, for instance.

But you don't want to turn off server-side validation, just add client-side validation. Backbase makes that easy, re-using the same regular expressions on the client and the server. You define that functionality once, and the framework takes care of where to perform validation. You just set a flag to indicate how and where you want validation performed -- you can do all your validation on the client, or all of it on the server, or validate on both the client and the server.

Frank Sommers: You touched on a key decision for an Ajax developer: how to distribute processing between client and server. Based on your experience in rich-client development, can you provide a few general guidelines?

Jep Castelein: In general, if end-users want a more interactive user experience, then the best way to give that interactive experience is to move certain presentation logic to the client. We don't believe that business logic belongs in the client. But to provide a better user experience, the capabilities of the client should be utilized.

If you look at the JSF market today, most products I know of do everything on the server. If there is an end-user event in the browser, they call the server, and the server decides what should happen. If you have a richly interactive user interface, the number of calls to the server can grow exponentially. Because you always have some latency before the client gets a response, the user interface will start to slow down as the application gets more interactive. When you notice that, you need to move more intelligence to the client side.

Frank Sommers: How about rendering? Many JSF/Ajax frameworks today perform rendering on the server, and then call back to the client to update a component's state. As a user expands a tree component, for instance, the server renders that expanded tree. To better utilize the client's capabilities, how much component rendering would you perform on the client?

Jep Castelein: A tree is an interesting case, because where rendering should take place depends on how big that tree is. If you have hundreds of nodes, you can send the entire tree to the client at once, so you won't need to go back to the server to expand that tree, but have all the information available in the browser. Expanding a node then does not require immediate server action.

However, if you have thousands of nodes, you'd load only some of the nodes from the server, and the other nodes would be fetched as you expanded tree nodes. Note that even if you loaded the entire tree in the browser, the Backbase state synchronization mechanism will synchronize the state of the tree with the data model on the server.

Frank Sommers: I may not always be able to anticipate the size of a component's data model. Are your components smart enough to figure out the best distribution strategy between client and server at runtime, or does the developer have to make that choice based on the information he has at development time?

Jep Castelein: If you try to make a component extremely smart, you will get the early Microsoft Word effect: as you were typing, the software would change your text to something else or would alter the formatting in strange ways. We want to avoid that in our components.

We provide default behavior based on what we think is the most common way of implementing a given piece of functionality. Then we expose the different choices that a developer would want to make – whether you'd want to do thick client side, or thick server side, and when you'd want to synchronize the state information. In many cases, we provide an API for the server-side, and an API for the client, and you can make use of that in any way you see appropriate.

Frank Sommers: You said earlier that your new Eclipse plug-in allows the creation of custom components. What use-cases would compel a developer to design a custom UI component, and when would he choose to extend an existing component instead?

Jep Castelein: There are two approaches in a UI framework to support all usage scenarios. You can provide controls that are extremely complex and configurable. Or you can make different flavors of user interface controls. We go very much for the latter approach.

A data grid is a good example. If you want to build in all the functionality different users request, then you get something like Microsoft Excel in a single control. We don't believe that that is a successful approach. Rather, we believe that you can have several different types of data grids, with each subset focused on a specific type of application. That's going to make the end-user happy, as well as the developer, because only the options that are relevant are shown, and it's also much easier to get better performance out of that simpler component.

For instance, consider a list view, which is a sort of data grid. If you use that type of a grid in an email client application, it's important to have a good context menu, and also to be able to drag and drop the different records in that data grid. By contrast, you might have another data grid in a data manipulation application. There, you want to be able to edit inside the cell, which is not what you need in an email application. These are both grids, but people use these grids in completely different ways. So you may want different grid flavors to support those use-cases.

Almost every project has some kind of unique control. With our Eclipse wizard, it's pretty easy to create a component that's unique to your project. If you just need one or two Excel-like functionalities in a data-grid, you can add that to our basic data grid. That will do exactly what you want it to do, and will still perform well. And we heard of people combining user interface components, such as combining a toolbar with a drop-down menu. As for creating completely new components, one of our customers built an SVG mapping application exposed as component.

Frank Sommers: There is much less knowledge and experience building complex rich-client applications than there is similar information about building traditional Web apps. In addition to the server- and client-side components, how does your product help a developer construct more complex rich-client applications?

Jep Castelein: We don't believe that individual components from a single component vendor will in the end make it easier to build complex rich-client applications. A single component will not provide a solution. If you want to approach the power of client-server communications, you will need an integrated framework, both on the server and on the client. You can see that also in the Windows world where Microsoft has a very solid framework to which component vendors can plug in. And component vendors are successfully adding value that way.

In the Java world, JSF is a good server-side framework, but you need something that integrates with the client-side as well. Backbase provides such a framework, allowing you, for instance, to get the benefits of some client-side processing while not having to hand-code any JavaScript.

If you use the JSF components that we deliver with the product, that's just a pure JSF – you don't need to know anything about Ajax or JavaScript. If you want to move more intelligence to the client and handle some business or presentation logic on the client, you can do that with XML tags. For instance, with a table, you can set a sort attribute to make that table sortable. If you have something very specific, or if you have existing JavaScript code, you can also use that with our framework, it's just that there is no need to do so in most cases.

Finally, we also try to put user interface patterns in our user interface components. That allows developers to not have to think about how to build an application; instead, we provide best practices that can be followed.