前段時間公司產品在apache的孵化項目tuscany的基礎上，做了一些擴展了自己的一些實現。在項目中發現模塊的動態更新帶來的模型之間的依賴關系處理比較復雜；沒有一套好的機智處理這種模塊動態的更新，部署，以及解決他們之間的關系。
Osgi的框架很好的解決了上面的問題，更夠搭建動態化的系統可以說是OSGI在sca的部署策略上的一種很好的參考實現。
OSGI規范中包括很多層，安全層，Module 層，生命周期層，服務層等等
這里主要對服務層（service layer）做一下介紹
服務層定義了一個動態的協作模型，服務模型是定義在模塊（bundle）的基礎上的。
Bundle可以動態的發布，查找service，并且當該服務的狀態（生命周期）改變時，更夠發出通知，這樣所有對該service關心的bundle，可以通過注冊監聽器的方式，接收消息，做后續的處理。
下面是它的模型
下面簡單的加以說明：
在osgi平臺中，各個模塊（bundle）可以提供服務，并且可以引用其他的服務，而這些服務都有統一的管理注冊中心（ServiceRegistry），該注冊中心由框架提供，運行在框架之上的。
這樣的一些服務都是歸bundle所有并且運行在它的bundle上的；所以可以通過bundle的bundlecontext把這些服務注冊在ServiceRegistry中，以便能夠由框架統一管理，并且能夠被其他的bundle所引用。這樣當bundle的生命周期發生變化的時候，如stop，那么就能夠通過框架，來自動的卸載提供的服務，并且解決好bundle之間的服務引用依賴關系。
服務對象serviceobject，類似與pojo，調用它的接口，可以提供服務。這樣的一個serviceobject可以實現ServiceFactory接口，也可以實現其他的接口。如果實現了ServiceFactory，那么對于每一個bundle對服務的引用來說，都是一個通過ServiceFactory創建新的實例。否則所引用的服務對象就是通過bundlecontext注冊的綁定在ServiceRegistration 的原始對象。
ServiceReference類似于服務對象的句柄，通過它可以查找到真實的服務對象。其實它只是包含了對對象的描述，如該服務是位于哪一個bundle上的，該服務的bundle是否已經停 止，以及服務的描述等等。
對于引用該服務的bundle來說，只是保存的service的句柄，真實的service對象可以不存在，這樣的模式被廣泛應用在動態的環境中。
ServiceListener可以通過BundleContext注冊在框價ServiceRegistry中，這樣在服務的生命周期改變時候，可以接收消息，每個bundle可以在自己的lisitener里，做出相應的處理，如釋放響應的資源等等。
BundleContext提供了注冊服務，注冊服務，框架，bundle的監聽器，查找服務的統一入口。
暫時寫這么多，待敘