OSGi的CM就是Configuration Admin Service，是用于管理Bundle屬性、并在屬性發(fā)生變更時(shí)通知相應(yīng)的Service，可以看出，這是保持OSGi動(dòng)態(tài)性的很關(guān)鍵的一個(gè)服務(wù)，畢竟配置屬性的修改是會(huì)發(fā)生的，象修改了Http的端口呀等，但又不希望修改這些屬性后需要重啟才能生效，那么CM是一個(gè)不錯(cuò)的選擇，使用CM時(shí)無需關(guān)心屬性具體怎么存儲(chǔ)這些問題，而在屬性修改后CM也會(huì)自動(dòng)通知相關(guān)的service。
通常在系統(tǒng)的屬性管理上，我們的需求通常是在一個(gè)統(tǒng)一的界面上對(duì)系統(tǒng)的相關(guān)屬性進(jìn)行統(tǒng)一的配置，保存后則希望能通知相應(yīng)的服務(wù)，這里面的屬性自然有些是公用的，有些是某些模塊專用的，既然基于CM來實(shí)現(xiàn)這樣的需求，首先來看看基于CM需要怎么去做，這是基于CM的統(tǒng)一管理系統(tǒng)屬性的典型的序列圖：
其中ConfigurationAdminService、ManagedService均為CM中定義的規(guī)范的服務(wù)接口，而ConfigManageAction就是用于實(shí)現(xiàn)統(tǒng)一管理屬性配置的web響應(yīng)接口了，根據(jù)上圖可以看出，通過調(diào)用ConfigurationAdminService的getConfiguration方法可以獲取到Configuration對(duì)象，通過這個(gè)對(duì)象可以獲取到配置的屬性集合，而通過Configuration對(duì)象的update方法就可以更新屬性了，ConfigurationAdminService在更新屬性時(shí)將異步的調(diào)用系統(tǒng)中對(duì)外提供了ManagedService的服務(wù)的update方法，該方法的參數(shù)即為更新的屬性的集合。
首先要說明下CM對(duì)于屬性是怎么進(jìn)行存儲(chǔ)的，CM對(duì)于屬性的存儲(chǔ)是根據(jù)服務(wù)注冊(cè)時(shí)提供的service.pid的值(必須是唯一的)以及Bundle Location(Bundle的地址)構(gòu)成key來存儲(chǔ)其屬性的，按照這樣的過程，在維護(hù)屬性時(shí)自然也要以這個(gè)為Key來進(jìn)行操作，同樣的，在通知屬性更新時(shí)CM也是根據(jù)這個(gè)key的值來決定的，但實(shí)現(xiàn)ManagedService的服務(wù)只能傳入service.pid這個(gè)值，Bundle Location的值CM將自動(dòng)的獲取該服務(wù)所屬的Bundle的Location，這看似設(shè)計(jì)的很好，但同時(shí)在應(yīng)用層面則帶來了一個(gè)問題，后面將會(huì)講到。
假設(shè)我們的需求是這樣的：
1、A Bundle中的PortService的port屬性需要管理，BookService的bookcount屬性需要配置；
2、B Bundle中的PortConfigService的port屬性需要管理，MenuService中的menucount屬性需要配置；
3、其中A Bundle中的PortService所需的port和B Bundle中的PortConfigService所需的port屬性是相同的；
4、屬性統(tǒng)一在C Bundle中通過提供web界面的管理方式來實(shí)現(xiàn)，在屬性發(fā)生變化時(shí)要通知相應(yīng)Bundle的Service。
那么根據(jù)上面對(duì)于CM的講解我們來實(shí)現(xiàn)這個(gè)需求：
1、PortService、BookService、PortConfigService、MenuService均需實(shí)現(xiàn)ManagedService接口，ManagedService接口中只有一個(gè)方法update(Dictionary props)，當(dāng)service關(guān)注的屬性被更新時(shí)CM將會(huì)自動(dòng)的通知，然后服務(wù)根據(jù)屬性自行的做出相應(yīng)的處理；
2、PortService、BookService、PortConfigService、MenuService對(duì)外提供ManagedService接口，在注冊(cè)時(shí)提供service.pid屬性的值，這個(gè)值必須是唯一的，假設(shè)分別為a.port、a.bookservice、b.port、b.menuservice；
3、實(shí)現(xiàn)ConfigManageAction，配置頁面上自然是只有port、bookcount和menucount三個(gè)屬性需要配置的了，由于CM是采用service.pid加上Bundle的Location來構(gòu)成key的，而在通知屬性更新上也是根據(jù)這個(gè)key來決定，那么這其實(shí)也就已經(jīng)意味著ConfigManageAction在管理這幾個(gè)屬性時(shí)必須帶上相應(yīng)的Bundle的Location了，這是不太合理的地方，首先要獲取Bundle的Location是比較麻煩的事，其次是這樣也就意味著ConfigManageAction是必須知道當(dāng)屬性變更時(shí)需要通知到哪些Bundle的，如果將來增加一個(gè)Bundle的服務(wù)需要監(jiān)聽某已經(jīng)存在的屬性的話，就必須要修改ConfigManageAction的代碼，當(dāng)然，這和注冊(cè)的服務(wù)監(jiān)聽的server.pid的屬性必須唯一也有關(guān)，也就是說CM其實(shí)只是一個(gè)基于Event的一對(duì)一的訂閱/發(fā)布模型，這就導(dǎo)致了在維護(hù)一個(gè)port這樣的公共屬性的時(shí)候竟然要在A Bundle的PortService和B Bundle的PortConfigService中各存一份，OSGi聯(lián)盟對(duì)于此的解釋是出于安全問題的考慮，所以在CM的設(shè)計(jì)上采取了加上Bundle Location做為Key的原因。
在這樣的情況下，也就導(dǎo)致了ConfigManageAction變得復(fù)雜了......
CM在這塊設(shè)計(jì)上欠缺對(duì)于應(yīng)用級(jí)屬性(共享配置屬性)上的考慮絕對(duì)是有待商討的，現(xiàn)在只能是在各個(gè)Bundle中各自維護(hù)一套，同時(shí)在各自Bundle中提供一個(gè)ConfigManageService這樣的服務(wù)來更新當(dāng)前Bundle中的屬性，這樣才能解決Bundle Location的那個(gè)問題，在目前的情況下就沒法構(gòu)成共有屬性的維護(hù)方式了，如果是公有屬性變化的話也就只有在ConfigManageAction中調(diào)用相關(guān)的多個(gè)Bundle的ConfigManageService來完成屬性的修改了，這樣的話存儲(chǔ)和動(dòng)態(tài)的通知仍然交由CM去完成了。
關(guān)于模塊的耦合上只有個(gè)小小的想法討論下，就是做為設(shè)計(jì)師你能否很快的告訴別人搭建你其中的一個(gè)模塊的工程需要哪幾個(gè)模塊的支撐，或者最好就是運(yùn)行檢驗(yàn)?zāi)闫渲械囊粋€(gè)模塊的功能需要哪幾個(gè)模塊來支撐，當(dāng)然，這個(gè)在基于OSGi的系統(tǒng)更容易來做到，不過這個(gè)確實(shí)是設(shè)計(jì)時(shí)很關(guān)鍵的一個(gè)地方，這既反映了系統(tǒng)中模塊的耦合性，更體現(xiàn)了系統(tǒng)的擴(kuò)展性以及系統(tǒng)的組裝耦合上是否合理。