上次开会讨论了对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的方法，更加灵活一些的