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