0 comments
.NET 
In my current project we build WCF services that are called by Java middleware. The partner in this project developing the Java middleware is requesting flat WSDL’s (i.e. a WSDL for a service is a single file). WCF generates by default a WSDL with an xsd import element for each namespace that is different from the namespace of the operation and contains types used in these operations. When using svcutil.exe to download the metadata it stores these as seperate files.
This popular blogpost provides a very simple endpoint behavior to flatten your WSDL and it works like a charm! Note that the WsdlExporter has a property GeneratedWsdlDocuments which returns a ServiceDescriptionCollection. The catch here is that this is a collection System.Web.Services.ServiceDescription instead of System.ServiceModel.Description.ServiceDescription. It took me a while to figure that out.
Another problem to tackle was BizTalk. We have an orchestration in BizTalk server 2009 with a receive port that is published as a WCF service. The web.config of the generated service contains no endpoint to apply the endpoint behavior to. The solution was again quite easy: create a service behavior that can be applied in a WCF config file. Use the service behavior to apply the flat wsdl behavior to each endpoint in the description. Add the service behavior to the web.config of the generated WCF service and you’re done.
NB the code only works to replace imports of xsd schemas. When the WSDL is split over multiple files (because the binding namespace is different from the contract namespace for example) you still end up having two files.
PS if you are working with the Endeavour service framework you can use sfutil to generate a flat wsdl, but this wsdl does not contain an wsdl binding element. For WCF scenario’s this is no problem with it’s config approach for bindings, but for most interop scenario’s this information has to be known at compile time (or proxy-generate time).