cuiyi's blog（崔毅 crazycy）

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

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

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

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

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

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

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

分級

一個(gè)關(guān)于粗粒度服務(wù)的爭論是此類服務(wù)比細(xì)粒度服務(wù)的重用性差，因?yàn)榇至６确?wù)傾向于解決專門的業(yè)務(wù)問題，因此通用性差、重用性設(shè)計(jì)困難。解決該爭論的方法之一就是允許采用不同的粗粒度等級來創(chuàng)建服務(wù)。這種服務(wù)分級包含了粒度較細(xì)、重用性較高的服務(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ù)，這一點(diǎn)區(qū)別于大多數(shù)其他的組件架構(gòu)。該方法旨在將服務(wù)使用者和服務(wù)提供者在服務(wù)實(shí)現(xiàn)和客戶如何使用服務(wù)方面隔離開來。

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

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

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

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

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

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

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

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

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

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

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

    過去，如果一個(gè)組件要調(diào)用另外一個(gè)組件的功能，它需要知道后者的接口在什么位置，使用什么協(xié)議和消息格式，這往往與其實(shí)現(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ù)細(xì)節(jié)，程序員需要了解很多相關(guān)的內(nèi)容，比如他需要?jiǎng)?chuàng)建一個(gè)JDBC或ODBC的數(shù)據(jù)源，再利用這些規(guī)范所提供出來的編程接口來想辦法得到數(shù)據(jù)源中的數(shù)據(jù)，為達(dá)成這個(gè)目標(biāo)，程序員還需要去做對象-關(guān)系映射，以實(shí)現(xiàn)對象到關(guān)系數(shù)據(jù)庫或者與之相反的數(shù)據(jù)轉(zhuǎn)換。目前有一些技術(shù)可以用來解決這些問題，比如前段時(shí)間在Java社群中一直都非常流行的Hibernate等，諸如此類的方法和工具很多，他們都是用來協(xié)助程序員處理上述工作的。但無論如何，你都無法逃避地要看到很多這些方法中非常底層的技術(shù)細(xì)節(jié)，而且，程序員需要學(xué)習(xí)所有這些不同的技術(shù)，了解它們適應(yīng)于什么情況，處理各種情況下的不同技術(shù)細(xì)節(jié)。事實(shí)上，程序員需要抽象層次更高的東西，比如業(yè)務(wù)數(shù)據(jù)對象(Business Object)以及它內(nèi)部各種細(xì)粒度數(shù)據(jù)對象之間的關(guān)聯(lián)，這是可以用一致、通用的方式來表示和操作的。有了抽象層次更高的模型，程序員就可以通用的方式來定義和訪問業(yè)務(wù)數(shù)據(jù)，從而以統(tǒng)一的方式來描述和訪問不同的數(shù)據(jù)源，降低對程序員技能的要求，提高生產(chǎn)率，更容易在不同的應(yīng)用環(huán)境交換。

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

    SDO 的目標(biāo)有很多，從某種程度上講 SDO 看起來好像是 J2EE 的一把多功能“瑞士軍刀”，因?yàn)樗奶匦钥蓪?shí)現(xiàn)多種不同種類的功能，基本來講，SDO 及其相關(guān)的技術(shù)設(shè)計(jì)有以下五大主要專題:

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

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

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

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

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