And another thing... Tim Quinn's Blog

During 2005 I spent time adding a feature to the GlassFish implementation that allows end users to launch app clients using the Java Web Start technology included with the Java runtime. I had a great time doing it, partly because I got to learn and apply some new technology and partly because I got to work closely with many different people in Sun's app server group and other organizations as well. But more importantly, the addition of this new feature may help reinvigorate interest in rich clients as part of enterprise apps.

I'll say right off that we consciously chose to implement a subset of all the features we could think of, so we're eager for you in the community to try the feature out, say what else you'd like to see, and even contribute to the implementation.

Here's some background on app clients and why the new feature seemed like such a good idea...

In Java EE, an application client is a rich-client component of an enterprise app that runs in a lightweight container on the end-user's client system. This app client container (ACC) takes care of a number of details common to many app clients (such as security, dependency injection, and annotations) so the developer can concentrate on the key business elements of the overall application - including the rich client piece.

In earlier versions of the app server, an administrator or an end-user would install the ACC and supporting jar files on remote clients manually or using their own automated procedures. This infrastructure supports any number of app clients from the same or different enterprise apps. Then, either during the deployment of an app or as a separate step later, the user would retrieve the generated app client archive from the server. (The generated app client jar contains the app client code which the developer created as well as other classes and files generated by the app server specifically for that app client.) With the ACC infrastructure in place and the generated app client jar file downloaded to the remote client system, the user would run the appclient script that is part of the ACC infrastructure, specifying which app client should be launched.

That may sound like a lot of work - at least the first time or so you have to do it. After that it begins to become second-nature, but someone still needs to set up new remote client systems and keep the bits on the clients synchronized with new versions of the app on the server.

The whole problem of

• downloading and launching applications from a central server to possibly many clients,

• caching and reusing bits locally on the clients, and

• keeping the downloaded bits up-to-date with what's on the server

is precisely what Java Web Start technology aims to solve. So in the GlassFish project we've kept the original way of working with app clients but we've also added a feature that allows end-users to do all of that by using Java Web Start technology instead of the manual set-up and the appclient script. By visiting a single URL in their browsers - or clicking on a link that's on a Web page in an app they're using - end-users can very easily retrieve the needed files and start the app client.

This is already longer than it should be, but it should give you an idea of the issue we wanted to address and the benefits to admins, developers, and end-users of doing so. I'll be devoting other entries to more aspects of this feature: how end-users use it, how developers can take advantage of it, how we've implemented it, and so on.