上次開會討論了對SCA和SDO的理解后，又重讀了IBM上關于SCA的文章，摘要如下：
SCA（Service Component Architecture）編程模型入門上指出：
?
服務組件（SCA Service Component）是SCA中的基本組成元素和基本構建單位，也是我們具體實現業務邏輯的地方。
其組件結構圖如下：
?????? 服務模塊（Service Module）由一個或多個具有內在業務聯系的服務組件構成，模塊是SCA中的運行單位，因為一個SCA模塊背后對應的是一個J2EE的企業應用項目。
服務模塊之間的關系如下：
?????? 可見，同一服務模塊內部的服務組件之間是通過Reference和Interface直接關聯起來的，相對來說有比較緊密地耦合。
結合HelloWorld的示例應用
?????? 可以看到，同一個ServiceModule實際上實現了一個獨立的應用，這個應用一般有自己的展示層，通過Standalone Reference的方式，和Service Component建立聯系，實際的業務邏輯都封裝在Service Component中。同時，對于不同的ServiceModule，要相互引用，就要多費一些功夫了，需要使用服務模塊中的導入和導出定位到實際的服務模塊。
?????? 對于不同ServiceModule的交互，文章
WebSphere Process Server V6 體系結構概述中給出下圖一個簡單的端到端業務數據同步的例子：
并解釋：
?????? 源EIS通過其適配器發出請求，傳入一個應用特定業務對象（Application-Specific Business Object，ASBO），通過轉接器轉換成一般業務對象（Generic Business Object，GBO），進入業務流程引擎進行處理，處理的結果以另一個GBO的形式，通過Selector傳輸到指定的目標，再經轉接器轉換為目標EIS的應用特定業務對象，進入目標EIS進行處理。
?????? 其中中間的矩形包括的ASBO、轉換器、GBO等等，按照我的理解，我覺得應該是企業服務總線ESB的功能，也就是不同的ServiceModule都插接到ESB上，通過業務對象映射服務（Map Service）以及關系服務（Relationship Service）一起，完成接口轉接的功能。同時，在一個SCA Service Component中，一般都是使用同樣的BO，如果不同，可以使用SCA接口轉接器（Interface Mediator）提供了SCA接口轉接的功能轉換，但是考慮到BPEL等等的自動編排，一般ServiceModule內部還是應該使用同樣的BO，不同的ServiceModule之間一般BO不同。這里的BO就是SDO
同時，可以看到，不同模塊的耦合主要是通過引用來實現，一般來說，SCA引用分為模塊內的引用和模塊間的引用。模塊間的引用定義的是一個模塊（中的組件）對于外部服務，例如另一個模塊中的組件或者Web服務等的依賴。
??????同時，我們注意到一點，在很多IBM SOA的文章中，都是使用了Service Locator的方法來定位服務，比如
SCA（Service Component Architecture）編程模型入門中就使用了如下代碼：
1
ServiceManager?serviceManager?=?new?ServiceManager();
2Service?service?=?(Service)?serviceManager.locateService("HelloWorldInterfacePartner"); ????注意到這里的
HelloWorldInterfacePartner實際上是一個服務的邏輯名，所以這里就實際上解除了和實際的服務的耦合，是很松散的耦合。比較一下在spring等等IOC框架中的通過配置文件來組裝POJO的方法，這樣也不失為一種可行的策略。不過，相比而言，我還是更喜歡在spring中那種通過xml配置文件組裝bean的方法，更加靈活一些的