OSGi應用程序由稱爲包的模塊組成。問題是任何合理大小的應用程序都會有大量的bundle（可能很容易成百上千，只需查看Eclipse IDE的plugins目錄），這樣在管理或部署應用程序時就需要比單個bundle更粗的粒度。OSGi部署管理服務的狀態
OSGi Service Compendium Spec包含一個部署管理服務，該部署管理服務將部署包定義爲可作爲單個部件進行部署，升級，卸載等的捆綁包和其他工件（例如配置）的集合。
不幸的是，我找不到關於Deployment Admin實現，工具或用戶的很多信息。
此服務的狀態如何？ 有沒有人有任何關於部署管理的經驗，意見或建議？另外，Spring dm-server具有bundle（PAR文件）的應用程序範圍集合的概念，我認爲Eclipse Equinox正在研究嵌套框架來解決這個問題。這些方法與部署管理員有什麼關係？
部署管理員是那些似乎沒有引起足夠重視的OSGi彙編服務之一。顯然有一個規範，因此可能是一個參考實現和一致性測試。 Apache Felix項目實現了一個實現，但似乎沒有任何痕跡就沉沒了。
在SpringSource dm服務器中設計PAR文件支持時，我查看了Deployment Admin，但該模型不適合我們的用例。特別是，具有給定符號名稱（以及任何版本）的軟件包可能不駐留在安裝在相同OSGi框架中的兩個不同的部署軟件包中。
相反，安裝在dm服務器的同一實例中的兩個PAR文件可能都包含具有給定包符號名稱（以及相同或不同包版本）的包。我們將此視爲應用程序擴展需求：我們不希望大型應用程序「碰撞」，僅僅是因爲他們的開發人員碰巧打包了相同的包。服務也受PAR文件的限制。
在dm Server 2.0中，我們已經將PAR的概念推廣到「計劃」中，這些計劃是按類型名稱和版本引用要安裝的工件的文件。計劃的範圍可以是（如PAR），也可以是非原子的（也可以是原子的（意思是其內容的生命週期與計劃的生命週期原子級綁定），也可以是非原子的。
爲了解決應用程序範圍的要求，嵌套框架也被作爲未來可能的OSGi標準進行研究，但是與dm服務器範圍的設計點有所不同。嵌套框架無法自動在其父框架中看到包和服務。因此，默認情況下，該模型是一種隔離模式，無論是將子框架彼此隔離，還是將子框架與父框架分離。 dm服務器範圍故意將孩子隔離開，但只將孩子與其父母隔離在一個方向上：孩子可以看到父母的所有包和服務。
您可能有興趣知道Apache Ace（目前正處於孵化和快速發展階段）可以爲部署管理員動態生成部署軟件包，並使用（默認情況下，在配置到OSGi目標時）Felix的部署管理員。
由於網站正在開發中非常：Apache的王牌是一個軟件分發框架，使您可以集中管理和分發軟件組件，配置數據等文物到目標系統。它是使用OSGi建成 可以在不同的拓撲結構進行部署。目標系統通常也基於OSGi，但不必須。