Tin's Blog

You are coming a long way, baby~Thinking, feeling, memory...

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  128 随笔 :: 0 文章 :: 221 评论 :: 0 Trackbacks

看了下BlueDavy的OSGi实战这篇OpenDoc,很感谢BlueDavy同学!
例子举的是一个User Login的Case,例子很简单,让我们从中领略了OSGi的风情。这个Doc中的例子都是围绕Equinox展开的,它是Eclipse 3.1以后的核心实现,也就是说现在的Eclipse是个OSGi架构。
从架构上来说OSGi和SOA如出一辙,都强调面向服务,而OSGi似乎对热切换和契约管理比较着重,也就是说OSGi更现实,它强调的是一种实际的合约标准。产生的结果是差不多的,就是系统模块之间的高度解藕。
可以看OSGi的Core Framework,最内层是L0:运行环境(就是语言平台或者解释平台一类的环境),然后是OSGI的L1:模块,L2:生命周期管理,L3:服务注册。
我认为这种架构也基本上是一个SOA需要关注的几个问题。
L1是实现OSGi的基础,在Java下提供了类加载机制,使系统能够模块化。个人感觉类似原来Eclipse中的微内核。
L2是解决模块之间依赖关系的最基本工作单位,负责初始化、停止、更新等操作,这样模块能够活起来,同时在这些过程中可以手动维护依赖关系,也是模块协作的基础。
L3则是协作的合同签署场所,应该是L2的扩展,使模块之间能够按照契约工作。我觉得更形象地说就是路由器,模块间的动态依赖可以很好地通过它来解决,让OSGi可以动起来。
拥有了这几层,我想我们完全可以理解为一个SOA的实现,当然更细化。应该是一种新的组合应用的方式。
白嘴说肯定没有BlueDavy的文章好,大家还是去看看那篇文档。

说说遗憾:
1、OSGi在B/S架构中还不好应用。虽然例子是B/S的,可是居然是Servlet模型,里面解释了目前Equinox项目也在扩展应用服务器支持和JSP支持等,可是起码目前还不成熟。
2、模块的粒度很成问题。目前OSGi的契约机制与java interface机制对比一下。OSGi不可能完全取代本地的interface式的解藕,当然人家也没这么说。只使我担心过渡设计后,过细的Bundle肯定会得不偿失,所以需要有人设计/计划这个粒度。这个可能与基于Web services的SOA架构面临类似的问题,需要好的架构师。
3、文档不友好么?说实话,很感谢BlueDavy和OSGi观察者那些大牛的贡献。但是感觉production的样例工程还是很难搞到(其实Eclipse plugins的例子满多哈,可惜没啥文档,需要硬着头皮看),对应的指导文档还没出现。BlueDavy提供的servlet实现我们不可能跟上,毕竟简单也是一种需求。(那谁说过度设计比设计不足更可怕,那个我不是唱反调,我希望我们都能找到那个sweet point,有个好的参照那最好不过了)。
4、由于思想先进,在某些人看来是阳春白雪。估计不少人还是埋头下里巴人。观望态度。

结束,又是流水账,大家拍砖。

posted on 2006-09-06 11:27 Tin 阅读(4234) 评论(2)  编辑  收藏 所属分类: Other Project

评论

# re: 《OSGi实战》读后感 2006-09-06 20:18 BlueDavy
呵呵,仍然是那句话,OSGi对于Server Side app和企业应用而言提供的基础Bundle确实还不足,但这个是需要使用OSGi的同行们共同努力去充实的,至少我个人认为OSGi带来的好处已经可以弥补这方面的不足....
对于OSGi在B/S这块,我不认为会是多大的问题,OSGi业界完全可以提供一个MVC Framework的Bundle,在我公司的商业产品中就是自己实现了一个简单的MVC Framework....
文档来说目前确实还不够多,就如你所说的,缺少production的样例工程,近期我正考虑公布一个这样的project....
目前对于OSGi确实很多人都处于观望态度,不过大家可以看看IBM、Eclipse、Adobe等等公司的动作,再看看OSGi对JSR的影响,也许再不动手就迟了,呵呵,一家之言...  回复  更多评论
  

# re: 《OSGi实战》读后感 2006-09-10 22:34 Tin
差沙推荐了http://opensource.atlassian.com/projects/spring/secure/attachment/11891/spring_and_osgi.html。还是感觉目前OSGi的dynamically优势并不是中小Web应用最迫切需要的。超大Web应用估计可以从中获得好处。  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: