模塊的可擴展性是模塊設計時需要重點考慮的非功能特性，對于框架而言，擴展性的設計則更加的重要，框架需要通過不斷的擴展來充實其基礎設施，構成真正的應用系統。
模塊的擴展主要有兩種，一種為擴充功能的擴展，另一種為覆蓋性質的擴展，當然，本質上而言是可以把這兩者進行合并的。
在模塊的擴展上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的方法更加有語義之外，暫時還真沒想明白。