若谷学院
互联网公司技术架构分享

在路上—基于SCA规范的应用服务框架成长记(二)(连载中…)

 二.背上铺盖带上干粮SCA服务框架之路启程

记得我在推广SCA规范的时候,常常和Spring作比较,Spring广为流传很大的一点就是在于它的IOC理念,SCA中也很彻底贯彻了这点(这点应该是个趋势,包括OSGI等等开源框架),但是也正是这个理念,在实际运用当中会带来困扰。当开发系统越来越大,一个工厂里面的bean组装复杂度不断增加,庞大的spring bean factory就好比一个大锅子,越来越多配置交织在一起,最终模块与模块之间无法分割,架构师虽然规划了很好的目录结构以及配置文件,但是在运行期的结构依然是耦合性极强,难以分割的业务模块逻辑团。这样的系统所面临的问题就像当初OO要解决的问题一样,只是上升到了业务级别:业务耦合性强,需求变更适应能力弱,维护成本高,无法剥离较为独立的业务组件提供复用,模块与模块之间牵制性强等。

SCA规范中描述的元数据就是CompositeComponent,在代码级别的概念中Component就是SpringbeanComposite可以看作Spring bean factory(其实使用Spring也可以实现SCA,只是如果使用factory来作为composite那么可能在性能上和可扩展性上还有一些问题)。在业务级别的设计中Composite就是业务模块,Component就是业务内部的业务实现逻辑单元,同时引入了ServiceReference的概念,将服务和引用单独作为内部逻辑单元,同时定义了ServiceReference的两种级别(CompositeComponent),达到了业务实现作用域的控制,真正做到了业务组件级别的封装。

应该来说,除了开放性的特质以外,业务模块封装的特质是SCA的模块化最突出的优势,也是解决系统日益庞大情况下,如何降低维护成本,如何适应需求变更,如何提高开发效率的有效手段。但就是规范中的这一点,Tuscany的实现,不得不让我由原来的基于Tuscany架构二次扩展开发的想法做了转变,同时在后面对于服务框架的需求不断发展的情况下,对于Tuscany在服务框架中的定位不断的作着改变。

Tuscany在业务模块封装上面究竟有什么问题呢?在Tuscany中提供给第三方嵌入的SCA容器EmbeddedSCADomain结构如下:

                                                                             

EmbeddedSCADomain运行期结构图

       上面的图展示了EmbeddedSCADomain如何载入外部的Composite到容器中,这里所用的一个技巧,就是includeComposite可以include多个Composite。下图是一个很简陋的活动图,主要就是大致描述了EmbeddedSCADomain是如何加载所有的Composites的。这里面省略了Tuscany对于插件扩展的载入以及一些细节方面的处理。

EmbeddedSCADomain启动活动图

 

       根据上面两个图就出现了两个比较大的问题:

1.       首先EmbeddedSCADomain所有的Composite和资源都是根据固定的URI载入,但是这个或者是目录或者是jar,但是如果是目录中的jar将不会去解析,那么对于我们业务模块当前的开发要求,各个业务开发组会把不同的Composite最后打包到各个业务模块的jar中,这样就没有办法通过一个EmbeddedSCADomain去装载,互通就更加说不上了。不过这个问题不是根本性的问题。而后面2的问题是根本性的原则问题。

2.       Tuscany让所有的Composite互通,是将所有的composite通过include到一个domainComposite中,在build的过程中将所有的Composite的内部components克隆到了domainComposite中,这样其实所有的Component就在一个Composite中,也就很方便的互通了。这样SCA框架的业务模型封装形同虚设,和spring一样一个大的factory没有什么区别,丢失了最大的一个优势。同时serivcereference都没有两种级别之分,业务模块化就无法实现和控制。

 

就这样两个问题,让我需要考虑重新基于Tuscany的部分内核机制来重新构建容器装载,解析,组装机制。下图是ASF(Application Service FrameWork)的运行期结构设计图

 

ASF(Application Service FrameWork)的运行期结构设计图

问题一的解决方案:

ASF中定义了真正包容所有CompositeService Container,创建的过程中,通过搜索Classpath中所有的有composite-load-config.xml文件的jarcomposite-load-config.xml定义了需要装载的Composite,然后resolve这些jar的所有的resource,根据定义要加载的内容动态加载所有需要加载的composite

 

问题二的解决方案:

       基于问题一的解决,然后在Container中记录各个composite的必要信息和状态,然后按照不同级别的servicereference组装所有的composite,最后激活所有的composite

 

这两个问题的解决,也标志着ASF的基础框架形成,后续的战斗真正开始。

原文出自:https://blog.csdn.net/cenwenchu79/article/list/8

好烂呀没啥价值凑合看看还不错很精彩 (还没有人评分)
Loading...
本站文章来自互联网一线技术博客,若有侵权,请联系我们:若谷技术学院 » 在路上—基于SCA规范的应用服务框架成长记(二)(连载中…)
关注若谷技术,获得个性化即时架构文章推送

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

全球互联网技术架构,前沿架构参考

联系我们博客/网站内容提交