Contract in SO：Contract是對操作和數(shù)據(jù)的抽象 

　　在我們看來，Service Orientation提供了一種對業(yè)務(wù)、功能進(jìn)行分解的方式。針對SO，我們把一個具體的業(yè)務(wù)流程或者一個復(fù)雜的功能分解成一個個獨立完成某項任務(wù)的子單元，這些子單元通過一個個Service來承載。對于Service本身來講，他們應(yīng)該是自治的，獨自完成自己的功能、不依賴于其他的Service。但是Service的價值體現(xiàn)在它被潛在的消費者使用的程度。這實際上包含兩方面的內(nèi)容，作為Service本身，它如何將自己暴露出來，供一切可能的潛在用戶調(diào)用，這些潛在用戶不僅僅指那些不同的Client，也包含其他的Service：Service Orientation其中一個特征就是“Service should be composite”,鼓勵將一個個相關(guān)細(xì)粒度的Service組合成一個大的Service。這樣有利于較大限度的實現(xiàn)重用，而重用往往意味著更小的投入、更佳的可維護(hù)性。而另一方面就是這些消費者通過怎樣的方式來調(diào)用它所需要的Service。

　　這實際上體現(xiàn)了兩者相互交互的問題。在一個分布式的環(huán)境中要實現(xiàn)兩者的交互，有兩個必須要解決的問題：如何保證Service的使用者對Service的調(diào)用能夠被Service端理解，以及對Service的調(diào)用如何抵達(dá)Service Side。后者實質(zhì)上是關(guān)于communication的問題，我們現(xiàn)在不去談它。第一個問題就是Contract需要解決的問題。

　　我們知道SOA一個主要的目標(biāo)就是促進(jìn)不同技術(shù)平臺的互操作，要真正實現(xiàn)這樣一個宏偉的目標(biāo)是一件極不容易的事情，需要不同的廠商和標(biāo)準(zhǔn)組織相互協(xié)作，制定一個大家一致遵循的標(biāo)準(zhǔn)。這樣一個標(biāo)準(zhǔn)就是WS-* 。我們很清楚，無論個個廠商各自的標(biāo)準(zhǔn)怎樣千差萬別，但是有個標(biāo)準(zhǔn)是他們必須要遵循的，那就是InterNET的標(biāo)準(zhǔn)，如果哪家公司拒絕InterNET，那肯定要被淘汰的。而對于InterNET，基于Http的網(wǎng)絡(luò)協(xié)議和基于XML的數(shù)據(jù)表達(dá)已經(jīng)成為了事實上的標(biāo)準(zhǔn)。對于SOA來說，XML不僅僅用于表示Service調(diào)用攜帶的數(shù)據(jù)（參數(shù)和返回值），更用于表示這個調(diào)用本身，以及滿足各種要求的控制信息, 比如基于Security、Session、Reliable Messaging、Transaction等等的控制信息。WS-*就是一個基于XML的標(biāo)準(zhǔn)。而對于SOA中的Contract所要做的就是尋求一種廠商中立的方式來表示Service的接口、和用于交互的數(shù)據(jù)結(jié)構(gòu)。前者就是Service Contract、后者就是Data Contract。

　　SOA中的一個Service由一組相關(guān)的Operation來構(gòu)成。Service Contract用于表示構(gòu)成該Service所有Operation的Interface（而不是Implementation）。說得更加具體點，大家都知道Consumer和Service之間的交互都是通過Message的形式來實現(xiàn)的，一次交互就是一次Message Exchange。在不同的場景，我們以不通過Pattern來進(jìn)程Message Exchange，比如我們通常使用Request-Response的方式來向Service發(fā)送Request進(jìn)而得到返回結(jié)果，我們也可以以Request-Forget的形式來異步地調(diào)用Service（不需要從Service獲取Response），我們可以讓一個Service在沒有收到任何Request的情況下，以廣播的形式向注冊的Client發(fā)送通知，當(dāng)然我們還有其他不同的消息交互的模式，我們把這些不同的信息交互方式稱為MEP（Message Exchange Pattern）。也就是說，一個Operation最終通過被最終轉(zhuǎn)換成了按照某種MEP進(jìn)行的消息交互，而Service Contract旨在實現(xiàn)對這種MEP的描述，比如是否需要Request Message或者Response Message（如果僅僅有Response Message就是Notification的方式；如果僅僅具有Request Message,那就是我們上面談到的Request-Forget的模式），和Message本身具有的格式。

　　上面我們說了Service Contract是以一種廠商中立的形式描述體現(xiàn)為某種模式的消極交互、構(gòu)成整個Service的所有Operation。而我們也說了Consumer和Service的交互本質(zhì)上看就是按照某種Pattern體現(xiàn)的一次Message Exchange，好像具有了Service Contract的描述就可以了。但是實際上，單單有了Service Contract對Service的描述還不夠，因為Service Contract本身缺乏對攜帶于Message，用于信息傳遞的數(shù)據(jù)類型的描述，而這是Data Contract需要解決的問題。我們知道不同的技術(shù)平臺對數(shù)據(jù)類型的表示是不一樣的，可能某一種技術(shù)平臺使用16bit來表述一個浮點數(shù)，另一種則使用32bit。所以要想實現(xiàn)不同技術(shù)平臺的互操作，將不同技術(shù)平臺同一類型的數(shù)據(jù)以一種廠商中立的形式來描述是必須的。

　　概括的說，SOA中的Service Contract和Data Contract就是一種廠商中立的數(shù)據(jù)呈現(xiàn)方式對Service Interface和Data Type的。而Service的調(diào)用都是通過SOAP Message來實現(xiàn)，SOAP是基于XML，而對于XML結(jié)構(gòu)的定義，我們很自然地想到XSD，我們可簡單地將SOA中的Contract看成是一個XSD。 
Contract in WCF 

　　上面我們實際上是在一個廠商中立的前提下探討Contract，這里的Contract和具體的平臺和技術(shù)無關(guān)。接下來我們要談的是基于技術(shù)的話題：討論一下WCF下的Contract。簡單地說，WCF中的Contract主要的功能就是如何將一個基于.NET的CLR Type，Interface或者Class，轉(zhuǎn)化成一個我們上面提到的Neutral Contract。比如，如果我們在一個Interface和它的成員上分別運(yùn)用Service Contract Attribute和Operation Contract，當(dāng)我們Host實現(xiàn)了該Interface的Service的時候，WCF就能將在一個.NET-specific的CLR Type暴露成一個Neutral Service Contract。同理對于一個，我們通過在一個Class和它的成員上分別添加DataContractAttribute和DataMemberAttribute，就可以就該CLR Type轉(zhuǎn)變成Neutral Data Contract。

比如我們一個運(yùn)用了DataContractAttribute和DataMemberAttribute的Order class：

 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 

　　通過上面的介紹，我們發(fā)現(xiàn)WCF Data Contract就如同一個適配器，彌合了 CLR Type和Neutral Contract的差異，很容易地實現(xiàn)了他們之間的匹配。接下來，我們就以一個實際的例子來介紹WCF DataContract的這種適配功能：通過DataContractAttribute的修飾，實現(xiàn)了將一個現(xiàn)有Data Type向一個既定的Neutral Data Contract進(jìn)行適配，從而實現(xiàn)了對基于該Neutral Data Contract的Service 進(jìn)行正常調(diào)用的目的。

　　我們就以上面提到的Order Class為例，Service端的Order class最終暴露成一個以XSD表示的Neutral Contract：

Order class：

 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技術(shù)：[原創(chuàng)]談?wù)刉CF中的Data Contract （1）：Data Contract Overview，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。