傳統方式下，我們可以在bundle的activator（bundle啟動時呼叫）中通過bundlecontext.registerservice()進行服務的註冊，通過servicereferencesr = bundlecontext.getservicereference() 和bundlecontext.getservice(sr)兩步得到服務。但這種方式有許多缺點：
1、產生較多重複**
2、在啟動時要例項化所有要發布的服務，影響啟動時間
3、有些註冊的服務在執行期間不會被用到，額外占用記憶體
4、增加了與osgi框架的耦合
osgi使用blueprint規範和宣告式服務解決這些問題。
一、blueprint：
1、服務發布
2、服務引用
blueprint的實現方式是在服務引用的時候建立乙個**，在呼叫此服務時通過動態**的方式呼叫。也就是說，即使服務的依賴還沒有得到滿足的情況下，也是可以發布服務的。而呼叫時，如果依賴的服務當前不可用，將會導致阻塞，直至依賴得到滿足或超時。
blueprint機制的乙個好處在於能夠應對在bundle更新期間服務取消和發布對框架的影響。除此之外，因為blueprint方式使用了**機制，因此服務必須要以介面的方式發布。
二、宣告式服務
<?xmlversion="1.0" encoding="utf-8"?>宣告式服務是一種元件模型，它簡化了元件的建立過程，這些元件會發布和使用osgi服務。我們需要以宣告的方式定義元件及其依賴，框架會基於依賴的滿足情況來管理元件的生命週期。這意味著，只有元件的依賴完全滿足的時候，才會處於啟用（activated）狀態，一旦依賴出現了缺失，元件就會處於停用（deactivated）狀態。因此，宣告式服務沒有使用**，但是能保證只要元件處於啟用的狀態，它的內部依賴就是已滿足的。//組建宣告以及其中的一些屬性
//實現類
//介面宣告
//依賴的服務，初始化服務時呼叫bind方法，服務停止時，呼叫
unbind
SAT外掛程式引用服務 發布osgi服務
osgi的服務層 service layer 為bundle之間的解耦合及服務引用提供的強大而又靈活的實現機制。通過bundleactivator控制項的生命週期，通過bundlecontext與其他元件和服務互動。但是，osgi服務層在提供強大的功能的同時，也給使用者造成了很大的困惑，比如，元件的...
OSGI動態註冊和建立服務
1 需要引入 org.osgi org.osgi 3.0.0 2 建立乙個工廠類實現介面managedservicefactory public class wservicefactory implements managedservicefactory public void setcontext...
OSGI 服務的發布和引用
一 在activator中註冊和引用服務 該方式可以說是最原始的方法，首先在manifest.mf中配置需要匯入的服務介面myservice import package org.jack.myservice 然後採用硬編碼方式註冊服務 public class myactivator implem...