|
|
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，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
