|
|
Contract in SO：Contract是对操作和数据的抽象
在我们看来，Service Orientation提供了一种对业务、功能进行分解的方式。针对SO，我们把一个具体的业务流程或者一个复杂的功能分解成一个个独立完成某项任务的子单元，这些子单元通过一个个Service来承载。对于Service本身来讲，他们应该是自治的，独自完成自己的功能、不依赖于其他的Service。但是Service的价值体现在它被潜在的消费者使用的程度。这实际上包含两方面的内容，作为Service本身，它如何将自己暴露出来，供一切可能的潜在用户调用，这些潜在用户不仅仅指那些不同的Client，也包含其他的Service：Service Orientation其中一个特征就是“Service should be composite”,鼓励将一个个相关细粒度的Service组合成一个大的Service。这样有利于较大限度的实现重用，而重用往往意味着更小的投入、更佳的可维护性。而另一方面就是这些消费者通过怎样的方式来调用它所需要的Service。
这实际上体现了两者相互交互的问题。在一个分布式的环境中要实现两者的交互，有两个必须要解决的问题：如何保证Service的使用者对Service的调用能够被Service端理解，以及对Service的调用如何抵达Service Side。后者实质上是关于communication的问题，我们现在不去谈它。第一个问题就是Contract需要解决的问题。
我们知道SOA一个主要的目标就是促进不同技术平台的互操作，要真正实现这样一个宏伟的目标是一件极不容易的事情，需要不同的厂商和标准组织相互协作，制定一个大家一致遵循的标准。这样一个标准就是WS-* 。我们很清楚，无论个个厂商各自的标准怎样千差万别，但是有个标准是他们必须要遵循的，那就是InterNET的标准，如果哪家公司拒绝InterNET，那肯定要被淘汰的。而对于InterNET，基于Http的网络协议和基于XML的数据表达已经成为了事实上的标准。对于SOA来说，XML不仅仅用于表示Service调用携带的数据（参数和返回值），更用于表示这个调用本身，以及满足各种要求的控制信息, 比如基于Security、Session、Reliable Messaging、Transaction等等的控制信息。WS-*就是一个基于XML的标准。而对于SOA中的Contract所要做的就是寻求一种厂商中立的方式来表示Service的接口、和用于交互的数据结构。前者就是Service Contract、后者就是Data Contract。
SOA中的一个Service由一组相关的Operation来构成。Service Contract用于表示构成该Service所有Operation的Interface（而不是Implementation）。说得更加具体点，大家都知道Consumer和Service之间的交互都是通过Message的形式来实现的，一次交互就是一次Message Exchange。在不同的场景，我们以不通过Pattern来进程Message Exchange，比如我们通常使用Request-Response的方式来向Service发送Request进而得到返回结果，我们也可以以Request-Forget的形式来异步地调用Service（不需要从Service获取Response），我们可以让一个Service在没有收到任何Request的情况下，以广播的形式向注册的Client发送通知，当然我们还有其他不同的消息交互的模式，我们把这些不同的信息交互方式称为MEP（Message Exchange Pattern）。也就是说，一个Operation最终通过被最终转换成了按照某种MEP进行的消息交互，而Service Contract旨在实现对这种MEP的描述，比如是否需要Request Message或者Response Message（如果仅仅有Response Message就是Notification的方式；如果仅仅具有Request Message,那就是我们上面谈到的Request-Forget的模式），和Message本身具有的格式。
上面我们说了Service Contract是以一种厂商中立的形式描述体现为某种模式的消极交互、构成整个Service的所有Operation。而我们也说了Consumer和Service的交互本质上看就是按照某种Pattern体现的一次Message Exchange，好像具有了Service Contract的描述就可以了。但是实际上，单单有了Service Contract对Service的描述还不够，因为Service Contract本身缺乏对携带于Message，用于信息传递的数据类型的描述，而这是Data Contract需要解决的问题。我们知道不同的技术平台对数据类型的表示是不一样的，可能某一种技术平台使用16bit来表述一个浮点数，另一种则使用32bit。所以要想实现不同技术平台的互操作，将不同技术平台同一类型的数据以一种厂商中立的形式来描述是必须的。
概括的说，SOA中的Service Contract和Data Contract就是一种厂商中立的数据呈现方式对Service Interface和Data Type的。而Service的调用都是通过SOAP Message来实现，SOAP是基于XML，而对于XML结构的定义，我们很自然地想到XSD，我们可简单地将SOA中的Contract看成是一个XSD。
Contract in WCF
上面我们实际上是在一个厂商中立的前提下探讨Contract，这里的Contract和具体的平台和技术无关。接下来我们要谈的是基于技术的话题：讨论一下WCF下的Contract。简单地说，WCF中的Contract主要的功能就是如何将一个基于.NET的CLR Type，Interface或者Class，转化成一个我们上面提到的Neutral Contract。比如，如果我们在一个Interface和它的成员上分别运用Service Contract Attribute和Operation Contract，当我们Host实现了该Interface的Service的时候，WCF就能将在一个.NET-specific的CLR Type暴露成一个Neutral Service Contract。同理对于一个，我们通过在一个Class和它的成员上分别添加DataContractAttribute和DataMemberAttribute，就可以就该CLR Type转变成Neutral Data Contract。
比如我们一个运用了DataContractAttribute和DataMemberAttribute的Order class：
namespace Artech.DataContractVersioning.Service
{
[DataContract(Namespace="http://artech.datacontractversioning")] public class Order 
{
[DataMember(Order = 0)] public Guid OrderID {get;set;} [DataMember(Order = 1)] public DateTime OrderDate { get; set; } [DataMember(Order = 2)] public Guid SupplierID { get; set; }
}
}Data Contract Mapping Mechanism
通过上面的介绍，我们发现WCF Data Contract就如同一个适配器，弥合了 CLR Type和Neutral Contract的差异，很容易地实现了他们之间的匹配。接下来，我们就以一个实际的例子来介绍WCF DataContract的这种适配功能：通过DataContractAttribute的修饰，实现了将一个现有Data Type向一个既定的Neutral Data Contract进行适配，从而实现了对基于该Neutral Data Contract的Service 进行正常调用的目的。
我们就以上面提到的Order Class为例，Service端的Order class最终暴露成一个以XSD表示的Neutral Contract：
Order class：
namespace Artech.DataContractVersioning.Service{ [DataContract(Namespace="http://artech.datacontractversioning")] public class Order { [DataMember(Order = 0)] public Guid OrderID {get;set;} [DataMember(Order = 1)] public DateTime OrderDate { get; set; } [DataMember(Order = 2)] public Guid SupplierID { get; set; } }} NET技术：[原创]谈谈WCF中的Data Contract （1）：Data Contract Overview，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
