WS service with response elements not in the XSD

We are using .NET 4.x WCF to consume a JAX-WS service. The proxy generated from the WSDL and XSD by "Add Service Reference" produces code which can correctly call the service. The service response, however, uses a root element name which is not defined in the XSD. The proxy returns a null result, presumably because the element name wasn't recognized, so the rest of the response envelope is ignored.

The SOAP response looks like this. Notice the root element in the body is named txLife22814Type :

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" />
  <soapenv:Body>
     <ns3:txLife22814Type xmlns:ns3="http://ACORD.org/Standards/Life/2" xmlns:ns2="http://dtcc.com/lnapm/service/">
     <ns3:TXLife>
          ...snip...
    </ns3:TXLife>
    </ns3:txLife22814Type>
  </soapenv:Body>
</soapenv:Envelope>

The relevant portion of the XSD looks like this. Notice the root element is named Tx22814 and there is no txLife22814Type associated with the TXLife_22814_Type complexType:

<xs:schema xmlns="http://ACORD.org/Standards/Life/2" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://ACORD.org/Standards/Life/2" elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="Tx22814" type="TXLife_22814_Type"/>
    <xs:element name="Tx22815" type="TXLife_22815_Type"/>
    <xs:element name="Tx22816" type="TXLife_22816_Type"/>
    <xs:complexType name="TXLife_22814_Type">
        <xs:sequence>
            <xs:element name="TXLife" type="TXLife_IPT_Type"/>
        </xs:sequence>
    </xs:complexType>

The rest of the response matches the XSD just fine. (I have not posted the full WSDL and XSD as they are quite large, many hundreds of lines.)

On the sending side, the operation request takes this same type ( TXLife_22814_Type ) as an input parameter (actually it's a byref that is modified by the service), the WSDL for the call references the correct XSD name ( Tx22814 ), and it works.

I tried adding a second root to the XSD which maps to the same type:

    <xs:element name="txLife22814Type" type="TXLife_22814_Type"/>

This caused the request to fail, which surprised me. I wondered if WCF can't disambiguate the type, although I would expect the explicit use of the Tx22814 name in the WSDL should handle that. The WSDL (heavily edited for readability to show only the relevant operation) looks like this. The operation or "message" of interest here is isProducerTrainedRequest :

<wsdl:definitions ...snip... >
  <wsdl:types>
    <xsd:schema targetNamespace="http://dtcc.com/lnapm/service/">
      <xsd:import namespace="http://ACORD.org/Standards/Life/2" schemaLocation="DTCC_PM_ACCORD_V2.28.xsd"/>
      <xsd:element name="MessageHeader">
          ... snip ...
      </xsd:element>
    </xsd:schema>
  </wsdl:types>
  <wsdl:message name="isProducerTrainedRequest">
     <wsdl:part element="ns1:Tx22814" name="Tx22814"/>
  </wsdl:message>
  <wsdl:message name="isProducerTrainedResponse">
    <wsdl:part element="ns1:Tx22814" name="Tx22814Response"/> 
  </wsdl:message>

I wrote an AfterReceiveReply interceptor and did a string-replace on the mangled tag, and then the rest of the proxy works, but that is clearly a hack that we'd prefer to keep out of production code.

We do not own the service. The service providers do not have other .NET consumers. They claim all of their Java-based clients are not having a problem. (Maybe JAX-WS or Java in general assumes some sort of element name decoration? Or ignores it?)

Has anyone seen this? Does anyone have a solution? Is there maybe a way to decorate something in Reference.cs to either translate or map element names, or something along those lines? I am not a SOAP or XML expert; do I misunderstand something about SOAP and/or XSD element naming rules? Can the XSD be altered to satisfy both the request and response?

链接地址: http://www.djcxy.com/p/34304.html

上一篇: WCF中的SOAP响应

下一篇: 带有不在XSD中的响应元素的WS服务