再谈OSGI，SCA， 服务框架

 

       兄弟公司新来的BlueDavy同学正好是我过去OSGI起步时的间接导师（看了他的《OSGI进阶》和一些实际的使用经验分享），中午第一次在网上遇到，谈了一会儿，下午有一点时间正好去看了看他新的三篇文章，关于OSGI,SCA,服务框架的文章，有一些自己的体会，在这儿也分享一下，自己对于OSGI也就入门性的了解，所以分析的未必到位，也只能说投石问路了^_^，不过很是期待后面彼此的合作和交流。

 

OSGI --> SCA

       在去年的3，4月份，平台需要做一次重构，前端框架不列入第一次重构范围，重构的重点在于后端整体框架的重构和服务框架的设计与实现。对于服务框架这部分，前期的需求主要是希望能够为将来的模块化做好准备，因此就正好去研究了一下OSGI。OSGI的优点在于做到了真正的业务组件模块化（实现类，各种资源，类库等），就和其元数据Bundle名字一样，完全打包。其实就OSGI的起源来看也是这样，它最早用于汽车制造的设计，和J2ME嵌入式开发一样，这种良好的封装对于组件的交互（接口稳定），动态装载替换都有天生的良好支持。而当前的Java应用开发也越来越重视业务模块的封装和重用，动态载入以及类库的独立管理都是未来的一种趋势。但经过一段时间的实践操作，使我考虑去寻找一个新的技术框架规范来实现我的服务框架，原因是什么呢？首先和BlueDavy同学在文章中说到一点一样，OSGI的服务框架没有提供外部显示调用，同时当时我实践的Equiox要被Embedded到平台中比较困难，除非由上至下全部采用统一的OSGI框架，而且和外部第三方系统进行交互也不是很方便。再则，OSGI的一大亮点classloader自管理机制也是一个制约，在实际开发中很需要能够这么做，由于第三方开源项目的依赖日益增多，这问题就更加突出，不说别的，就说现在Jdk1.6中已经作为基础API框架的Stax API 框架，就会被任意的第三方实现，载入的方式也是动态运行期查找实现载入，这时候莫名其妙的问题，单元测试没有问题，上了Web Container有问题都冒了出来。但是OSGI的隔离需要处理很复杂的依赖关系，这样往往在复杂的情况下还是会出现解决不了的灵异问题。最后就是OSGI其实和我的需求不是很符合，起码是后面平台战略的改变以后，OSGI就更加不是首选的技术实现。因为现在公司需要构建的是应用接入平台，SAAS模式的运营平台，OSGI的长处不在于这种分布式异构松耦合服务框架的实现，它特长在于单机同构模块化的服务框架实现。因此，OSGI就此暂告一段落。

       还是那句老话啊，没有不好的技术，只有被滥用的技术，适合的才是最好的，从OSGI转到SCA并不是说OSGI不如SCA，没有可比性，只是说SCA更合适我当前的应用场景，没必要喝汤非要用筷子。

 

SCA和服务框架

       我的Blog已经有很多关于SCA应用设计实现的文章，这里我不再去讨论那些，只是把为什么在设计服务框架时选择SCA来说一下。其实服务框架的技术选型，试验，实践，应用，都是一步一步踏踏实实的走过来的。

       ASF(Application Service Framework)也就是当前基于SCA规范实现的服务框架有这么一些特质，也是未来应用接入平台需求所决定的一些必备特质。

模块化：SCA规范明确界定了服务模块的封装交互。（很多人觉得模块化是个概念，系统规模日益增大，模块间耦合对于需求变化频繁，模块化集成测试，动态载入需求等等都会产生很大的影响）

开放性：在我的blog有个朋友问起，用Spring实现这些功能绰绰有余，web service独立的框架一大堆，为什么还搞出一个SCA来弄，自找麻烦。赫赫，如果这么说，那么就证明其实没有仔细理解SCA是什么，SCA只是一个框架规范，而上面提到的都是实现技术手段，用Spring也可以实现SCA框架，而且实现起来很容易，但真正要把SCA的开放性体现出来，那么需要做的远远不是简单的用N个Spring Factory来构造N个Composite那么简单。其实现在ASF中已经很好的集成了Spring,Hessian,Jetty,Axis2,JMS等等，简单来说，只要想集成的就是一个SCA的实现，也就是说其实SCA不是什么技术，而是一种技术实现规范，任何技术只要按照这种规范来实现了，也就是一种SCA扩展，SCA框架就好比Eclipse，SCA就好比Eclipse的plug api和Flow design。一本好菜谱怎么做全看厨师，用什么料，什么锅子铲子，厨师说了算，如果硬生生的将技术和SCA去比较，那只会离SCA越来越远。

SOA：记得我去BEA参加SOA年会的时候，听了几节关于SOA的技术教学课，因为时间的原因，几个老师都很快地去说了一下SOA的大致概念，不过最为突出的就说到了Web Service，其实自己觉得这可能会误导很多人。现在一提到SOA很多刚刚接触的朋友都说就是用Web Service来做服务掉用么，但其实和前面对于SCA犯了一样的一个错误，Web Service只是SOA的某一部分的一种技术实现手段，无疑Ws的成熟运用是SOA的技术支持，但是SOA对于服务的管理其实才是最重头的部分。SCA框架在WS上的支持主要来源于他的开放可以集成各种好的开源应用，Jetty+AXIS2（以后考虑集成CXF来满足Rest类型的服务发布）可以很好的满足需求，Jetty+Hessian可以提供给内部的分布式服务调用和组装。在服务管理方面，灵活的框架规范已经实现了服务调用组装于实现透明，松耦合异构化的服务在SCA框架中得到了很好的支持，唯一需要考虑的是，在将来更高层服务流的支持上，可以集成BPM来提供更高层次的支持。前一阵子考虑是否要集成某一个开源的ESB到框架中，用来提供更多的服务管理功能，不过看了看几个不错的ESB开源框架，很多功能已经都是在ASF中实现的，而且相对来说比较重，所以暂时就没有再作什么工作了。

       在BlueDavy同学服务框架一文中提到的服务的组装调用管理在ASF都已经得到了很好的支持。

 

SCA & OSGI

       然后回过头来再看看SCA和OSGI的关系。其实我觉得用个比喻来说明会更加形象一些，现在就好比我们平台需要开发一种武器攻击范围可近可远，我就选择了弓箭，SCA就好比弓箭的设计图，而ASF现在就好比是弓，已经有了火箭，冰箭，木箭等等，OSGI是一支可变的箭，箭头多变，以变克敌。ASF中集成OSGI就是将这种好的技术作为一种内部扩展实现，在各种适合的应用场景中发挥其最大的作用。

       OSGI在当前互联网应用之所以没有被广泛应用，其实也有它的道理，首先对于现在的应用来说模块化的动态载入和部署应用需求场景很少，特别是生产环境，因为当前的大应用往往重新部署和启动来的更有效和方便，classloader管理的复杂性也是很重要的原因。

       但就将来的趋势来看，Jdk7的一个重点就是类似于OSGI的动态性，也已经把OSGI作为JSR，那么就能看出OSGI的未来。

       没有好与不好，只有适合和不适合，按需设计，简单事情简单做，才是设计最重要的原则。