Eclipse中的扩展点机制存在的理由

文章转自：http://java.chinaitlab.com/Eclipse/759607.html 中国IT实验室

众所周知，Eclipse平台本身就作为一个成功的OSGI应用，从技术层面讲，Eclipse本身就是由OSGI协议驱动的（我想，这句话大家已经听的很多遍了~_~）。同时Eclipse对OSGI组件机制做了有力的扩充，也就是我们所熟知的扩展点（Extension Point）机制，关于扩展点的支持也作为Equinox（Eclipse的OSGI协议实现）一部分呈现给了广大的Eclipse开发者和用户。关于为什么会存在扩展点这个补充，也是国外技术论坛上经常讨论的话题，在这也斗胆猜测一把，仅供大家参考。

「OSGI的关键特性和适用场景」

OSGI为我们提供了一个追求模块化的方式来开发、部署、运行、管理组件（OSGI Bundle）的机制，其主要的技术特征包括模块化、生命周期管理、松耦合交互等。OSGI为我们提供了组件模块化所需要的技术，并允许以服务等方式来实现模块之间的动态松耦合交互，这也就为我们开发盼望已久的Pluginable System打下了坚实的基础（有关OSGI的技术，可以参加OSGI协议和国外论坛上的一些关于OSGI具体应用的讨论）。本质上讲，OSGI在追求组件模块化，并希望组件本身具备黑盒的效果，其并没有投入很大精力来关注如何让一个组件更容易扩展，更加开放。

通过上面的阐述我们可以看出来，OSGI本身适用于那种建立模块化、动态管理、即插即用的组件化系统，如果应用于产品软件的开放，对建立一个可靠的内核是非常有用的，OSGI对应的一些成功应用包括 Eclipse、JBoss AS、IBM Websphere等。

「Eclipse的需求」

Eclipse本身作为一个基础平台存在，其关键需求就是来方便用户扩展，并能够很方便的和Eclipse平台本身做无缝集成。说白了，在Eclipse中一个组件（Eclipse Plug-in）的任务大致为二：提供扩展实现或者声明扩展需求（当然，不完全针对库插件、feature…）。我们知道，一个软件产品的技术实现必须要以符合产品需求为基础，Eclipse作为一个软件产品最大的需求就是如何方便的允许用户扩展并无缝地集成这些扩展。

如果要满足Eclipse的这种需求，需要一个组件（Eclipse plug-in）还需要具备什么关键特质呢？开放、易扩展！！！

显然，OSGI本身并不能满足Eclipse的部分关键需求（面向开发者和用户的需求），但是OSGI所带来的模块化、声明周期管理、懒加载等机制都是Eclipse迫切需要的，自然选择了OSGI来作为Eclipse内核的驱动协议。考虑到扩展和便于无缝集成这两大关键需求，Eclipse在OSIG之上面向用户提供了扩展点的机制，以一种xml描述的方式来配置组件之间的扩展关系，涉及到的三个核心概念便是我们熟知的：扩展点（Extension Point）、扩展（Extension）和扩展注册表（Extension Registry）。

「实例讨论」

上面说了一些偏于抽象的东西，下面配合几个实例来大致说明一下。

首先我们讨论一个偏于理论的例子，假设我们现在当前系统有两个OSGI bundle，再加入第三个陌生的bundle，那这个新的bundle是不能被自动发现的（auto-discovered，自己发明的~_~），除非在被显示调用的情况下。同比，如果当前系统中有一个plug-in，其本身声明了一个扩展点（host plug-in），然后系统中引入了一个新的plug-in，按照host plug-in定义的扩展契约提供了扩展（extesion plug-in），那么这个新的plug-in是可以被自动发现的，host plug-in可以借助eclipse扩展注册表查找对应的扩展，而同时避免了两个plug-in之间的紧密耦合（说明：有人以为extension plug-in和host plug-in之间是紧密耦合的，我觉得更合适的说法是plug-in是开发的）。

我们知道Eclipse本身的体系架构是：微内核（micro kernel）、核心插件（core plug-ins）和用户应用插件（application plug-ins）。

上图中的runtime、workbench和resource就是Eclipse所谓的核心插件，而JDT恰恰是在这些核心插件的基础上提供扩展，并做无缝集成；同时也定义了一些扩展点，供JDT自身或者其他扩展插件使用并做无缝集成。

对普通Eclipse工具用户而言，如果没有扩展点的机制，用户能够方便的将第三方工具安装（本质上是集成）到Eclipse中吗？是不是要关心一些技术细节啊？

「总结」

上面，一直在说Eclipse plug-in在OSGI bundle的基础上在追求开放和扩展，其实从技术本质上讲，Eclipse是对OSGI协议在插件间的交互方式做了补充，扩展和扩展点也成为了我们在Eclipse插件开发过程中最主要的插件间交互方式了，而OSGI中定义的组件间松耦合交互方式（OSGI Service）却并没有很大的用武之地（对用户而言）。说到这里，可能会给大家造成一个疑问： Eclipse扩展点机制这么好，为什么不加入OSGI协议呢？需求不同。

最后再回顾一下，Eclipse之所以提供了扩展点机制，本质上取决于Eclipse自身的部分关键需求：扩展和集成。OSGI协议本身尤其应用场景，Eclipse的扩展点机制是针对Eclipse自身需求在OSGI之上做的有力补充。