上次開會討論了對SCA和SDO的理解后，又重讀了IBM上關(guān)于SCA的文章，摘要如下：
SCA（Service Component Architecture）編程模型入門上指出：
?
服務組件（SCA Service Component）是SCA中的基本組成元素和基本構(gòu)建單位，也是我們具體實現(xiàn)業(yè)務邏輯的地方。
其組件結(jié)構(gòu)圖如下：
?????? 服務模塊（Service Module）由一個或多個具有內(nèi)在業(yè)務聯(lián)系的服務組件構(gòu)成，模塊是SCA中的運行單位，因為一個SCA模塊背后對應的是一個J2EE的企業(yè)應用項目。
服務模塊之間的關(guān)系如下：
?????? 可見，同一服務模塊內(nèi)部的服務組件之間是通過Reference和Interface直接關(guān)聯(lián)起來的，相對來說有比較緊密地耦合。
結(jié)合HelloWorld的示例應用
?????? 可以看到，同一個ServiceModule實際上實現(xiàn)了一個獨立的應用，這個應用一般有自己的展示層，通過Standalone Reference的方式，和Service Component建立聯(lián)系，實際的業(yè)務邏輯都封裝在Service Component中。同時，對于不同的ServiceModule，要相互引用，就要多費一些功夫了，需要使用服務模塊中的導入和導出定位到實際的服務模塊。
?????? 對于不同ServiceModule的交互，文章
WebSphere Process Server V6 體系結(jié)構(gòu)概述中給出下圖一個簡單的端到端業(yè)務數(shù)據(jù)同步的例子：
并解釋：
?????? 源EIS通過其適配器發(fā)出請求，傳入一個應用特定業(yè)務對象（Application-Specific Business Object，ASBO），通過轉(zhuǎn)接器轉(zhuǎn)換成一般業(yè)務對象（Generic Business Object，GBO），進入業(yè)務流程引擎進行處理，處理的結(jié)果以另一個GBO的形式，通過Selector傳輸?shù)街付ǖ哪繕耍俳?jīng)轉(zhuǎn)接器轉(zhuǎn)換為目標EIS的應用特定業(yè)務對象，進入目標EIS進行處理。
?????? 其中中間的矩形包括的ASBO、轉(zhuǎn)換器、GBO等等，按照我的理解，我覺得應該是企業(yè)服務總線ESB的功能，也就是不同的ServiceModule都插接到ESB上，通過業(yè)務對象映射服務（Map Service）以及關(guān)系服務（Relationship Service）一起，完成接口轉(zhuǎn)接的功能。同時，在一個SCA Service Component中，一般都是使用同樣的BO，如果不同，可以使用SCA接口轉(zhuǎn)接器（Interface Mediator）提供了SCA接口轉(zhuǎn)接的功能轉(zhuǎn)換，但是考慮到BPEL等等的自動編排，一般ServiceModule內(nèi)部還是應該使用同樣的BO，不同的ServiceModule之間一般BO不同。這里的BO就是SDO
同時，可以看到，不同模塊的耦合主要是通過引用來實現(xiàn)，一般來說，SCA引用分為模塊內(nèi)的引用和模塊間的引用。模塊間的引用定義的是一個模塊（中的組件）對于外部服務，例如另一個模塊中的組件或者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的方法，更加靈活一些的