cuiyi's blog（崔毅 crazycy）

粗粒度服務(wù)提供一項特定的業(yè)務(wù)功能，而細粒度服務(wù)代表了技術(shù)組件方法。舉個例說明最為清楚:向計費系統(tǒng)中添加一個客戶是典型的粗粒度服務(wù)，而你可以使用幾個細粒度服務(wù)實現(xiàn)同一功能，如：將客戶名加入到計費系統(tǒng)中，添加詳細的客戶聯(lián)系方式、添加計費信息等等。

采用粗粒度服務(wù)接口的優(yōu)點在于使用者和服務(wù)層之間不必再進行多次的往復(fù)，一次往復(fù)就足夠。Internet環(huán)境中有保障的TCP/IP會話已不再占據(jù)主導(dǎo)、建立連接的成本也過高，因此在該環(huán)境中進行應(yīng)用開發(fā)時粗粒度服務(wù)接口的優(yōu)點更為明顯。

除去基本的往復(fù)效率，事務(wù)穩(wěn)定性問題也很重要。在一個單獨事務(wù)中包含的多段細粒度請求可能使事務(wù)處理時間過長、導(dǎo)致后臺服務(wù)超時，從而中止。與此相反，從事務(wù)的角度來看，向后臺服務(wù)請求大塊數(shù)據(jù)可能是獲取反饋的唯一途徑。

Code First vs WSDL Frist 如果要構(gòu)建一個Web Services，CXF提供了兩種構(gòu)建方式一個是Code First，另一個WSDL First。接觸過WSDL的朋友應(yīng)該都有這樣的感覺，WSDL雖然是用XML來進行描述的，但是如果讓你在不借助任何工具的情況下寫一個正確的WSDL，或者是改正一個錯誤的WSDL是很難的。Code First可以說是為我們提供了一個不錯的選擇。

但是Web Services的Best Practies并不推薦Code First這一Web Services的構(gòu)建方式。原因是什么呢？

這是因為我們在使用Code First構(gòu)建方式時很少考慮到Web Services之間的交互是以文檔方式進行（這樣可以大大提高Web Services的互交互性），如果是使用Code First來構(gòu)建WSDL信息，在描述描述交互信息的XML Schema都是以我們的Code中定義的類型信息來生成的，這樣就可能會暴露一些比較細粒度的信息。同時大家知道不同的語言（C＋＋，Java， C＃，PHP）對XML Schema映射是各不相同的，如果我們Code中定義的類型很特殊，就可能產(chǎn)生出一個不能互操作的現(xiàn)象。

所以Best Practies建議你在創(chuàng)建Web Services從交互的消息Schema入手，構(gòu)建一個中間層來提供一個比較粗粒度的描述，這樣可以比較好的解決Web Services的互交互問題。

分級

一個關(guān)于粗粒度服務(wù)的爭論是此類服務(wù)比細粒度服務(wù)的重用性差，因為粗粒度服務(wù)傾向于解決專門的業(yè)務(wù)問題，因此通用性差、重用性設(shè)計困難。解決該爭論的方法之一就是允許采用不同的粗粒度等級來創(chuàng)建服務(wù)。這種服務(wù)分級包含了粒度較細、重用性較高的服務(wù)，也包含粒度較粗、重用性較差的服務(wù)。

在服務(wù)分級方面，須注意服務(wù)層的公開服務(wù)通常由后臺系統(tǒng)（BES's）或SOA平臺中現(xiàn)有的本地服務(wù)組成。因此允許在服務(wù)層創(chuàng)建私有服務(wù)是非常重要的。正確的文檔、配置管理和私有服務(wù)的重用對于IT部門在SOA服務(wù)層快速開發(fā)新的公開服務(wù)的能力具有重要影響。

松散耦合

SOA具有“松散耦合”組件服務(wù)，這一點區(qū)別于大多數(shù)其他的組件架構(gòu)。該方法旨在將服務(wù)使用者和服務(wù)提供者在服務(wù)實現(xiàn)和客戶如何使用服務(wù)方面隔離開來。

服務(wù)提供者和服務(wù)使用者間松散耦合背后的關(guān)鍵點是服務(wù)接口作為與服務(wù)實現(xiàn)分離的實體而存在。這是服務(wù)實現(xiàn)能夠在完全不影響服務(wù)使用者的情況下進行修改。

大多數(shù)松散耦合方法都依靠基于服務(wù)接口的消息。基于消息的接口能夠兼容多種傳輸方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和異步協(xié)議實現(xiàn)，Web服務(wù)對于SOA服務(wù)接口來講是一個重要的標準。

當(dāng)使用者調(diào)用一個Web服務(wù)時，被調(diào)用的對象可以是CICS事務(wù)、DCOM或CORBA對象、J2EE EJB或TUXEDO服務(wù)等，但這與服務(wù)使用者無關(guān)。底層實現(xiàn)并不重要。

消息類Web服務(wù)通常是松散耦合和文檔驅(qū)動的，這要優(yōu)于與服務(wù)特定接口的連接。當(dāng)客戶調(diào)用消息類Web服務(wù)時，客戶通常會發(fā)送的是一個完整的文檔（如采購訂單），而非一組離散的參數(shù)。Web服務(wù)接收整個文檔、進行處理、而后可能或者不會返回結(jié)果信息。由于客戶和Web服務(wù)間不存在緊密耦合請求響應(yīng)，消息類Web服務(wù)在客戶和服務(wù)器間提供了更為松散的耦合。

明確的邊界
通過跨越定義明確的邊界進行顯式消息傳遞，服務(wù)得以彼此交互。有時候，跨越服務(wù)邊界可能要耗費很大的成本，這要視地理、信任或執(zhí)行因素而定。邊界是指服務(wù)的公共接口與其內(nèi)部專用實現(xiàn)之間的界線。服務(wù)的邊界通過 WSDL 發(fā)布，可能包括說明特定服務(wù)之期望的聲明。

精確定義的服務(wù)接口

服務(wù)是由提供者和使用者間的契約定義的。契約規(guī)定了服務(wù)使用方法及使用者期望的最終結(jié)果。此外，還可以在其中規(guī)定服務(wù)質(zhì)量。此處需要注意的關(guān)鍵點是，服務(wù)契約必須進行精確定義。

META將SOA定義為：“一種以通用為目的、可擴展、具有聯(lián)合協(xié)作性的架構(gòu)，所有流程都被定義為服務(wù)，服務(wù)通過基于類封裝的服務(wù)接口委托給服務(wù)提供者，服務(wù)接口根據(jù)可擴展標識符、格式和協(xié)議單獨描述。”該定義的最后部分表明在服務(wù)接口和其實現(xiàn)之間有明確的分界。

 面向文檔
消息被構(gòu)造為“純文本的”XML文檔（換句話說，數(shù)據(jù)的格式只對XML有意義）。 消息通常用于傳輸業(yè)務(wù)文檔，比如購買訂單、發(fā)票和提單。這種交互類型與同步消息排隊系統(tǒng)的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。 

    SCA主要是針對在面向服務(wù)的計算環(huán)境里，組件的實現(xiàn)方法。同時，它強調(diào)了這些組件與現(xiàn)有的平臺，組件之間的關(guān)聯(lián)，并描述怎樣通過已有的技術(shù)、平臺甚至于現(xiàn)有的組件來實現(xiàn)面向服務(wù)組件。另外，在將這些服務(wù)組件實現(xiàn)以后，它們的接口以及這些接口的語義是怎樣描述的。

    其實，新的組件描述應(yīng)該是技術(shù)獨立、平臺獨立、語言獨立的，也就是說它是一個開放的規(guī)范，這樣就可以讓很多IT廠商在不同的平臺上用不同技術(shù)和語言來參考和實現(xiàn)這些技術(shù)。除此之外，面向服務(wù)的組件需要相互之間的交互，這種交互應(yīng)該是松耦合的，也就是說需要打破過去那種緊耦合的現(xiàn)象。因為不管是.NET、J2EE還是更早的CORBA等技術(shù)，它們在支持分布式計算時，其組件往往和平臺、語言以及實現(xiàn)技術(shù)緊密相關(guān)。       　

    過去，如果一個組件要調(diào)用另外一個組件的功能，它需要知道后者的接口在什么位置，使用什么協(xié)議和消息格式，這往往與其實現(xiàn)技術(shù)有直接的關(guān)系，所以技術(shù)、平臺、語言和位置等各種各樣的因素的透明性對于組件之間的交互就是非常重要的一件事情了，而SCA恰恰就規(guī)定了這一部分的內(nèi)容。                                                                                 

    過去我們所采用的技術(shù)中，不管是.NET也好，J2EE也好，它們都有基于自身平臺下的規(guī)范，比如在J2EE環(huán)境下，我們就會通過JDBC、Entity Bean這樣的方式訪問數(shù)據(jù)庫或者其它數(shù)據(jù)源;而在.NET下同樣有類似ADO這樣的方式來訪問各種不同的數(shù)據(jù)源。這里面的問題在于，平臺透露了太多的技術(shù)細節(jié)，程序員需要了解很多相關(guān)的內(nèi)容，比如他需要創(chuàng)建一個JDBC或ODBC的數(shù)據(jù)源，再利用這些規(guī)范所提供出來的編程接口來想辦法得到數(shù)據(jù)源中的數(shù)據(jù)，為達成這個目標，程序員還需要去做對象-關(guān)系映射，以實現(xiàn)對象到關(guān)系數(shù)據(jù)庫或者與之相反的數(shù)據(jù)轉(zhuǎn)換。目前有一些技術(shù)可以用來解決這些問題，比如前段時間在Java社群中一直都非常流行的Hibernate等，諸如此類的方法和工具很多，他們都是用來協(xié)助程序員處理上述工作的。但無論如何，你都無法逃避地要看到很多這些方法中非常底層的技術(shù)細節(jié)，而且，程序員需要學(xué)習(xí)所有這些不同的技術(shù)，了解它們適應(yīng)于什么情況，處理各種情況下的不同技術(shù)細節(jié)。事實上，程序員需要抽象層次更高的東西，比如業(yè)務(wù)數(shù)據(jù)對象(Business Object)以及它內(nèi)部各種細粒度數(shù)據(jù)對象之間的關(guān)聯(lián)，這是可以用一致、通用的方式來表示和操作的。有了抽象層次更高的模型，程序員就可以通用的方式來定義和訪問業(yè)務(wù)數(shù)據(jù)，從而以統(tǒng)一的方式來描述和訪問不同的數(shù)據(jù)源，降低對程序員技能的要求，提高生產(chǎn)率，更容易在不同的應(yīng)用環(huán)境交換。

　　這樣，不管是Java或者C++語言描述下，程序員都不必去了解平臺上的技術(shù)細節(jié)，用一個XML Schema描述這樣的通用、簡單的的業(yè)務(wù)數(shù)據(jù)模型，然后在運行將對象持久化到你的關(guān)系數(shù)據(jù)庫、XML或者其它數(shù)據(jù)源中。

    SDO 的目標有很多，從某種程度上講 SDO 看起來好像是 J2EE 的一把多功能“瑞士軍刀”，因為它包含的特性可實現(xiàn)多種不同種類的功能，基本來講，SDO 及其相關(guān)的技術(shù)設(shè)計有以下五大主要專題:

　　1）簡化數(shù)據(jù)訪問:第一個目標是提供對多種企業(yè)信息系統(tǒng) (EIS) 的統(tǒng)一的數(shù)據(jù)訪問，包括數(shù)據(jù)庫、遺留應(yīng)用程序(使用 JCA)、XML 或者是 Web 服務(wù)數(shù)據(jù)源。通過使用 SDO 的一種獨特而簡單的模型，應(yīng)用程序擺脫了使用多種 API 和框架進行數(shù)據(jù)訪問的復(fù)雜工作。

　　2）數(shù)據(jù)提取:使用 SDO 后，數(shù)據(jù)的表示是獨立于其數(shù)據(jù)源的，它采用了一種叫做 Domain Store 的 J2EE 模式，這種級別的數(shù)據(jù)提取有很多優(yōu)點，例如使數(shù)據(jù)操作變得更容易，實現(xiàn)了不同層之間的松耦合。

　　3）數(shù)據(jù)操作:一旦檢索到信息后，SDO 會提供一種統(tǒng)一的編程語言進行數(shù)據(jù)操作，簡單的說，就是通過使用 API 及其接口，SDO 客戶機可以讀取數(shù)據(jù)和修改數(shù)據(jù)。SDO 為此提供了連接和斷開連接的兩種模型。

　　4）數(shù)據(jù)傳輸:SDO 有一部分概念是關(guān)于傳輸對象 (Transfer Object) 和傳輸對象組裝程序 (Transfer Object Assembler) 模式的。數(shù)據(jù)封裝到 SDO 對象中后，它就可以在 J2EE 層間高效地傳輸。

　　5）設(shè)計模式的采用:SDO 的一個關(guān)鍵目標是鼓勵大家采用公用的 J2EE 模式，這也是 SDO 體系結(jié)構(gòu)以一些廣為人知的模式為基礎(chǔ)的原因，例如傳輸對象 (Transfer Object)、數(shù)據(jù)訪問對象 (Data Access Object)、傳輸對象組裝程序和 Domain Store等。如果使用了 SDO，應(yīng)用程序就可以從這些經(jīng)過了驗證的設(shè)計策略中受益，從而可以推動分層技術(shù)和松耦合的發(fā)展。