You are touching on an interesting and deep running debate, my friend. In order to build a SOAP service, should you be modeling the data types that you wish to exchange (the message payloads) in your native object oriented programming language (Java, C#, etc) or in your XML schema? Modeling the data types in the XML Schema first is generally considered a sound approach to SOAP service implementation when a) cross SOAP platform service interoperability and b) cross SOAP platform service portability issues are concerns. Hence the focus on hand crafted XML Schema and WSDL.
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. The converse is also true - WSDL + Schema run through a particular SOAP platform's XML -> OO binding generator (WSDL2Java or the .Net equivalent WSDL.exe) will most certainly generate different service implementation skeletons/XML schema bindings/service deployment descriptors than another SOAP platform's equivalent tool. 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 These issues are extremely relevant to WS-I compliant document/literal SOAP service design and implementation, given that current SOAP platforms (Axis, webMethods GLUE, Cape Clear, BEA Weblogic, Systinet WASP, Microsoft .Net) all approach the XML data binding problem differently, given that no J2EE specification currently mandates one particular approach (even JAX-RPC 2.0's usage of JAXB 2.0 as its default data binding API will probably be overridable). 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. Regards, Jonathan Anderson Booz Allen Hamilton -----Original Message----- From: Yakulis, Ross (Ross) [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 5:35 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design Note, that while Axis cannot currently generate this wsdl file, the WSDL2Java in Axis will consume the wsdl. This seems more painless that the other documented process. Ross -----Original Message----- From: Yakulis, Ross (Ross) Sent: Wednesday, April 14, 2004 1:43 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design It can be eaiser. Download the Systinet developer tools for eclipse. Given the .java file it generated a doc/literal wsdl. Ross -----Original Message----- From: Nelson Minar [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design >David, you may be understating the problem a bit. Building interoperable, >WS-I compliant SOAP services with Axis is a little involved. Yeah, a little too involved. Shouldn't this be easier? No specific criticism of Axis intended. I'm just amazed at how much effort I'm going through to pass arrays of numbers around.
