… and complicated things should be possible. And, for that matter, not unnecessarily complicated.

I don’t know how many years it’s been since Alan Kay said that, and people still don’t listen.

I’m working on an application now that uses a Swing-based client, deployed using JNLP (i.e., Java Web Start). The client talks to a SOAP-based web service. It’s written using Apache SOAP, which has worked out pretty well, but for various reasons I’ve been looking into reimplementing the web service part using Sun’s JAX-RPC.

Some background: JNLP-based apps are deployed from a web server, and launched (the first time, at least) from a web page. But they’re full-fledged Java apps that get downloaded as JAR files and run on the client machine. So the best way to package it is to put the whole client—the JAR files, the HTML pages, and the JNLP file—in the WAR file with the server-side stuff. And that’s the way our build system works. We compile the whole thing, build the client JAR, and then build the WAR that includes the client.

In JAX-RPC (at least, in Sun’s implementation of it) they’ve tried to make the process easy. The service is defined as an RMI interface, and the implementation also fits RMI conventions. So far, so good. Then you compile the service definition and the implementation class. Then things get bad. In an effort to make this all simple, they’ve gone too far. The next step is that you package your server and a SOAP mapping file into a WAR file, and pass that WAR to a tool called “wsdeploy”. That tool reads your WAR, generates stub and tie classes that are used to hook the client and server code into the SOAP infrastructure, and then repackages your server, along with the tie classes and the server-side SOAP support, into a brand new WAR file.

All of that has to be done before you have the stub files that you need to properly compile your client code. So our nice, clean, 3-step build process (compile, package client, package server) turns into this:

  1. Compile server
  2. Package server into WAR
  3. Run wsdeploy, which does these things:
    • reads the WAR
    • generates stubs and ties
    • rebuilds the WAR with ties and SOAP infrastructure included
  4. Compile client
  5. Package client
  6. Add the client to the WAR file.

That’ll sure shorten the edit/compile/debug cycle and keep my ant scripts clean.

It turns out that there is another tool, xrpcc, that generates the stubs and ties in a more conventional way. But I haven’t been able to find any documentation for that tool. It, too, uses an XML-based config file to define the SOAP mapping, but it’s a different flavor of XML, with no documentation that I can find.

I’m all in favor of a good out-of-the-box experience. But it’s frustrating to hit a brick wall when you try to move beyond that to real work.