基于OSGI做真正面向接口的開發
是否能夠真正做面向接口的開發,和系統所采用的容器或框架具有很大的關系,面向接口的開發最重要的就是解決系統的依賴問題,在這點上目前最成熟的解決方案莫過于IoC,IoC容器而言最成功的莫過于Spring,那么基于OSGI的話是不是會帶來不同的視角呢,來看看這幾個方面的例子:
1、A類希望能夠執行系統中實現了B接口的類
????? 在OSGI中實現這種是多么的簡單,可以看看:
????? ServiceReference[] serviceRefs=context.getServiceReference(B.class.getName());
????? for(int i=0;i<serviceRefs.length;i++){
?????????B b=(B)context.getService(serviceRefs[i]);
???????? b.execute();
????? }
????? 用習慣了IoC的人都會去說上面的方法還需要通過context主動獲取這么的爛,那么在OSGI中你同樣可以用下面的這樣一種方式去調用:
????? public void setService(B b){
??????????? b.execute();
????? }
????? 這樣的方式滿意了吧,在這樣的情況只需要將這個類對于B的引用配置為cardinality="0..n",那么OSGI框架就會自動的去完成調用實現了B接口的類的execute方法。
????? ps: 可以想象基于這樣的方式要實現COR Pattern是多么的容易....
2、A類引用了Log接口,但無所謂系統中有否Log接口的實現此類都需要正常運行
????? 在OSGI中要做到這個同樣是非常的容易:
????? public void setLog(Log log){
?????????this.log=log;
????? }
????? 只需要將這個類對于Log的引用配置為:cardinality="0..1"
3、A類希望根據某種條件來決定到底調用哪個實現接口的類
????? 在OSGI中可以通過象屬性過濾、版本過濾等多種方式來動態的決定調用相應的實現接口的類,可以想象有這種來實現類似的業務邏輯的處理是不是更加的簡單和方便呢。
4、動態性
????? 這個自然是因為OSGI 帶來的特性,在基于OSGI構建的這樣的系統中,我們完全可以先定義好接口,然后啟動整個系統,當完成了某個接口的實現后,部署到OSGI框架中,再使用此接口的功能后自然就可以直接使用了,整個系統完全無需進行重啟等麻煩的操作。
從以上簡單的幾個例子可以看出,基于OSGI做真正的面向接口的開發變得非常的容易和靈活,而動態性特征更是使得可以完全以接口的方式先搭建好系統,這對于迭代式的開發模型來說非常的重要。
為什么說這樣的方式才是真正的面向接口的開發呢,可以看到在傳統的開發方式中,無論怎么樣,都仍然是要先有實現了接口的類后系統才可運行,而在基于OSGI的開發中完全不需要,在基于OSGI的系統中開發人員可以確定當需要的接口的實現都提供了后,功能自然就是實現了的,而無需管系統中是否具體有接口的實現,更為重要的一點是由于傳統的開發方式多是在運行前定義好依賴關系,而在基于OSGI的系統很容易實現運行期才決定依賴關系,這對于提升系統的靈活性的效果不言而喻。
ps:我知道很多spring高手在看了上面的例子后會告訴我基于spring也可以去實現上面的這些例子,但是不是要做出更多的增強呢,spring本身并沒有classloader的完整機制,所以要基于它去實現這些動態的特征的時候會變得很復雜,而既然現在OSGI已經提供了這些,為什么一定要基于spring去增強來達到這些已經在OSGI中達到的目標呢?
1、A類希望能夠執行系統中實現了B接口的類
????? 在OSGI中實現這種是多么的簡單,可以看看:
????? ServiceReference[] serviceRefs=context.getServiceReference(B.class.getName());
????? for(int i=0;i<serviceRefs.length;i++){
?????????B b=(B)context.getService(serviceRefs[i]);
???????? b.execute();
????? }
????? 用習慣了IoC的人都會去說上面的方法還需要通過context主動獲取這么的爛,那么在OSGI中你同樣可以用下面的這樣一種方式去調用:
????? public void setService(B b){
??????????? b.execute();
????? }
????? 這樣的方式滿意了吧,在這樣的情況只需要將這個類對于B的引用配置為cardinality="0..n",那么OSGI框架就會自動的去完成調用實現了B接口的類的execute方法。
????? ps: 可以想象基于這樣的方式要實現COR Pattern是多么的容易....
2、A類引用了Log接口,但無所謂系統中有否Log接口的實現此類都需要正常運行
????? 在OSGI中要做到這個同樣是非常的容易:
????? public void setLog(Log log){
?????????this.log=log;
????? }
????? 只需要將這個類對于Log的引用配置為:cardinality="0..1"
3、A類希望根據某種條件來決定到底調用哪個實現接口的類
????? 在OSGI中可以通過象屬性過濾、版本過濾等多種方式來動態的決定調用相應的實現接口的類,可以想象有這種來實現類似的業務邏輯的處理是不是更加的簡單和方便呢。
4、動態性
????? 這個自然是因為OSGI 帶來的特性,在基于OSGI構建的這樣的系統中,我們完全可以先定義好接口,然后啟動整個系統,當完成了某個接口的實現后,部署到OSGI框架中,再使用此接口的功能后自然就可以直接使用了,整個系統完全無需進行重啟等麻煩的操作。
從以上簡單的幾個例子可以看出,基于OSGI做真正的面向接口的開發變得非常的容易和靈活,而動態性特征更是使得可以完全以接口的方式先搭建好系統,這對于迭代式的開發模型來說非常的重要。
為什么說這樣的方式才是真正的面向接口的開發呢,可以看到在傳統的開發方式中,無論怎么樣,都仍然是要先有實現了接口的類后系統才可運行,而在基于OSGI的開發中完全不需要,在基于OSGI的系統中開發人員可以確定當需要的接口的實現都提供了后,功能自然就是實現了的,而無需管系統中是否具體有接口的實現,更為重要的一點是由于傳統的開發方式多是在運行前定義好依賴關系,而在基于OSGI的系統很容易實現運行期才決定依賴關系,這對于提升系統的靈活性的效果不言而喻。
ps:我知道很多spring高手在看了上面的例子后會告訴我基于spring也可以去實現上面的這些例子,但是不是要做出更多的增強呢,spring本身并沒有classloader的完整機制,所以要基于它去實現這些動態的特征的時候會變得很復雜,而既然現在OSGI已經提供了這些,為什么一定要基于spring去增強來達到這些已經在OSGI中達到的目標呢?
posted on 2006-08-19 18:07 BlueDavy 閱讀(2885) 評論(3) 編輯 收藏 所屬分類: OSGi、SOA、SCA