|« June 2013|
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:
wsdeploy, which does these things:
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.