JAX-WS kinda reeks, and here's more of why.

Loughran and Smith, in an HP whitepaper called "Rethinking the Java SOAP Stack", discuss a new RPC implementation, called "Alpine." It's an interesting read, sort of a quickly-done 99 theses nailed to JAX-WS' door.

However, I think they miss a few critical points.

• In section II.A.1, they mention the impedance mismatch between XML Schema and Java classes, pointing out that Java loses restrictions that Schema doesn't. That's... fine, I guess, but presumes that an XML Schema "string" type maps to a java.lang.String, which is an acceptable mistake. Except it's not. Anyone who knows Schema would know that restrictions on type would mean something that contained a String along with constraints or requirements... not the String itself, although I suppose it could be argued that java.lang.String should actually have the ability to manage such constraints itself.
• The issues of unportable types... well, let's just say that I think C# and Java need to get off their collective high horses and figure out what a date looks like, and be done.
• II.A.5 also blames naive implementations, referring to cyclic graphs in the object models. While I'll happily concede that it's a concern, it's obviously a concern that the mapping can and should address, perhaps through references. In fact, most likely through references.

They then go on to mention a new mechanism, Alpine. I really don't care about Alpine here - I haven't seen it, so I'm not capable of commenting on it. Compared to Richard Monson-Hafael (see JAX-RPC is Bad, Bad, Bad!), I'm not even concerned overmuch about the handler chain, which I see as the proper way to manage the layered WS-specs.

What I don't get is the deployment model.

Look. Everyone knows EJB 1.0 sucked. Mention using ejbc to anyone with any experience with anything else and you'll get laughed at. Why? Because the extra compilation step was STUPID. In fact, I'll do something I've never done before and say it even more strongly: the extra compilation step was STUPPID, an appelation I've used only once before, when referring to a fellow who got his nose bitten off by his own dog.

I don't know of a clearer way to say "don't use this API" than to introduce an extra compilation step. I'll pretend you AspectJ and XDoclet people aren't reading this, or if you are, I'm sure you just wrote me off as a crank. But it's true: add ejbc or any other interferon into the deployment step and your tool sucks.

Thankfully, EJB 1.1 corrected things and moved processing where it belonged: the application server's deployment step. That's when EJB turned into something that ordinary dorks like you or I would be willing to use. If you're one of the unordinary dorks who enjoyed EJB 1.0's deployment cycle, go back in your cave. Your mushrooms are waiting.

But... but.... but people learned. Retards went out and invented SQLJ, not a horrible idea in its original thinking but the precompiler was back. Nothing like the taste of C in a language that eschewed C's compiler phases... except programmers were more wise this time 'round and stayed away in droves.

Well, SQLJ failed, for all intents and purposes, but no... XDoclet revived the preprocessor. AspectJ continues to carry the banner. And...

Yes...

JAX-RPC has it, too. Three minutes to deploy a web service? Two minutes, 59 seconds too long.

Deploying a service should be so complex as TWO ANNOTATIONS. That's it. The class should have @endpoint. The exposed methods should have @remote.

Containers should be able to do that. No dumb wsdeploy required.

JAX-RPC is ignoring its potential users. And why? I don't know. Maybe it's because they're STUPPID. RMH is a great guy, I'm sure, but he's wrong: the mapping of JAX-RPC/JAX-WS to the web services stack, with a set of handlers, isn't the problem. It's how you use the handlers that's the problem, along with a complete and fundamental lack of clear and understandable evangelism about how you, like, use the technology. It's frustrating, because they're so close to being able to simply tool the entire process, and make it everything it should be - i.e., easy, and working - yet nobody seems willing to contemplate getting there.