Interoperability Gotcha: "These members may not be derived"

@YaronNaveh

The following gotcha applies when the server is written in a Java framework (e.g. Axis) and the client is in .Net. When we "add service reference" in VS to create the client proxy from the wsdl we may get this error:

Custom tool error: Unable to import WebService/Schema. Unable to import binding 'SomeBinding'
from namespace 'http://SomeNamespace'. Unable to import operation 'myOpereration'.
These members may not be derived.

In order to understand what this means we need to take a look at some other (valid wsdl):

<s:element name="EchoString">
 <s:complexType>
  <s:sequence>
   <s:element minOccurs="0" maxOccurs="1" name="s" type="s:string"    />
  </s:sequence>
 </s:complexType>
</s:element>
...
<wsdl:message name="EchoStringSoapIn">
 <wsdl:part name="parameters" element="tns:EchoString" />
</wsdl:message>
...
<wsdl:portType name="SimpleServiceSoap">
 <wsdl:operation name="EchoString">
  <wsdl:input message="tns:EchoStringSoapIn" />
  <wsdl:output message="tns:EchoStringSoapOut" />
 </wsdl:operation>
</wsdl:portType>

This means that the EchoString operation accepts a message that looks like that:

<EchoString xmlns="...">
 <s>some string</s>
</EchoString>

We might expect the proxy class to look something like that:

string EchoString(EchoStringRequest req) {...}

class EchoStringRequest
{
  string s;
}

However the real proxy looks like this:

string EchoString(string s) {...}

Why?
The reason is that most wsdls use the "document/literal/wrapped" pattern. This means that the first element of the message ("EchoString" here) is just some wrapper that the user does not really care about. What our user cares about is the "s" parameter. So the proxy generated the more useful proxy.

But let's take a look at this schema:

<s:element name="EchoString" type="tns:SomeBaseType" />

<xs:complexType name="SomeBaseType">
  <xs:sequence>
   <xs:element name="inParent" type="xs:integer"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="SomeDerivedType">
  <xs:complexContent>
   <xs:extension base="tns:SomeBaseType">
    <xs:sequence>
     <xs:element name="inChild" type="xs:integer"/>
    </xs:sequence>
   </xs:extension>
  </xs:complexContent>
</xs:complexType>

Here the root element "EchoString" is not a dummy wrapper - it can take the form of a few types (since there is derivation). This means the proxy should not omit it.

So how does VS knows which proxy to create?

The answer is in the message definition in the wsdl:

<wsdl:message name="EchoStringSoapIn">
 <wsdl:part name="parameters" element="tns:EchoString" />
</wsdl:message>

Whenever the name of a part is "parameters" .Net assumed doc/lit/wrapped is used and generates the proxy accordingly. If even though the word "parameters" is used the wsdl is not doc/lit/wrapped (as in the last example) .Net may give us some error. Which error? You guessed correctly: "These members may not be derived". Now we can understand what the error means: .Net tries to omit the root element as it thinks doc/lit/wrapped is used. However this element cannot be removed since it is not dummy - it should be actively chosen by the user out of a few derived types.

Fix
The way to fix it is open the wsdl in a text editor and change the part name from "parameters" to "parameters1". Now .Net will know to generate a doc/lit/bare proxy. This means a new wrapper class will appear as the root parameter in the proxy. While this may be a little more tedious api, this will not have any affect on the wire format and the proxy is fully interoperable.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!