An Interview with Xoetrope's Val Cassidy from JavaOne 2007

Rich-client user interfaces are often motivated by the desire to offer users a more interactive, even desktop-like, way to use a Web application. Rich clients, however, can also be a mechanism to allow an application to scale to a larger number of users.

While Web applications traditionally perform all processing on the server—both processing of business data and processing of the generated HTML output—rich-clients can relieve the server of some of that processing. A simple example of client-side processing is sorting data on the client. The more data is made available on the client, more processing can be pushed to the client, making rich applications rich not only in the sense of user interface elements, but also because significant amounts of data is cached in the client.

Irish start-up Xoetrope used that sort of richness to help scale a popular open-source PHP application, Sugar CRM. By providing a rich-client Java client to Sugar CRM, Xoetrope allows a Sugar installation to serve more users, since the rich Java client reduces processing on the server, according Val Cassidy, CTO of Xoetrope. Cassidy pointed out in an interview with Artima that:

What's created on the back-end is HTML that we can read and transform into XML that will then drive our rich Internet application, which is Java-based. Within our XUI framework, the engine that runs [the client] is based on an XML description that hooks back into the Java logic. It's a very flexible way of working with metadata and pushing it out to the rich client...

Most of the work is being done on the client, caching is taken care of [on the client]. You are not serving up the HTML that's displaying the application. So you're taking a huge load off the server. The end-result is that your server can serve more clients. The client machines perform better, and can also start interacting with the desktop...

Cassidy also noted that this technique requires some extra care from developers: Because each client caches potentially identical data items, the system must check for, and handle, update conflicts:

You would do concurrency checking of the data. It's really up to the developers to decide how they handle that, whether to present the conflicts back to the user and let them decide how to handle them, or work with them on the server [and] cache them for an administrator to work with that later.

Val Cassidy, CTO of Xoetrope, talks about scaling enterprise applications with rich clients. (5 minutes 6 seconds)

What do you think of Xoetrope's client-side caching approach to scaling an enterprise applications?

Talk back!

Have an opinion? Readers have already posted 3 comments about this article. Why not add yours?

About the authors

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.