cuiyi's blog（崔毅 crazycy）

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

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

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

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

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

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

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

分級

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

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

松散耦合

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

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

大多數松散耦合方法都依靠基于服務接口的消息?；谙⒌慕涌谀軌蚣嫒荻喾N傳輸方式（如HTTP、JMS、TCP/IP、MOM等）?；谙⒌慕涌诳梢圆捎猛胶彤惒絽f議實現，Web服務對于SOA服務接口來講是一個重要的標準。

當使用者調用一個Web服務時，被調用的對象可以是CICS事務、DCOM或CORBA對象、J2EE EJB或TUXEDO服務等，但這與服務使用者無關。底層實現并不重要。

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

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

精確定義的服務接口

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

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

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

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

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

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

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

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

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

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

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

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

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

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