讨论：关于OSGi Based 应用服务器

eclipse是不是基于osgi了啊，每次update一个插件，都强烈要求我重启eclipse来着。不过我倒是无所谓。
我觉得能不能热拔插还是要看业务逻辑。如果2个插件之间没什么依赖关系的时候，你的确是可以热拔插任何一个的的。否则，情况就很难说了。
另外，我觉得windows的系统服务就是跟这个osgi的东西很类似。

问题就在于依赖关系部分
拿Eclipse说明，因为支持扩展点（其实象JDK6引入的Service也是一样）
就表示你对象的实例有可能被其它的Bundle持有
也就是说只有一个Bundle中的对象或者类被其它Bundle或者系统拥有
几乎肯定这个Bundle就不可能dispose。
所以OSGi的热加载是可能的，但目前看来热替换不现实
可以说热插不能热拔

整理邮件，发现前段时间回复同事的一段话，是关于网上一篇文章说“OSGi将成为下一个EJB么？”引发的，原文在CSDN上，下面是我的邮件中的回复。

1、EJB和OSGi的设计目标本身就不一样，前者一直是在为整个企业做中间层，而后者现在的目的则是以一个标准去模块化地架构一个系统，所以与其说OSGi是一个标准，不如说它更是一种软件思路的体现。
2、EJB最重要的内容是什么?是EJB Container，这也是EJB重的一个根本原因。而OSGi最重要不是OSGi Container，而是Bundle，事实上Bundle几乎与普通的Jar包没有区别，所以它没有轻重之说。
3、至于作者说Bundle附加的限制，这个我觉得在任何一个体系结构中都是不可能避免的。象多ClassLoader结构，即有好处，也有坏处，就要看具体的环境了，就象某些环境下，用EJB仍然是最佳的选择一样，如果应用程序体系结构本身就不需要集群，不需要复杂事务等等一系列内容，EJB就用不上。同样如果程序不能很好的划分模块，特别是涉及到遗留系统，那么OSGi可能也不合适。
4、EJB之所以被骂，更多是因为不负责任的宣传，不过现在OSGi也出现一些不负责任的宣传，也就是说不加思考就直接使用某个系统或者框架，那么不管是EJB，还是OSGi，或者Spring，都会被骂!

恩，我也这么想，OSGI在‘开放’的‘平台’上才有意义，热插拔，只是手段而已，而且，似乎java没有什么真正严格意义的安全的热插拔技术，如果有，望告知，呵呵。

1,可以尝试自己做“热更新的”系统缓存，至少俺试过，可行。不知道你值得“安全热插拔”有啥特殊的？java在这点上跟其他语言有啥差异？
2，如：WebSphere等商用app server就确实支持应用的热部署啊，难道不能算“热插拔”？

“热更新的”系统缓存？能讲具体点吗？

中间件之所以，能做到热加载，取决于它维护的一套庞大而复杂的ClassLoader，隔离性好些，才能热加载。如果交叉的引用，一样加载不了。

而且，就算热加载后，状态也是要丢失的诶，这怎么安全呢？

我的理解跟你有所不同，热加载是指用户在使用过程中，系统的新版本发布，但不影响用户使用。在线用户仍然处理在旧系统的实例上，直到一笔业务完成；新发起的请求则指向新的系统。

如何保证新的应用实例是安全的呢？比如你的代码里存在静态数据，而这些数据是功能依赖的，在热部署后，状态丢失，新的代码还能正确跑起来吗？

当然，可以通过ClassLoader去制造一个相对隔绝的应用环境，但是也是没法完全保证所有的引用是隔绝的，同时也没有办法替换新的状态，存在诸多限制，对应用代码来说，不是完全透明的机制。不能说，中间件有热部署功能了，就可以放心的更新代码了

OSGi热部署实现原理我的文章里有介绍：http://yipsilon.iteye.com/blog/361660

OSGi规范中定义可以使用BundleContext.getAllServiceReferences方法来获取所有的同名服务，如果你的旧插件中存储有状态，使用上述方法可以获取到旧插件对象，然后新旧插件之间进行一下状态更新不就可以了。

假设有一个Bundle称为A，可以被另外Bundle称为B的来热更新
问题是谁来负责状态更新啊?
是A吗？不应该是，因为A和B应该没有严格的约束关系？
是B吗？也不应该是，原因同上
OSGi容器吗？问题在于，谁知道哪些状态要更新，更新的方式是什么呢？可以想一下J2EE的Session，它做HotDeploy的方式也可以算是一种热更新，但我觉得目前所谓J2EE服务器所谓的HotDeploy基本是个玩具（过分一点说，可以说是笑话），而且如果更新失败，又怎么处理呢？
再比如说，现在有代码持有了Bundle A中的某个服务对象，那么怎么办呢？

大家如果有兴趣的话，可以查一下JDK的历史，它曾经有一个版本，是1.1的某个版本，支持Class的Unload和Reload，结果后来又放弃了，然后给出了一个严格的Class对应的Unload和Reload规范，现在几乎不可能做到Class的Unload和Reload了。有兴趣的朋友可以查一下这段历史，有些意思的。