为什么WCF将请求/响应类型包装在另一个XML元素中，以及如何防止这种情况? [英] Why does WCF wrap request/response types in another XML element, and how to prevent this?

问题描述

我有一个简单的echo服务，其中定义了一个操作方法和一对用于请求/响应的类型:

I have a simple echo service where I've defined one operation method and a pair of types for request/response:

[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()会产生:

Invoking Message.CreateMessage() on an instance of EchoRequest yields:

  <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元素中，如下所示:

...which is exactly what I want. However, it appears that the service is expecting the message body to be further wrapped in another XML element, like this:

  <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".

UPDATE: Thanks to Mark's reply, I've explored MessageContract instead of DataContract on the request/response types. This seems closer to what I want, but now it's going too far, and not expecting the outer type element, "EchoRequest".

这令人迷惑，因为Message.CreateMessage似乎以某种方式无法正确地生成正确的XML，因此显然使用了一些默认的序列化，我想将其配置为接受该服务.我只是误解了Message.CreateMessage的工作原理吗?

This is confusing since somehow Message.CreateMessage appears to unfailingly produce the correct XML, so it's apparently using some default serialization which I'd like to configure the service to accept. Am I just misunderstanding how Message.CreateMessage works?

推荐答案

我最终切换到使用消息合同，使用 TypedMessageConverter ，我是通过这个问题介绍的答案.那是这里缺少的一块.

I eventually switched over to use Message Contracts using a TypedMessageConverter which I was introduced to via this question's answer. That was the missing piece here.

这篇关于为什么WCF将请求/响应类型包装在另一个XML元素中，以及如何防止这种情况?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！