Freigeben über

Using the WSDL-First design approach with WCF services

  • Artikel

Couple of helpful posts from the archives for you. 

If you are care about interop, then you probably want to use a contract-first or WSDL-first design for your web services.  In other words, you will not simply decorate server-side code annotations (in Java) or attributes (in .NET) and generate WSDL dynamically from that running code.  That approach works in demonstrations, but it does not lend itself to good interoperability in the long run.

So you start with WSDL.  Since you are WCF-savvy, you are confining yourself to the subset of XML Schema that is friendly to WCF.  The restriction isn't too onerous, though, especially as it improves interoperability significantly, and also simplifies your life since you don't have to read and understand all of the XML Schema spec!  Ok, so following those rules, you write the WSDL. And then you generate from that WSDL the server-side stub code, and the client-side proxy code, using the web services toolkits of your choice.  On the .NET side, that toolkit is obviously WCF (and the tool itself is svcutil.exe); on the Java side, maybe the JAXWS reference implementation, or AXIS2, and so on.  But the trick is, the generated code on the .NET side is muy bueno if you write your WSDL following a few additional simple rules, which are not mentioned in the above linked doc.

For example, if you want to pass a collection in your interface, and you will be using WCF on one or both ends of the wire, then you want to use an explicit complexType for the array in the WSDL/XSD.  This is not required by WSI Basic Profile, nor is it mentioned anywhere in the official WCF doc as far as I know.  Nonetheless, follow this rule for best results.   Do not define your arrays with an element and a @maxOccurs="unbounded" attribute in your schema; if you do, you will get the XmlSerializer with WCF, rather than the DataContract serializer, and that is probably not what you want.  More on this tip here.

Also, use only one part in each wsdl:message (to comply with WS-I Basic Profile) and set the message part attribute @name = "parameters" to make the messages document/literal wrapped, versus bare.  If you're not sure, you want wrapped.

Finally, another tip: when using collections in service interfaces (or more specifically, data contracts), you can use the svcutil.exe tool to specify that collections be represented in the generated .NET code as one of the Generic collection types, rather than a vanilla array.  This is done with the /collectionType option on the svcutil.exe command line.  See this post for more detail on that idea.

I think there might be a similar codegen hint on other web services toolkits but I could not find the right switch on AXIS2.

Comments