Recently I was giving a demo of Java Web Start (JWS) to a customer and while they appreciated that systems management issues had been addressed, someone in the audience said "it's just client/client all over again - not really client/server." Her point was that true client/server is about the runtime separation of the two environments, not just deployment magic. It was my fault because I had used a "Hello World" program to demonstrate JWS, first running it locally and then deploying it across JWS in a "look no hands, ma" kind of fashion. My demo slide even included the bullet point that no changes were required in the Swing program to allow it to run across JWS. She told me, in nice words, that I didn't get it because changes should be required. The runtime dynamics of how the program should validate input and access data are different when run locally or across a client/server divide.

What she was looking for was a mechanism for building a Swing program that had several pieces to it: a client that concerned itself with presentation, local validation, and a richer UI experience than HTML currently offered; a server that dealt with issues such as persistence, concurrency, and load balancing; a bit in the middle that was the runtime transport layer; and a distribution mechanism for which JWS appeared to be satisfactory.

It was a sobering discussion for me, because it made me realize one difference between server people and client people. In the client space we're often obsessed with the GUI toolkit and widget APIs. The server heads, however, seem more focused on the application itself - the transactional nature of the program, the workflow of tasks and data, and issues with multiuser persistence and scalability. Architectures such as Struts, EJB, or JavaServer Faces tackle these issues by providing frameworks that power the application, whereas analogous client initiatives seem lacking. GUI builders still provide palettes of basic JFC components, but when it comes to the question of building a scalable real-world application, the user is often left to reinvent the wheel rather than have these frameworks provided out of the box with J2SE.

Several good ideas came out of the ensuing conversation with the customer regarding things they wanted to see formalized.

Separate UI and Back-End Logic
It makes sense from an object-oriented viewpoint to separate the UI from the back-end logic, but why not have this architected into the framework. The GUI could be separately serialized into some kind of XML format to allow easy transmission across HTTP, and arguably easier construction for people who preferred markup languages to writing Java Swing code. Other issues such as providing different GUIs for levels of accessibility, countries, or hardware devices could be achieved by providing new XML files that were dispatched according to each client type.

Use Web Services Between the Client and Server
Communication between the two sides could be done using Web services, so the server components are managed as a pool of shared resources in a J2EE server that each client communicates to. Having a defined protocol between the two portions of the application insulates each side, so new implementations of existing services can be swapped in without disrupting the client, and likewise new clients can be created combining multiple services for a single functional task. Unlike JDBC, where the program's SQL exposes the structure of the server and is thereby vulnerable to structural changes, Web services tend to be more task-oriented, like a more traditional transaction API providing both physical and logical separation.

For the GUI portion the beginnings of this might already be there with technologies such as SwixML (www.swixml.org), SwingML (http://swingml.sourceforge.net/), or the XMLEncoder/XMLDecoder that was included with 1.4. There is more work to be done, however, such as integration into GUI builders, which almost exclusively serialize to Java code right now. It's not enough to store a GUI in XML; there is still logic that is going to occur on the client that needs to be written, so there should be a way that the GUI can be deserialized into the Java client piece and elements of it can be easily accessed - sort of like a JAXB for named Swing components or maybe some kind of XPath solution. While proxy classes can be created for communicating with the Web service, there are quite a lot of code steps to go from WSDL to a usable Java API for the GUI. Some of this could be abstracted out into reusable components that provided dynamic bindings and configurable behavior. Right now the JFC includes graphical component classes, but why not extend it to have more JavaBeans that are less concerned with presentation, but instead know how to broker a conversation between the UI and the data and/or transport layer. One of the projects that I hope might be able to provide these kind of pluggable components is Java Desktop Network Components (JDNC) that offer the promise of an easily customizable API for people to create the middleware components currently missing in Swing. Whatever the answer, I think that J2SE should move its focus away from the glass and down into the application framework space. The solution should not be demoware, however, and should become the foundation framework for users wanting to build large, scalable client/server applications. So instead of building wheels, developers can focus more on their domain-specific logic and less on plumbing and glueware.