设计SOA WCF Web服务时的最佳实践是什么？

给定运营合同,例如:

[OperationContract]
void Operation(string param1, string param2, int param3);

这可以重新设计为:

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

我喜欢MessageContract的一件事是我对SOAP消息的格式有了更明确的控制.

同样,我可以编写几乎相同的代码,但使用DataContract:

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

我喜欢DataContract的一件事是我可以定义IsRequired,Order和Name.

今天我希望唯一的消费者将成为WCF客户端.但是,我想首先设计合同并尽可能地遵守SOA实践.我不希望WCF指示我的SOAP,WSDL和XSD,而是希望XML定义WCF层,但是使用WCF来生成它,以便不向WCF添加任何自定义消息处理.我想遵循最常见的SOA XML约定,我认为这些约定可能都是以小写字母开头的标签 - 我是对的吗？我希望尽可能地容忍版本.

总是创建像这样的请求和响应消息是明智的吗？这三种格式中的哪一种促进了最佳SOA实践？我是否应该更进一步定义DataContract和MessageContract,其中MessageContract只包含DataContract？或者,如果我真的暴露了一种新类型(即不创建消息类型作为容器),我应该只使用DataContracts吗？

我知道的一系列问题,但我试图找到它的核心,我不确定分离问题提供足够的背景来得到我正在寻找的答案.

它总是最好的做法,不要在操作契约中有多个参数,总是有一个包装所有必需参数的类型,从长远来看这将有所帮助.添加新的可选参数时,现有客户端不会中断.

我在一个业务集成团队工作,我们定期与其他公司(AT&T,Cox,Exxon ......)进行集成,并且从未见过带有多个参数的Web服务调用.

XML通常倾向于camelCased.WSDL和XMLSchema对元素和属性使用camelCasing,例如检查语法和模式.

为什么SOAP定义不同,我不知道,但它使用PascalCasing元素和camelCasing属性,请点击此处.

类似地,大多数WS*规范(可能全部)都使用PascalCasing作为元素和属性,请参见此处.XML Schema与它为XML定义的类型的约定无关.

Thomas Erl撰写了许多关于SOA"服务导向架构"的重要书籍.在第13章和第15章中,他提供了许多典型事务各部分的XML示例.它使用PascalCasing在XML Schema中定义类型和对象成员,它很好地匹配C#的常规模式,用于类和属性命名.因此,WCF默认值已经与标准非常接近.

关于实际的消息命名,一些约定使用camelCasing而其他约定使用PascalCasing,所以我的首选是匹配主要语言需求,在这种WCF情况下是PascalCasing.并且WCF默认值匹配应该如何写入请求和响应消息的一些示例,这里的一些示例.

因此,唯一突出的问题是现在的多少各地使用规范的基本问题OperationContract,DataContract和/或MessageContract.

只有当你有一个复杂的类型(用XSD说法)才有意义定义DataContract ,我倾向于认为特里指出的YAGNI(你不需要它)是正确的选择,但Erl似乎建议更多过程密集型版本,所以我仍然不确定使用最佳方法作为我的默认选择(问题的主要部分).