Bouche Paul wrote:
...portions elided...
I personally think, ... that when we have to "hack" WSDL in order to get interoperability then something is wrong
I understand this point of view and how you feel that the suggested method of generating a WSDL with a tool and then manually modifying parts to make it interoperable implies a broken tool. That may be.
I believe the *real* proposed solution is to consider your WSDL contract as a first class artifact of you web service instead of an afterthought. WSDL is the IDL of your service and if that means something to you you are probably familiar with the fact that "ContractFirst" isn't new.
As a practical matter WSDL 1.1 can be somewhat unapproachable - too many angle brackets, too much cryptic syntax or funky/non-obvious semantics, I don't know. Whatever it is it makes most people NOT look forward to authoring it. To me this is tremendously unfortunate since plenty of people consider writing IDL first obvious and necessary. This is how we get to the "generate a WSDL to start with" philosophy. Once you have the boilerplate parts and a rough outline of the types you need you can then tweak the non-interoperable parts to get a nice clean WSDL.
Does this mean Java2WSDL is broken? Maybe, but to my way of thinking about it I wouldn't expect such a tool to exist in the first place. :-) Although I have to admit the idea is seductive.
The type contract that is the basis for your service should be authored in the XML type system not in the java type system - thats the fundamental problem. As we continue to insist on mapping everyone else world to our own we will continue to have interop problems. To be fair much of the the deep thinking has been done here and the non-interoperable parts are due in large part to (pervasive) legacy toolkits that are based on deprecated technology and of course plain old bugs.
Some people suspect a somewhat dark angle here too. That platform vendors are dis-incented to make their toolkits *really* interop so if you end up making a service using toolkit A the "best" consumer is a client using toolkit A as well. This is really unfortunate in as far as it happens but in my experience this hasn't been the case. In fact, without naming names, those that you think would pull these sort of stunts have been most interested in interop - from the start.
(Opening can labeled "Worms")
There are other problems with ignoring WSDL as well - like versioning. If your WSDL is being generated from you Java classes dynamically will you know when your contract changes? Will you know what parts of your contract change and whether older style messages are still safe to process?
Jim Murphy Mindreef, Inc.
