Strange behavior: WCF Adapter/Web Service/Maps/elementFormDefault/Client issue…

Hello,

I’m testing a messaging only scenario using the WCF adapter and four schemas.  The messaging scenario is as follows:

1. A WCF service created by publishing a schema using the BizTalk WCF publishing wizard.  The service is hosted in IIS and is published using schema A (request) and schema B (response).
    
2. A request-response receive location setup for WCF-CustomIsolated and the XMLReceive (recv) and PassThru (send) pipelines.  The address points to the published service.
    
3. A request-response send port with a filter that creates a subscription for messages received from the receive port above.  The send port is configured with a custom pipeline component that creates a SOAP header and attaches it to the outgoing message context for the WCF adapter to use.  The receive portion of the port is configured with the built-in XMLReceive pipeline.

   The send port is configured with an incoming and an outgoing map.
    

4. Four schemas, schema A, B, C, and D.  Schemas A & B are used to publish the WCF service and schema C & D represent the message types used by the send port to invoke a remote web service.  All schemas have the elementFormDefault attribute set to “qualified”.
    
5. A client that was created using “Add Service Reference” and pointed to the published BizTalk WCF endpoint.

For sake of clarity, I’ve simplified the XML instances below:

Instance of Schema A:

<Validate xmlns=”urn:namespaceA”>
  <Data>
    <X>1</X>
    <Y>2</Y>
  </Data>
</Validate>

Instance of Schema B:

<ValidateResponse xmlns=”urn:namespaceA”>
  <MessageId>123</MessageId>
</ValidateResponse>

Instance of Schema C:

<SendMessage xmlns=”urn:namespaceB”>
  <any>
</SendMessage>

Instance of Schema D:

<SendMessageResponse xmlns=”urn:namespaceB”>
  <MessageId>123</MessageId>
</SendMessageResponse>

I’m having a strange problem in that the response from the published Web service is not being deserialized properly.  On the wire, the response message from BizTalk looks like this:

<ns0:ValidateResponse xmlns:ns0=”urn:namespaceA”>
  <MessageId>123</MessageId>
</ns0:ValidateResponse>

This appears to be an invalid message because the MessageId node should be qualified with “ns0”.  The ValidateResponse object instance is generated, but the MessageId property is null instead of “123”.  So the client code is expecting one of the following:

<ns0:ValidateResponse xmlns:ns0=”urn:namespaceA”>
  <ns0:MessageId>123</ns0:MessageId>
</ns0:ValidateResponse>

OR

<ValidateResponse xmlns=”urn:namespaceA”>
  <MessageId>123</MessageId>
</ValidateResponse>

The ValidateResponse instance is generated by the incoming map on the send port.  This map copies the MessageId node of Schema D (that represents the response from the remote Web service) and maps it to the MessageId node of Schema B (ValidateResponse):

<xsl:stylesheet xmlns:ns0=”urn:namespaceA” …>
  <xsl:output omit-xml-declaration=”yes” method=”xml” version=”1.0″ />
  <xsl:template match=”/”>
    <xsl:apply-templates select=”/s0:SendMessageResponse” />
  </xsl:template>
  <xsl:template match=”/s0:SendMessageResponse”>
    <ns0:ValidateResponse>
      <ns0:MessageId>
        <xsl:value-of select=”s0:MessageId/text()” />
      </ns0:MessageId>
    </ns0:ValidateResponse>
  </xsl:template>
</xsl:stylesheet>

This map should result in one of the correct instance documents mentioned above.  Unfortunately, this doesn’t appear to be the case and it is driving me insane.  Using a send port to subscribe to messages of type “urn:namespaceA#ValidateResponse”, I can see that the document that comes out of send port (after being mapped) is the incorrect form:

<ns0:ValidateResponse xmlns:ns0=”urn:namespaceA”>
  <MessageId>123</MessageId>
</ns0:ValidateResponse>

The client is obviously unable to deserialize the MessageId element correctly using this instance because MessageId is incorrectly in the default empty namespace, instead of “urn:namespaceA”.  I’m not sure why this is happening.  When I validate and test the map in VS2005, I get the correct output, but at runtime I’m seing the incorrect result above.  I have redeployed the artifacts and even restarted IIS and BizTalk, but no luck.

The only way I can seem to fix this is either by using [XmlElement(Form = XmlSchemaForm.Unqualified)] on the ValidateResponse/MessageId property in the client reference or by changing my schemas to use elementFormDefault = “unqualified”, neither of which is really an acceptable solution. 

Does anyone have any idea of what the problem might be or what I should look at?