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，但不必须。