>You are advocating an approach that builds Java language specific types >first and generating WSDL + Schema from them, using a SOAP platform specific >WSDL emitter. Not everyone is sold on this approach, given that the >different SOAP platforms on the market right now all have a) differing >levels of support for W3C XML Schema and b) different approaches to the XML >data binding problem. > >A Java class run through a particular SOAP platform's presto-magic WSDL + >Schema generator a la Java2WSDL might not generate the same WSDL + Schema >when run through another platform's WSDL + Schema generator.
However, given the general programming principle of DRY (Don't Repeat Yourself), and given the general mantra of "WSDL is for Tools", it seems to me that there has to be some middle ground here. What would be ideal would be a standard (hopefully JCP-defined, or perhaps W3C-defined) for converting JDK-1.5-attribute-enhanced Java classes to *standard* WSDL. Then it would be possible to write Java code, with JDK 1.5 attributes, to WSDL which would be assimilatable by any standard-conforming SOAP implementation in any language. The alternative is to have to maintain two representations of your interface and types: your WSDL representation, and your Java representation. This kind of duplication is exactly what systems such as XDoclet, Java attributes, C# attributes, etc., were designed to avoid. >Dennis Sosnoski (www.sosnoski.com), a long-time XML deep thinker, first >turned me onto the XML data binding "problem" with his excellent articles >(4 >parts) on the issues over at IBM developerWorks. > >http://www-106.ibm.com/developerworks/library/x-databdopt/index.html I will dig into this -- probably shouldn't even respond until I do :-) >A SOAP service implemented on one Java platform today is simply not portable >to another Java platform - and that is indeed a sad state of affairs. It seems from your post that even if you *do* maintain your WSDL by hand, you are still pretty far from having a portably accessible SOAP service, aren't you? Given that each different Java SOAP platform will generate different Java bindings from your WSDL, you still don't necessarily have consistent interoperability. What's missing, it seems to me, is a canonical and sufficiently rich standardization of how Java and WSDL are coupled. Similarly, such a standard binding should exist for C#, Perl, etc., and should be compatible with the Java/WSDL binding. We are definitely moving in that direction and the momentum will continue; it just will take a lot longer given the number of players involved. It looks to me as though Microsoft, with Indigo, is end-running the whole interoperability problem by simply charging into a fully attribute-oriented service architecture, focusing on interoperability with themselves only. Personally I'd love to see Axis take the lead on doing a similar structure for Java, integrating JDK 1.5 metadata with a really robust Java2WSDL2Java toolset. Interop with others is important but having a good self-consistent end-to-end stack in your own world is equally (maybe more?!) important. Axis 1.2 is moving in that direction but as we all know it's not there yet. I hope I can get my company to move towards web services, so I can revive my defunct Axis-committer nature and really help out with this! Cheers! Rob
