JAX-WS 3.0 Wish List

JAX-WS is a good effort. It's much better compared to JAX-RPC , it's much more flexible, and one can use it to write all types of services. Granted, it's used most of the times for building Plain Old RPC SOAP Services (PORSS :-)), but it does have good features and it relies on all those cool Java things like annotations, generics and Executors.

JAX-WS is quite widespread but there's also a new kid on the block out there, JAX-RS. At Sun, JAX-WS and JAX-RS are implemented in two different projects. There's also a clear indication that future runtimes will attempt to combine the best out of all worlds, they'll try to catch two rabbits at the same time, if you wish.

So I'm curious what the future holds for JAX-WS ? Will it survive ? Or will we see a single JAX specification only in some time ? Whatever the future for JAX-WS holds, here's a wish list for its version 3.0 (if it ever happens to come to live) :

1. Deprecate Java-first web-services development. Yea, developers like it, things like annotations are so appealing. There's a catch though. It just does not work. Do you blame WSDL for the perceived interoperability issues of Web Services ? Nope, huge WSDLs are just partly to blame. It's that code-first development which makes it so easy for developers to quickly come up with a web service and send around that byte[] array or that List or Map.

By the way, I think I've seen proposals to quickly generate a WADL contract out of your code, sounds familiar, doesn't it ?

Code-first web services development is evil which many people have talked about before.
Well, ServiceContract-first development is not exactly a very pleasant experience either but it's better nonetheless. Policy-First Development which I'll chat about later will make it easier. Tools like Artix Registry/Repository are doing it (briefly referring to IONA's offering here) and it's going to blow away the code-first development and make it easier to deal with WSDL and indeed WADL contracts.

2. Deprecate doc-literal-wrapped. This one is a strong opponent. It helps you to create little nice-looking signatures completely shielding you from the reality that it's an implementation of the web service which you're dealing with :

int doIt(int x, int y);

It's nice, isn't it ?

The only problem that as soon as you add an ignorable property to the type which have been unwrapped all the signatures break. This is actually a problem of the code-generation, not that of web services. Sometimes this is exactly what people want. But there's a better way to control the change, just don't add extensibility points into your schema thus ensuring the validation will fail. Either way, the signatures should always be something like :

ComplexTypeReturn doIt(ComplexTypeRequest in);

This way one can control the change much better. More on it later, on the code generation for client runtimes and on 'must ignore'.
I'm wondering, when a WADL contract will be used to generate the code, will Sun come up with the schema design pattern which will do the same thing doc-literal-wrapped does ?