模塊的可擴展性是模塊設計時需要重點考慮的非功能特性，對於框架而言，擴展性的設計則更加的重要，框架需要通過不斷的擴展來充實其基礎設施，構成真正的應用系統。
模塊的擴展主要有兩種，一種爲擴充功能的擴展，另一種爲覆蓋性質的擴展，當然，本質上而言是可以把這兩者進行合併的。
在
模塊的擴展上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方法的話則需要自己主動監聽
相應的事件。
同樣是通過這樣簡單的兩步就可以實現模塊的可擴展性。
