基于OSGi实现可扩展的模块的设计

模块的可扩展性是模块设计时需要重点考虑的非功能特性，对于框架而言，扩展性的设计则更加的重要，框架需要通过不断的扩展来充实其基础设施，构成真正的应用系统。
模块的扩展主要有两种，一种为扩充功能的扩展，另一种为覆盖性质的扩展，当然，本质上而言是可以把这两者进行合并的。
在模块的扩展上Eclipse的扩展点的设计方式无疑是支撑模块可扩展的经典设计方法，到现在为止仍然是如此，基于Eclipse的扩展点的设计无论是对于扩充功能的扩展还是覆盖性质的扩展都支持的非常好，这个经典的设计也是RCP得到那么多client side app的原因之一，尽管OSGi中并没有定义这方面的规范，但做为OSGi R4的RI的Equinox考虑到更好的支撑Bundle的扩展就引入了Eclipse的扩展点的设计，在现在的Equinox中我们仍然可以基于Eclipse的扩展点的方式来支撑模块的可扩展性。
但是否有别的方法呢？一定需要Eclipse的扩展点的方式吗？其实个人觉得基于OSGi的Service就已经天然的构成了一种可扩展的设计，为什么这么说呢？
首先来看看基于Eclipse扩展点的方式是如何支撑模块的可扩展性的：
1、定义模块的扩展点接口和xml的schema规范；
2、在模块需要提供扩展的地方调用所有扩展点接口的实现，并加载执行其中的一些方法。
通过这两步就使得模块具备了可扩展性，典型的象Eclipse中的菜单、按钮、帮助窗口等等....
当需要增加新的菜单、按钮时，只需要实现相应的扩展点接口，然后按照schema规范相应的配置xml文件就可以了。
而基于OSGi的Service的方法怎么样去支撑模块的可扩展性呢，其实做法和Eclipse的扩展点的方式几乎就是一样的：
1、定义模块的扩展点接口；
2、在模块需要提供扩展的地方调用所有对外提供了此扩展点接口的服务组件，加载执行其中的方法。
      这一步有两种做法，一种是通过bundleContext获取服务的方法，另外一种是通过DS的方法，相比而言自然是DS方法操作起来更加简单，原因在于采用DS的方法的时候当服务发生动态的变化时OSGi框架会主动的调用该组件中的相关方法，而采用BundleContext方法的话则需要自己主动监听相应的事件。
同样是通过这样简单的两步就可以实现模块的可扩展性。

这样就产生了一个问题，既然是这样，为什么还需要之前Eclipse的扩展点的设计呢？除了扩展点相比采用OSGi的Service的方法更加有语义之外，暂时还真没想明白。