OSGI与JMX 的关系

不过重点是：

JMX 本来设计的用途就只为了管理，我们不该把他拿来 (over use) 作为开发应用程序的组件 (那是 EJB 或 JavaBeans 该做的事)。但 OSGi 却可以! 

JMX 多数用于 server 系统中，而 OSGi 却不限于所开发的应用程序。你可以用它开发 embedded 系统、desktop 程序，甚至是 server 程序。 

OSGi 不但提供了与 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 采用Micro-Kernel 的架构，可以提供无限延伸的功能。OSGi 的 Bundles 在线更新功能、以及应用程序之微量内存执行能力，都是开发应用程序的利基。

行文至此，又觉得 OSGi 与 JCA、JNDI 都有一些功能重迭及互补之处。只是 JMX、JCA、EJB、JNDI都经 JCP 标准，都属于 J2EE 家族成员，但 OSGi 过去屈居于 Embedded System，声名就不若前述标准响亮...。我觉得这完全是两种思维模式：J2EE 的思维是 build on large scale，OSGi 的思维是 build on dynamic scale。OSGi 以小搏大。

为什么要用osgi，我认为主要是因为java至今没有出现一个方便易用的组件配置模型。过去，JMX、ClassLoader、reflect都似乎可以做这个事情。但是，JMX太麻烦了，况且原本为J2EE准备的JMX，确实不太易用，走专用的协议，需要专门的客户端，需要adapter来访问等等....

而ClassLoader，单独用ClassLoader，需要自己在其上构建一层包装，否则用起来很麻烦。Reflect的配置方式和ClassLoader一样的问题 。

但是，所有java的组件配置方式，包括使用classloader的osgi在内共有的一个问题就是，被替换组件的回收时间无法控制。 

JMX 与 OSGi 在功能上的许多重迭之处，在国外已经有人讨论过 (例如 Eclipse Embeds OSGi Based MicroKernel 及 JMX vs. OSGi - The New Flavor of the Eclipse Runtime)。