Screaming Penguin

I will go on record saying I am a big fan of the JAX-WS stuff (*and* the core concepts of start from a java class and "burn" a service). A new quick tutorial using Glassfish is available on JAX-WS at java.net: Web Services Made Easy with JAX-WS 2.0 Even though I personally like the stuff some people seem to disagree and think JAX-WS Sucks! ("subject matter experts" who write books like "The Ultimate Guide to J2EE Web Services" even) but I say not so fast there fancy French hyphen-name guy. The original article about JAX-WS sucking basically said (paraphrasing but please correct me if you think I am wrong) that it was "bad bad bad!" because it was "too complicated" and had "too many annotations". Those are pretty broad reasons to say you dont like something, rather than specifics that might back up saying it "sucks" but alas they are reasons. The follow up article (aforelinked) elaborated a bit more and used real world examples associated with using eBay, Google and Amazon services and JAX-WS as a *client*. This is the first problem I have with this "analysis", its going at things from the client side and thats not really the main point of JAX-WS (sure its important, but once you HAVE a service you can generate a client any number of ways). The main point of JAX-WS is arguably in creating services themselves (you know, the whole annotation thing that was the problem in the first article). In few of the examples the author had issues getting wsimport to generate clients successfully at all due to various incompatibilities. In some cases this was understood and the author admitted that the server side implementation had issues (Google and SOAP Encoding for example) but still this is an area where wsimport simply needs to get better. Then the clients that did generate got bashed for being, wait for it, too complex. There were "too many classes" and "no documentation". That is again not the fault of JAX-WS (the spec or the implementation). The generated client is based on the service side implementation (this goes without saying but I said it anyway) and how complex the client ends up being in terms of number of types and classes is of course directly related to how the service was implemented (what the WSDL looks like). As for documentation, well its *generated* code, not sure exactly what one might expect there. Generally the interface which gets built into a service and resulting WSDL should not be so complex that it requires hundreds of classes and is not intuitive to use - agreed - but again that is not related to what wsimport comes up with for a client (especially not documentation). Once the client is generated and you have "too many classes" you are working from pure Java and that is in my book pretty easy and quite nice, rather than sucky, even if it entails a "lot" of classes. Either way (whether or not you think a 200 class client sucks because of the fact that is has 200 classes) you cannot reasonably blame JAX-WS for these "issues". Overall I personally find JAX-WS to be very easy to use but I have been going at if from a server side 'create a service' standpoint rather than generating clients. I think with the reasonable expectation when using JAX-WS that if a wsimport based client does show up its going to be a *generated* non documented client representative of the WSDL it was generated from (imagine that) users might have a different opinion, such as I do, as to whether or not JAX-WS "sucks". (I will admit that I need to try some more wsimport stuff. Really I should just try the same services the author of the "sucks" articles tried and see how complicated it really is. I will try to do that and then follow up here. In the past I have written only a few services with JAX-WS but found it really easy and it worked. I typically still generate clients with an ant script and "wsdl2java" but admit thats not JEE 5 vogue, though it works, I vow to start using wsimport - maybe that will change my opinion of this, but again with reasonable expectations I doubt it.)