对tuscany中domain、cloud、node、composite关系的理解
tuscany是对sca、sdo标准的实现，sca完成服务的封装和wire，sdo完成数据的统一。
sca是一种ESB实现方式
其实，sca完成的功能远远不止封装服务那么简单。我们在使用sca的过程中，将某个业务功能封装成sca组件，将多个composite封装成一个顶级的composite来完成更粗粒度的服务封装。将BPEL流程编排封装成一个sca组件来使用...... 可见，sca就是ESB的一种实现方式，而不单纯是一种服务的封装形式。
ESB完成的作用大致上有四点：
1、服务路由，让A服务发出的请求能够到达B服务。
2、协议转换，转换A服务和B服务之间所用的不同协议
3、数据格式转换，转换A服务和B服务之间数据的格式和关系
4、事件处理，处理不同来源的事件
sca通过构件的方式将基于业务功能的服务进行封装，组件和组件、构件和构件之间通过Reference进行wire，产生松耦合的依赖。因为Reference可以指向一个本地域的组件的服务（target方式）或者通过引用一个webservice的方式来定义。实际上就是在多个组件和构件之间进行了一种路由。
sca支持将某个协议的服务包装成一个sca组件，对外暴露出基于其他协议的服务，相当于进行了协议的转换。
数据格式的转换是通过tuscany的DataBindingFrameWork来完成的。
事件处理可以通过CEI来实现基于事件的响应处理，构建在JMS的基础之上。
因此，sca本身就是ESB的一种实现方式，而且这种实现方式采用的编程模型更易于理解，也更加一致。
domain/cloud/node/composite
scaDomain sca域：在tuscany运行时随着web container启动的时候，就会产生一个sca domain，这个domain是一个全局对象，而且是单例。类似于hibernate的SessionFactory，是个耗费资源的对象。它包括所有和tuscany运行时相关的东西，比如贡献包contribution、可部署构件deployable composite、节点node........
workspace.xml 工作空间配置文件：用来注册domain内所有贡献包资源的物理位置（location）和命名空间（namespace），包括所有可部署节点deployable composite和一些jar包、war包等等。
domain.composite domain构件： 它关注的是在domain中可以使用的composite，虽然这些composite在workspace中添加了，但在domain中能不能被使用则是在这里配置的。node 节点：一个用来描述物理节点或者逻辑节点的概念。
有两种情况：
1、将node视为物理节点
比如在分布式系统中，有很多台服务器，这些服务器侧重的业务不同。比如有A、B、C三台服务器。A服务器保存assert资源，B服务器保存某类业务的所有composite和实现，C服务器保存所有BPEL工作流组件。这三台服务器都链接到ESB上来，这个ESB也是一个SCA runtime，只不过通过这个runtime将分布在不同物理位置上的服务和应用整合起来了。那么这种情况下，对于每一个服务器，都可以看做是一个物理节点node。每个node下面都有一个或者多个composite，这些composite通过构构件实现的方式统一到一个顶级composite上来（构件之间的wire），然后node和这个顶级composite进行关联，从而实现了用node来管理多个composite的作用，而且对于构件引用而言，对引用它的构件是内部不可见的，也就是被引用的构件对外面引用它的构件隐藏了内部component的细节，而仅仅暴露了composite提升promote的Service、Reference和Property。从而实现了细节的封装。这是node作为物理节点的情况。
2、将node视为逻辑节点
比如在一个jvm环境下，可以通过node将应用程序按照功能模块进行划分，不同的模块对应不同的node，这也是一种用法。
cloud 云：用来管理node的一个逻辑集合，它的关注点是node，如何将这些分布在不同物理节点（或者不同功能模块）的node有效的组织起来，提供使用。
workspace从物理位置上定位了某个deployable composite的位置，但仅有这个还不能使用，cloud在逻辑上对deployable composite进行了定位（通过cloud来寻找node，在通过node找到某个具体的composite），两者缺一不可。
composite 组件：可以是细粒度的组件，也可以是粗粒度的组件