回复:细说SCA V1.0规范(2) --Composite与架构

网友sca提了几个问题,csdn的回复无法提交,所以作为文章发出。

回复:细说SCA V1.0规范(2) --Composite与架构  sca  9/28/2007 11:20:53 AM    
 还是支持一下
不知道你为什么要这么分成三层,有什么作用么
而且不知道能否深入一些
比如:Composite如何提供服务,服务如何打包,如何被其他服务引用.更进一步,服务如何组装.
对于非SOA架构的系统,如何拆分服务,如何把这些服务包装为符合SCA标准的服务.
还有能否通过例子来讲解,那样比较直观,实践最重要,理论上的东西比较抽象.
还是谢谢LZ了,很辛苦,期待继续

感谢支持!

1、为什么分成三层？有什么作用？
Composite架构层虽然都是由Composite组件构成的,但不同的Composite在架构层中起到的作用是不同的,虽然它们的内部结构是相同的---即都有Services,References,Component等.
对Base-Composite关注的是它提供了什么,它的作用体现在提供了哪些Services,这些Services主要都是由这些Composite的Component提供的，或者说至少有一部分是由Component提供的（因为它还可以通过References引用其他组件的Services）。这些由Component实现的Services是整个Composite架构层的基石。如果没有这些Base-Composite，没有它们包含的Component提供的实现，这个SCA系统就是个空壳，引用来调去最后调用的服务都是空的。这些Composite的Component的实现方式决定了它与另外两种Composite作用的不同。
Top-Composite的作用体现在它的Services是面向业务层的。通过使用URI命名这些Top-Composite，业务层可以直接通过URI使用这些Top-Composite提供的Services。Top-Composite是Composite架构层的门面。所以它的作用与其他两种Composite是不同的。
如果说Base-Composite是一层包含component的实现，Top-Composite是Composite架构层的门面，那么Arch-Composite的作用就非常的重要了。如果要发挥Arch-Composite的作用，还要涉及一个话题就是：Composite实现粒度的大小,或者说implementation实现的粒度的"度"。这个文章后面会谈到。
所以，Base-Composite体现的是实现(Component)，只不过在Component外面包了一层Composite的外壳，使得Component借用Composite的外壳，和其他的Composite使用统一的、标准的调用方式：即用Services输出服务、用References输入服务、用Property传值等。在上篇文中说过，在SCA模型中，Component组件对应实现层，Composite组件对应架构层。Base-Composite就是两层的边界。Base-Composite对架构层来说提供了实现;而对实现层来说，第一提供了封装，第二提供了Promote机制。
Top-Composite也类似，只不过与它对应的是架构层和业务层(Domain对应业务层)。这个在后面的Domain与业务中会详细说明。

2、关于Composite如何提供服务后面会继续，敬请关注。

3、服务如何打包，如何被其他服务引用，服务如何组装？
这是些非常实际的问题。在Tuscany的SCA早期实现中，服务是通过jar方式打包的。jar包需要通过一些方式部署到SCA环境中，SCA会在宿主机上有一个指定的或者默认的安装路径，将服务放在这些系统文件目录下使用。这是一个Tuscany SCA 引导和装配的过程供参考，http://blog.csdn.net/teamlet/archive/2007/03/26/1542064.aspx
以后会针对Tuscany SCA 1.0 做比较详细的解析。

4、对于非SOA架构的系统,如何拆分服务,如何把这些服务包装为符合SCA标准的服务？
对于非SOA架构的说法我觉得不够准确，如果说非SCA架构的系统，那么针对的就是目前的规范。因为SOA规范也可以使用其他的、非SCA的规范实现。
还有就是要求是基于J2EE架构的系统。对于其他的实现比如，.net，php等没有相关的实践，无法作出评述。
把非SCA的J2EE架构的系统包装为符合SCA标准架构的系统，拆分的重点是component实现的粒度考虑。这些component实现粒度多大合适，这个"度"，不好把握。粒度小，复用度很高，系统灵活，松散偶合度高，改变系统的行为容易，但是会使Composite层变厚，性能上会有些损失，管理上会麻烦一些。粒度大，复用度低，不能充分发挥Composite层的作用。

另外，component的实现如果粒度小，那么相应的每一个实现的代码就很少。很少的代码量可以减少代码的错误、降低逻辑复杂度、方便测试、降低维护和管理的成本、实现的功能定位清楚、目标明确，实现层的开发人员将精力集中在代码上，无需关心其他层的事情，专业化程度提高，提高了代码的质量，也提高了开发的效率和开发成本。同时可以构建本单位的Component实现的组件库，分类保存Component的实现组件，在多个SCA架构系统的项目中复用已有的Component实现组件。如果这个组件库足够大，那么Component实现组件开发成本几乎为零。充分发挥SCA架构的优势，为企业降低成本，提高软件质量，延长产品的生命周期，降低维护成本。

5、能否通过例子来讲解,那样比较直观,实践最重要,理论上的东西比较抽象
以后会结合Tuscany SCA 1.0 做比较详细的解析和示例，进度还是要看时间是否充裕。