OSGI Module&lifecycle
OSGI概念中主要分為了Bundle和Service，可以認為Bundle是一個模塊的管理器，主要是通過BundleActivator管理模塊的生命周期，而Service則是這個模塊可暴露對外的服務對象，這里體現(xiàn)了OSGI和傳統(tǒng)的Plugin Framework不同的一個地方，管理和靜態(tài)結構分開，在OSGI中通過在manifest.mf文件中增加一些內(nèi)容來發(fā)布Bundle，在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露對外的包、所依賴的包；每個Bundle擁有自己的ClassLoader以及context，通過context可進行服務的注冊、卸載等，這些操作都會通過事件機制廣播給相應的其他的Bundle；一般來說都為通過在Bundle中編寫初始需要注冊的服務的方法來完成Bundle可供外部使用的服務的暴露功能；如需要調用其他Plugin提供的服務可通過context的getServiceReference先獲取Service的句柄，再通過context.getService(ServiceReference)的方法獲取Service的實體。
前一段時間對osgi的service層做了介紹，下面介紹module和lifecycle層，在這里主要介紹lifecycle
系統(tǒng)框架對bundle的生命周期進行了管理。
osgi生命周期的管理，覆蓋到bundle的安裝，啟動，停止，更新，卸載，和監(jiān)控這么一個過程。
Bundle的生命周期
下面是bundle的lifecycle的類圖
下面詳細介紹bundle的幾個對象
l Bunlde 標識
Identifier
Location
symbolicName
l bundle的狀態(tài)
狀態(tài)轉換圖
ü bundle的安裝一般有兩種方式：
通過另外一個bundle的bundlecontext來完成
通過命令行的形式（比如系統(tǒng)bundle一般是這樣的）來完成的
ü Bundle的解析（一般是在啟動過程中完成的）
根據(jù)bundle的定義，創(chuàng)建基于版本的module（ModuleDefinition，ContentLoader，Wire）
ü Bundle的啟動，由該bundle的調用start api來完成的
這里包含創(chuàng)建該bundle的上下文（BundleContext）
創(chuàng)建該bundle的activator，可以在activator里進行與該bundle相關的service的注冊，bundlelistener，servicelistener ,frameworklistener的注冊以及安裝其他的bundle.等.
是否要立即觸發(fā)該activator，需要根據(jù)該bundle的activator policy來決定；在用bundle獲取resource的時候，采取解析bundle，才創(chuàng)建該bundle的classloader和activate該bundle。這樣能節(jié)省啟動的時間，實現(xiàn)了懶加載。
下圖描述了bundle的啟動過程中的狀態(tài)變化
ü Bundle的更新
Bundle的更新，是從一個版本到另一個版本的遷移過程
流程如下：
1． 檢查bundle的狀態(tài)
如果是uninsalled，拋出異常
2． ，但是不改變持久化的狀態(tài)Stop bundle
3． 版本的修訂
4． 更改bundle的時間戳，狀態(tài)設置成installed
5． 發(fā)送unresolved事件給bundle
6． 把該bundle的老的module做一個removal標記，表示不可用
7． 發(fā)送updated事件給bundle
8． 啟動（start）bundle
ü Bundle的停止
1． 把bundle的持久化狀態(tài)設置成inactive
2． 檢查bundle的狀態(tài)
如果狀態(tài)是Installed，Resolved，就返回
如果是uninstalled，拋出異常
如果是starting，stopping，拋異常
如果ACTIVE，把bundle的狀態(tài)設置成stopping，發(fā)stopping事件跟響應的bundle
3． 調用該bundle的activator的stop操作，清理分配的資源
4． 清除bundle的上下文
清理該bundle注冊的service
釋放該bundle用到的service
刪除該bundle注冊的listener
5． 該bundle的狀態(tài)返回到resolved狀態(tài)
6． 發(fā)stopped事件給該bundle
ü Bundle的卸載
1． Stop bundle
2． 把該bundle從緩存中刪除
3． 把該bundle放入uninstall 類別中
4． 該bundle狀態(tài)設置成uninstalled
5． 觸發(fā)bundle的uninstall事件
6． 看是否有以來該bundle的module，如果沒有則垃圾回收
Listener和事件機制
關于這一部分功能和用法已在上一篇service層里已經(jīng)做了介紹，這里只做一下簡單的羅列
ü Framework
FrameworkListener：
注冊時間：
觸發(fā)時間：
作用：OSGI environment
FrameworkEvent: type，bundle，throwable
ü Bundle
BundleListener
注冊時間：
觸發(fā)時間：
作用：a bundle lifecycle change.
BundleEvent: Bundle,type
ü Service
ServiceListener
注冊時間：
觸發(fā)時間：
作用：a service lifecycle change.
ServiceEvent:serviceReference ,type
|
資源
|
事件類型
|
觸發(fā)時機
|
|
Framework
|
STARTED
|
Framework啟動完成
Framework has started after all installed bundles that are marked to be started have been started and the Framework has reached the intitial start level.
|
|
ERROR
|
There was an error associated with a bundle.
|
|
PACKAGES_REFRESHED
|
Framework has completed the refresh packages operation initiated by a call to the
PackageAdmin.refreshPackages method.
|
|
STARTLEVEL_CHANGED
|
the Framework has completed changing the active start level initiated by a call to the StartLevel.setStartLevel
method.
|
|
WARNING
|
There was a warning associated with a bundle.
|
|
INFO
|
There was an informational event associated with a bundle.
|
|
Bundle
|
INSTALLED
|
The bundle has been installed.
|
|
STARTED
|
The bundle has been started.
|
|
STOPPED
|
The bundle has been stopped.
|
|
UNINSTALLED
|
The bundle has been uninstalled.
|
|
RESOLVED
|
The bundle has been resolved.
|
|
UNRESOLVED
|
The bundle has been unresolved.
|
|
STARTING
|
The bundle is about to start.
|
|
STOPPING
|
The bundle is about to stop.
|
|
Service
|
REGISTERED
|
This service has been registered.
|
|
MODIFIED
|
The properties of a registered service have been modified.
|
|
UNREGISTERING
|
This service is in the process of being unregistered.
If a bundle is using a service that is <code>UNREGISTERING</code>, the
bundle should release its use of the service when it receives this event.
If the bundle does not release its use of the service when it receives
this event, the Framework will automatically release the bundle's use of
the service while completing the service unregistration operation.
|
|
|
|
資源的查找
幾點說明
系統(tǒng)啟動時候，會把所有職責的關聯(lián)關系wire起來
并且創(chuàng)建核心的查找資源policy
還有就是有的module可以放在resolve階段可以放到查找資源的時候進行，實現(xiàn)懶加載的功能
1.查找資源的核心類，分發(fā)中心，所有的調度邏輯都在這里
2.所有的資源查找都代理到該核心類，有點象代理的方式
3.module的修改，這里會實時的得到更新（通過注冊listener）
資源的查找：在本bundle的classloader范圍內(nèi)，進行class的查找，資源加載的順序可以參見規(guī)范
下面是類查找的類圖
該bundle的Classloader在bundle的resolve階段就創(chuàng)建好了
關于bundle的說明定義中的import export詳見規(guī)范
系統(tǒng)Bundle的啟動過程
1．系統(tǒng)bundle由框架啟動，并且只啟動一次
2． 創(chuàng)建服務的注冊中心，該中心作為各種事件的分發(fā)場所。
3． 創(chuàng)建核心的查找資源的policy，加入resolver listener到該policy，可以在module解析后，得到通知更新bundle的狀態(tài)
4． 初始化事件分發(fā)器
5. 在加載其他的bundle之前，創(chuàng)建系統(tǒng)的bundle負責容器相關的service，resolve系統(tǒng)bundle，創(chuàng)建系統(tǒng)bundle的activator，創(chuàng)建bundle的上下文，并觸發(fā)activator
6. 安裝其他的bundle
7 觸發(fā)系統(tǒng)bundle的started事件，標志系統(tǒng)bundle啟動完成
8. 觸發(fā)框架的started時間，標志框架啟動完成
摘要: OSGI的框架很好的解決了模塊動態(tài)的更新，部署，以及解決他們之間的依賴關系
的問題，更夠搭建動態(tài)化的系統(tǒng)可以說是OSGI在SCA的部署策略上的一種很好的參考實現(xiàn)。
閱讀全文