大家都知道Eclipse是一个典型的插件系统，而从3.0起其插件体系架构就重构为基于OSGI规范来实现的，从这也可以看出osgi必然与Plugin Architecture是有很多的关联性的，在这里就来说说自己对Osgi R3与Plugin Architecture的关联。
首先还是来说说作为一个Plugin Architecture应该提供哪些功能：
1、插件的定义。
2、插件的加载。(文件、URL等形式)
3、插件的生命周期管理。(安装、卸载、启动、停止、更新)
4、插件间的交互机制。
5、插件的扩展。
从非功能性角度来讲，作为Plugin Architecture应该对原有的非Plugin Architecture的系统的改造不能造成过大的侵入性，还有就是Plugin的管理以及易开发，其次作为Plugin Architecture，其最大的优点莫过于可以保证系统构成了一个平稳的结构体系，所有的交互、扩展都通过Plugin来进行，并同时保证各个Plugin的独立性，使得系统基于一种拼装式的结构(松耦合)，每个Plugin对于外部而言都是一个黑盒，那么就要相应的告诉外部这个黑盒所能提供的功能，调用的方式等。
现在来说说OSGI，Osgi规范于1999年开始制定，目前版本是R4，OSGI之前主要用于网络设备的服务架构体系，那是一个典型的松耦合的服务架构体系，在被eclipse引入作为其插件体系架构后OSGI也被业界所关注，R4更是吸取了Eclipse的很多优点修订而成，相对于上面的功能点来说说OSGI对应的规范点：
1、插件的定义。
OSGI规范中将插件称为Bundle，Bundle作为整个插件的生命周期管理对象，负责插件的启动和停止动作，通过Meta-inf/mainfest.mf来描述Bundle，主要描述Bundle的名称、厂商、版本、对外暴露的包、对外暴露的服务、依赖的插件、引用的包、动态引用的包等，具体可参考OSGI R4中Framework Specification Chapter，插件可通过Bundle对象获取插件的定义信息。
2、插件的加载。(文件、URL等形式)
OSGI规范中定义通过BundleContext来完成Bundle的加载工作，每个Bundle拥有独立的classloader以及BundleContext。
3、插件的生命周期管理。
OSGI规范中定义通过BundleContext对Bundle进行生命周期的管理，或通过Bundle本身对象来进行。
4、插件间的交互机制。
OSGI规范中定义通过插件的定义中定义所需依赖的插件以及所需引用的包来实现插件的交互机制。
5、插件的开发。
OSGI规范中定义一个新的插件的开发需要的是构成其BundleActivator对象以及完成插件定义的描述。
6、插件所暴露的功能。
OSGI规范中定义通过在插件定义文件中描述插件所暴露对外的服务来说明插件对外所暴露的功能以及允许外部对此插件引用的包。
对于插件如何扩展OSGI规范中提及的是在修改插件后插件的自动更新以及热加载来实现，而不是象Eclipse的扩展点机制。
根据上面我们可以看出OSGI规范确实非常适用于Plugin Architecture，对应点基本都存在，不过上面只是简单的描述，具体的大家可参看OSGI R4，除了对于Framework的定义，OSGI R4中还定义了一些常用的服务的规范(如log、configuration、security等)，而且有Eclipse作为其R4的RI，Eclipse则使得插件的管理、 扩展以及易开发得到了保证，在管理上Eclipse上提供了管理的平台，在扩展上eclipse上提供了扩展点机制，在易开发上eclipse提供了ide，使得插件的代码开发、定义描述、调试甚至部署都变得非常的简单，而且eclipse会根据插件定义文件中需引用的包以及依赖的插件而自动的构造相应的classloader而无需去引用那些lib，这保证了插件的独立性(设计时)，呵呵，但大家是不是有发现什么不足点呢？
个人觉得OSGI规范中的不足点是插件的管理机制的定义，插件的管理机制上我觉得可以参考JMX增加一个Connector or Protocol layer plugin，^_^
插件的扩展机制由eclipse弥补了，其他的还真想不出什么不足点了。
突然开始觉得osgi比jmx+ioc实现的plugin architecture更为的好，以前觉得osgi没有jmx+ioc好的原因在于osgi对于插件的独立性保持的不够，意思就是在插件对于外部或其他插件作为黑盒而言，没有明确插件功能的描述以及调用方式的描述，这个怪自己之前对osgi规范看的不够仔细，其实就是service，而在独立性方面以前是想着在代码中如果要直接调用其他插件的service，那岂不是要引用那个插件的包，而这个问题在eclipse ide中是解决了的，只需要在定义文件中定义所依赖的插件即可，而不需要引用那个包，那么这样独立性的问题自然也解决了，还有一个是管理性，在这方面仍然是jmx更为强，不过完全可以在osgi中增加一个admin plugin的实现，吸取jmx在这方面的优点，呵呵，而相比之下现在变成了jmx+ioc并没有一个规范式的体系架构，实现起来只能是各按各的想法，而osgi的话毕竟是个规范，加上已经有eclipse这个现成的，何必再去发明轮子呢，^_^，也许某一天plugin architecture也会被列入jsr规范之中的。