OSGI
Eclipse 3.0后采用的是OSGI来作为其Plugin Architecture实现的依据，鉴于此就得简单提提OSGI了，主要从Plugin的角度来分析OSGI，OSGI概念中主要分为了Bundle和Service，可以认为Bundle是一个模块的管理器，主要是通过BundleActivator管理模块的生命周期，而Service则是这个模块可暴露对外的服务对象，这里体现了OSGI和传统的Plugin Framework不同的一个地方，管理和静态结构分开，在OSGI中通过在manifest.mf文件中增加一些内容来发布Bundle，在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露对外的包、所依赖的包；每个Bundle拥有自己的ClassLoader以及context，通过context可进行服务的注册、卸载等，这些操作都会通过事件机制广播给相应的其他的Bundle；一般来说都为通过在Bundle中编写初始需要注册的服务的方法来完成Bundle可供外部使用的服务的暴露功能；如需要调用其他Plugin提供的服务可通过context的getServiceReference先获取Service的句柄，再通过context.getService(ServiceReference)的方法获取Service的实体。

Eclipse Plugin定义
Eclipse中的Plugin的概念为包含一系列服务的模块即为一个Plugin。既然是遵循OSGI的，也就意味着Plugin通常是由Bundle和N多Service共同构成的，在此基础上Eclipse认为Plugin之间通常存在两种关系，一种为依赖，一种为扩展，对于依赖可通过OSGI中元描述信息里添加需要引用的Plugin即可实现，但扩展在OSGI中是没有定义的，Eclipse采用了一个Extension Point的方式来实现Plugin的扩展功能。
结合OSGI
Eclipse遵循OSGI对于Plugin的ID、版本、提供商、classpath、所依赖的plugin以及可暴露对外的包均在manifest.mf文件中定义。
Plugin Extension Point
对于扩展，Eclipse采用Extension Point的方式来实现，每个Plugin可定义自己的Extension Point，同时也可实现其他Plugin的Extension Point，由于这个在OSGI中是未定义的，在Eclipse中仍然通过在plugin.xml中进行描述，描述的方法为通过<extension-point id="" name="" schema="">的形式来定义Plugin的扩展点，通过<extension point="">的形式来定义实现的其他Plugin的扩展点，所提供的扩展点通过schema的方式进行描述，详细见eclipse extension-point schema规范，为了更好的说明扩展点这个概念，举例如下，如工具栏就是工具栏Plugin提供的一个扩展点，其他的Plugin可通过此扩展点添加按钮至工具栏中，并可相应的添加按钮所对应的事件(当然，此事件必须实现工具栏Plugin此扩展点所要求的接口)，工具栏的Plugin将通过callback的方式来相应的响应按钮的动作。可见通过Extension Point的方式可以很好的提供Plugin的扩展方式以及实现扩展的方式。

Eclipse Plugin Framework
那么Eclipse是如何做到Plugin机制的实现的呢？？还是先讲讲Eclipse的设计风格，Eclipse在设计时有个重要的分层法则，即语言层相关和语言层无关的代码分开(如jdt.core和core)，核心与UI分开(如workbench.ui和workbench.core)这两个分层法则，这个在Eclipse代码中处处可见，在Plugin Framework部分也充分得体现了这个，遵循OSGI，Eclipse首先是实现了一个OSGI Impl，这个主要通过它的FrameWork、BundleHost、ServiceRegistry、BundleContextImpl等对象来实现，如果关心的话大家可以看看这部分的代码，实现了Bundle的安装、触发、卸载以及Service的注册、卸载、调用，在Plugin机制上Eclipse采用的为lazy load的方式，即在调用时才进行实际的启动，采用的为句柄/实体的方式来实现，外部则通过OSGI进行启动、停止等动作，各Plugin则通过BundleContext来进行服务的注册、卸载和调用，这是OSGI的部分实现的简单介绍。
那么Extension Point方面Eclipse是如何实现的呢，在加载Plugin时，Eclipse通过对plugin.xml的解析获取其中的<extension-point>节点和<extension>节点，并相应的注册到ExtensionRegistry中，而各个提供扩展点的Plugin在提供扩展点的地方进行处理，如工具栏Plugin提供了工具栏的扩展点，那么在构成工具栏时Plugin将通过Platform.getPluginRegistry().getExtensionPoint(扩展点ID)的方法获取所有实现此扩展点的集合IExtensionPoint[]，通过此集合可获取IConfigurationElement[]，而通过这个就可以获取<extension point="">其中的配置，同时还可通过IConfigurationElement创建回调对象的实例，通过这样的方法Eclipse也就实现了对于Plugin的扩展以及扩展的功能的回调。在Plugin Framework中还涉及很多事件机制的使用，比如Framework的事件机制，以便在Bundle注册、Service注册的时候进行通知。

总结
通过对Eclipse启动过程的分析，可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式，在代码中分别对应为loadBasicBundles和registerApplicationServices，loadBasicBundles通过加载config.ini中的osgi.bundles完成基本的bundles的加载，去看看这个配置会发现是org.eclipse.core.runtime还有一个update，core.runtime又会通过IDEApplication来完成整个Eclipse的启动，同时会注册所有与workbench相关的plugin。
Eclipse由于以前版本的Plugin Framework是没有采用OSGI的，所以通过EclipseAdaptor的方式来实现与以往的兼容，目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息，Plugin.xml描述扩展点的信息。
Eclipse中有非常多优秀的设计，这个在看它的代码时会有很深的感触，比如Contributing to Eclipse中提到的Extension Object/Interface的设计，确实是非常的不错，虽然看到你可能觉得很简单，关键是要想得到并合适的去使用。
总结陈词，^_^，Eclipse Plugin Framework是采用OSGI Impl+Plugin Extension-Point的方式来共同实现的，实现了Plugin的部署、编写、独立的Classloader和Context、Plugin中Service的注册、Plugin中Service的调用、Plugin的依赖、Plugin的扩展、Plugin生命周期的管理。

带来的思考
Eclipse Plugin Framework采用的是OSGI的实现，一定程度上我们也能看到OSGI的优点，那么JMX+IoC方式的Plugin Framework与其的比较又是在哪些方面呢？Eclipse Plugin Framework不足的地方又在哪里呢？哪些地方值得改进呢？

看到即插即用这么几个字，但真的又有多少软件做到了呢，当然，不可否认的是也有部分的软件确实做到

了，而且做的很好，例如Eclipse，知名的插件式系统，还有象maven这些都是，其实portlet container

那些也都是的，列举出来还真的有不少。插件式系统带来的好处很明显，最大程度的重用，为快速的搭建

系统提供帮助，潜在的好处在于要求系统以插件式的方式进行设计，帮助你更好的做到模块化的划分以及

帮助系统达到良好的封装性。

需求
要做Plugin Architecture，首先需要做的是如何考虑Plugin，其实也就是需求，要看你是怎么看待一个

Plugin的，认为一个Plugin应该是怎么样的，认为Plugin是怎么样被组装起来构成系统的，这个时候需要

的是大家从需求的角度来提出要求，不要从技术角度来提。一个系统既然是按照Plugin的方式搭建出来，

那么首先需要知道的是就是Plugin能提供什么样的功能，这些功能需要什么参数，这是最基本的，其次是

如何去管理这个Plugin，包括修改它的配置参数，对它的生命周期进行管理(启动/暂停/停止等)，这是以

单独的Plugin角度来看，如果这个Plugin又得调用其他Plugin提供的功能，那么应该怎么去做，考虑了这

些后又会想到Plugin应该怎么去部署、怎么去自动升级。从扩展方面我们又会考虑到那么我要如何去扩展

一个Plugin呢，这也是很关键的。这都只是简简单单的提了一些Plugin的需求，归纳上面的需求可以得出

主要的几点就是Plugin的功能的暴露、Plugin的管理、Plugin的调用、Plugin之间的协作、Plugin的部署

、Plugin的扩展这几个大的方面。

技术简介
现有的可参考的Plugin Architecture还是有比较多的，例如Eclipse、Geronimo、Maven、Pluto等等，这

些都是做的比较好的插件式的系统，在这里主要讲讲Eclipse如今使用的Osgi和Geronimo所使用的JMX+IoC

方式实现的Plugin Architecture，应该说两者各有千秋，重点还是看对于Plugin的需求到底是怎么样的

，Osgi规范将系统按照Bundle的方法进行组装，每个Bundle下包含了一系列的Service，通过编写Bundle

完成对于Bundle的管理(Start、Stop)，而Service则为Bundle所能提供对外的功能，通过MANIFEST.MF这

个标准的jar包描述文件来描述bundle所能提供的功能以及一些元数据信息，由于对Osgi研究不深，也只

能大概的提提这些了，Eclipse在3.0以后的版本开始采用Osgi，并兼容其原有的Plugin方式，可以通过阅

读Eclipse源码去了解关于基于Osgi来实现Plugin Architecture的方式，Eclipse是基本实现了上述需求

部分的，不过个人认为在plugin的管理、plugin之间的协作、plugin的部署上还可以加强；接下来提提

JMX+IoC方式，对JMX稍有了解的人都知道JMX被大量的应用服务器所使用，如Jboss、Tomcat、Weblogic、

WebSphere等等，数不胜数，JMX强调的是一个管理概念，对JMX不在此详细的介绍，但其实它同样是一个

Plugin的概念，依照JMX系统可以编写MBean的方式来暴露Plugin的功能，并实现对于Plugin的管理(各种

方式，http、rmi等等)、Plugin的调用、Plugin的部署，那么为什么要引入IoC呢，IoC帮助实现Plugin之

间的协作，并且是通过注入的方式来实现，IoC也不在这里详细的去描述了。

总结
通过对上面两种实现Plugin Architecture的简介，分别都实现了需求中的内容，但都有提升的余地，个

人认为Osgi的方式需提升对于Plugin管理的关注(不仅是生命周期管理)、而JMX+IoC方式则需提高对于

Plugin内部结构的关注(就象Osgi将Plugin分解为了Bundle和Service)，至于Plugin的扩展方面觉得

Eclipse的Extension Point是非常不错的一个设计，不过同时也看出在Plugin Architecture的实现上基

本都采用了管理和静态结构分离的方法，其实这个好处是非常明显的，可以快速的将系统原有的模块通过

编写一个管理类的方法就可作为plugin放入系统中，这提升了简便性，当然最大的作用还是分清了职责，

说一句题外话，职责单一一直是软件设计的重中之重，此文纯属抛砖引玉，希望能听到更多关于Plugin

Architecture的声音，也希望大家都关注Plugin Architecture，最近也出了一个JPF，不知道大家是否有

所了解。

可快速开发一个插件，尽量少的对现有系统的侵入。在此平台上可快速的进行插件的开发，尽量减少对于系统的侵入，有良好的开发向导和开发IDE。

可轻松的进行插件的部署。当开发完毕一个插件需要部署至平台上时，此步骤应尽量的简单。

简单的调用其他插件。对于平台中其他可用的插件的调用应尽可能的依赖并保持插件的独立性。

简单的被调用。其他插件或应用需要调用时应可简单的被调用。

可进行测试、调试。可进行单元测试、调试，使得开发时更加的简便。

可被扩展。插件可被扩展，方便将来可对此插件进行功能上的完善和改进。

可分布式的部署，并支持多种方式调用(Webservice、JMS)。使得插件可部署在远端，实现分布式的物理结构。

可自动的升级。插件可自动的升级，减小对于插件的维护并保证插件功能的最新。

可被管理，安装、卸载、启用和暂停使用。使得用户可对插件进行选择性的配置。

插件异常的管理。保证插件在产生任何异常的情况下均可对其进行捕捉并友好的提示用户。

插件日志。在插件的使用过程中记录下足够的日志，方便将来对于插件的分析。

         通常一个Plugin Framework的职责就是：

1、   搜索相应目录，并将目录下可作为Plugin的部分注册到Plugin Framework中

2、   提供外部调用Plugin的方法

3、   Plugin之间相互交互的方法

4、   Plugin的加载，根据其描述构建相应的ClassLoader

5、   Plugin的编写说明

当然，一个好的Plugin Framework应该还提供Plugin开发向导，Plugin开发、调试、部署的IDE等等

         主要希望就下面几点来进行讨论，呵呵，当然，大家也可以增加一些大家认为值得讨论的部分：

1、   Plugin的编写

你构思中一个好的Plugin System会要求Plugin如何编写，我考虑中一个好的Plugin System对Plugin没有任何编码上的要求，要求的只是其描述文件的编写。

2、   Plugin的部署

Plugin的部署，如何更加方便的去部署一个Plugin，就象Osgi可以通过网络访问等等，考虑中根据配置从相应的目录或网站搜索Plugin并注册到系统中

3、   Plugin的调用

对于Plugin的调用，根据Plugin的描述采取相应的方式调用Plugin，例如webservice方式、socket方式等等

4、   Plugin的交互

对于Plugin的交互，也许可以参考Maven的方式，比如需要调用其他的plugin，则采用类似这样的配置或调用<attain plugin=”pluginname” function=”sendmail”/>抑或采用IoC容器注入依赖？？

5、   Plugin的扩展

对于Plugin的扩展，这个Eclipse的扩展点完全值得参考

6、   Plugin的依赖关系的分析