《OSGi实战》读后感

看了下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、由于思想先进，在某些人看来是阳春白雪。估计不少人还是埋头下里巴人。观望态度。

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