Wsdl validation

ServiceStack
1

I need to build a service supporting REST/JSON and SOAP12 as well. I followed all wiki-guidelines concering SOAP and so far I’m able to accomplish the following:

  • Service methods support DTO sent in any format
  • WSDL auto-generated (metadata page) can be consumed using soapui, scvutil(MS proxy generator), cxf(apache-cxf-3.0.4)

I squeezed all types within the same NS(acme.org) using HostConfig.WsdlServiceNamespace and I mapped all ClrNamespaces to the same NS using the [assembly: ContractNamespace…] approach.
So far so good.

Problems:

  • when apache-cxf-3.0.4 try to validate the wsdl returns that error(if I skip the validation, proxy will be generated with no problem):

WSDLToJava Error: Schema Error : src-import.1.1: The namespace attribute ‘http://acme.org/myservice/types’ of an element information item must not be the same as the targetNamespace of the schema it exists in.

I assume it refers to following wsdl section

    <wsdl:types>
    ...
    <xs:schema xmlns:tns="http://acme.org/myservice/types" elementFormDefault="qualified" targetNamespace="http://acme.org/myservice/types" xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:import namespace="http://acme.org/myservice/types" />
      <xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays" />
      <xs:complexType name="MyOperation1">
  ...

Reading this post seems should be used xs:include insted of xs:import.

What are your thoughts on this matter?

Thanks a lot to build a great product!

2

The generated WSDL follows WCF’s flavor of SOAP where the XSD <xs:import statements are generated by .NET’s XsdDataContractExporter and can’t be changed.

You can also try using the default http://schemas.servicestack.net/types namespace for all DTO types instead to see if that passes apache cxf validation, otherwise you’d have to go with apache validation turned off.

3

Hi Demis,
I assume squeezing all types within the default NS pass the validation due to all types will end up in the same wsdl schema , but that’s not an option: we do need a custom/company NameSpace.

Do you aggree that xs:include should be used instead of xs:import? If so, do you think that change could be included in a further release?

Thanks a lot.

4

Please re-read my previous comment:

i.e. the generated import statements are hard-coded into WCF’s XsdDataContractExporter which is the style of SOAP the generated WSDL’s are optimized for.

But there is an opportunity to modify the generated WSDL by overriding GenerateWsdl() method in your AppHost, e.g:

public override string GenerateWsdl(WsdlTemplateBase wsdlTemplate)
{
    var wsdl = base.GenerateWsdl(wsdlTemplate);
    wsdl = wsdl.Replace("<xs:import", "<xs:include");
    return wsdl;
}
5

Awesome!
Sorry I thought XsdDataContractExporter was a buit-in SS type/implementation.
GenerateWsdl allows me to do also other customizations requested by our consumers…