为什么WCF将请求/响应类型包装在另一个XML元素中,以及如何防止这种情况？

Question

我有一个简单的echo服务,我已经为请求/响应定义了一个操作方法和一对类型:

[ServiceContract(Name = "EchoService", 
                 Namespace = "http://example.com/services", 
                 SessionMode = SessionMode.NotAllowed)]
public interface IEchoService
{
    [OperationContract(IsOneWay = false,
                       Action = "http://example.com/services/EchoService/Echo", 
                       ReplyAction = "http://example.com/services/EchoService/EchoResponse")]
    EchoResponse Echo(EchoRequest value);
}

数据类型:

[Serializable]
[DataContract(Namespace = "http://example.com/services/EchoService", 
              Name = "EchoRequest")]
public class EchoRequest
{
    public EchoRequest() { }

    public EchoRequest(String value)
    {
        Value = value;
    }

    [DataMember]
    public String Value { get; set; }
}

[Serializable]
[DataContract(Namespace = "http://example.com/services/EchoService", 
              Name = "EchoResponse")]
public class EchoResponse
{
    public EchoResponse() { }

    public EchoResponse(String value)
    {
        Value = value;
    }

    [DataMember]
    public String Value { get; set; }
}

在EchoRequest实例上调用Message.CreateMessage()会产生:

  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header />
    <s:Body>
      <EchoRequest xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://example.com/services/EchoService">
        <Value>hello, world!</Value>
      </EchoRequest>
    </s:Body>
  </s:Envelope>

......这正是我想要的.但是,似乎服务期望消息体进一步包装在另一个XML元素中,如下所示:

  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header />
    <s:Body>
      <Echo xmlns="http://example.com/services">
        <EchoRequest xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://example.com/services/EchoService">
          <Value>hello, world!</Value>
        </EchoRequest>
      </Echo>
    </s:Body>
  </s:Envelope>

更新: 感谢Mark的回复,我在请求/响应类型上探索了MessageContract而不是DataContract.这似乎更接近我想要的,但现在它太过分了,并没有期待外部类型元素"EchoRequest".

这是令人困惑的,因为某种程度上Message.CreateMessage似乎可靠地生成正确的XML,因此它显然使用了一些我希望配置服务接受的默认序列化.我只是误解了Message.CreateMessage的工作原理吗？

Answer 1

我最终转而使用使用TypedMessageConverter 的消息合约，我是通过这个问题的答案介绍的。这就是这里缺失的部分。