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

标签: soadomainjar.net测试php
5996人阅读 评论(8) 收藏 举报
分类:

网友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 做比较详细的解析和示例,进度还是要看时间是否充裕。 

0
1

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2022960次
    • 积分:23782
    • 等级:
    • 排名:第287名
    • 原创:383篇
    • 转载:143篇
    • 译文:9篇
    • 评论:479条
    博客专栏
    最新评论