Code First Conundrum

... or another more apt title is "Why on earth is ASP.NET still producing .wsdl files with soap encoding".

Here's the scenario - out in the world of a fledgling SOA architecture that is currently .NET based, there is a SOAP web service published for consumption. This particular SOAP service was created using Microsoft ASMX in ASP.NET 2.0 - which implies that the web service features a .wsdl that is code-first generated from a .NET interface. Our application is Java based and is using Apache CXF to perform compile time binding against the web service. Immediately upon trying to consume the wsdl as published from CXF for compile time code generation and binding using wsdl2java, we get this error message:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Thrown by JAXB : undefined simple or complex type 'soapenc:Array'

Here's the lovely piece of generated SOAP goodness that's responsible for said parsing problem:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
      <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
      <s:complexType name="StringArray">
        <s:complexContent mixed="false">
          <s:restriction base="soapenc:Array">
            <s:sequence>
              <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
            </s:sequence>
          </s:restriction>
        </s:complexContent>
      </s:complexType>
    </s:schema>

A colleague and I both start researching why on earth this is. He discovers the quick fix, which is manually replacing the soap encoding Array type with the more familiar sequence element in the wsdl as follows

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
      <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
      <s:complexType name="StringArray">
            <s:sequence>
              <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
            </s:sequence>
      </s:complexType>
    </s:schema>

I went off trying to discover why on earth .NET 2.0 ASMX is producing this in the first place and why wsdl2java was barfing when it encountered it. As it turns out, JAX-WS (which CXF is an implementation of) doesn't support soap encoding or soap rpc any longer. This is apparently for good reason. Do you want proof? Well, here's an explanation as to why soap encoding is bad and should be moved away from entirely written in the year 2000 by the company whose flagship web framework still produces it by default in a version that was released in 2005. Unfortunately, I never did discover the answer as to why .NET produces this or how to disable it, if at all. The documentation on ASMX on MSDN was pretty sparse and no annotations in the .asmx in file seemed obvious candidates for tweaking to make this go away.

If anyone has any ideas, let me know. In the meantime, we'll maintain our own copy of the .wsdl without the soap encoding cruft so work can actually get done.