OSGi 部署管理服务的状态
OSGi 应用程序由称为捆绑包的模块组成。 问题是，任何大小合理的应用程序都会有大量的捆绑包（很容易有数百个，只需查看 Eclipse IDE 的插件目录），因此在管理或部署应用程序时，您需要比单个捆绑包更粗的粒度。
OSGi 服务纲要规范包含部署管理服务，它将部署包定义为捆绑包和其他工件（例如配置）的集合，可以将其作为单个单元进行部署、升级、卸载等。
不幸的是，我找不到太多有关部署管理实施、工具或用户的信息。
这项服务的现状如何？ 有人对部署管理有任何经验、意见或建议吗？
另外，我认为 Spring dm-server 具有应用程序范围的捆绑包（PAR 文件）集合的概念，并且 Eclipse Equinox 正在开发嵌套框架来解决该问题。 这些方法与部署管理有何关系？
OSGi applications are composed of modules called bundles. The problem is that any reasonably sized application will have a large number of bundles (could easily be hundreds, just look at the plugins directory of your Eclipse IDE), so that you want a coarser granularity than individual bundles when managing or deploying the application.
The OSGi Service Compendium Spec contains a Deployment Admin Service, which defined deployment packages as a collection of bundles and other artifacts (such as configuration) that can be deployed, upgraded, uninstalled and so forth as a single unit.
Unfortunately, I could not find much information about Deployment Admin implementations, tooling or users.
What is the status of this service?
Does anyone have any experience, opinion or recommendation regarding Deployment Admin?
Also, Spring dm-server has the concept of application-scope collection of bundles (PAR files) and Eclipse Equinox is working on nested frameworks to address the problem, I think. How do these approaches relate to Deployment Admin?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
部署管理是 OSGi 纲要服务之一，似乎引起的关注相对较少。 显然有一个规范，因此大概有一个参考实现和合规性测试。 Apache Felix 项目贡献了一个实现，但似乎已经沉没得无影无踪。
在设计 SpringSource dm Server 中的 PAR 文件支持时，我研究了部署管理，但该模型不适合我们的用例。 特别是，具有给定符号名称（和任何版本）的包不能驻留在安装在同一 OSGi 框架中的两个不同的部署包中。
相反，安装在 dm Server 的同一实例中的两个 PAR 文件可能都包含具有给定捆绑包符号名称（以及相同或不同的捆绑包版本）的捆绑包。 我们将此视为应用程序扩展要求：我们不希望大型应用程序仅仅因为它们的开发人员碰巧打包了相同的包而“冲突”。 服务的范围也由 PAR 文件确定。
在 dm Server 2.0 中，我们将 PAR 的概念概括为“计划”，这些文件通过类型名称和版本引用要安装的工件。 计划可以是有范围的（如 PAR）或无范围的，并且可以是原子的（意味着其内容的生命周期以原子方式与计划的生命周期相关联，如 PAR）或非原子的。
嵌套框架也正在作为未来可能的 OSGi 标准进行研究，以解决应用程序范围界定要求，但其设计点与 dm 服务器范围相当不同。 嵌套框架无法自动查看其父框架中的包和服务。 因此，默认情况下，该模型是一种隔离模型，无论是子框架之间的隔离还是子框架与父框架的隔离。 dm 服务器范围故意将子级彼此隔离，但仅在一个方向上将子级与其父级隔离：子级可以看到其父级的所有包和服务。
Deployment Admin is one of those OSGi compendium services that seems to have attracted relatively little attention. Clearly there is a specification and therefore presumably a reference implementation and compliance tests. An implementation was contributed to the Apache Felix project, but seems to have sunk pretty much without trace.
I looked into Deployment Admin when designing the PAR file support in SpringSource dm Server, but the model was inappropriate for our use cases. In particular, a bundle with a given symbolic name (and any version) may not reside in two distinct Deployment Packages which are installed in the same OSGi framework.
In contrast, two PAR files installed in the same instance of dm Server may both contain a bundle with a given bundle symbolic name (and the same or different bundle version). We see this as an application scaling requirement: we didn't want large applications to "collide" simply because their developers happened to package the same bundle. Services are also scoped by PAR files.
In dm Server 2.0 we have generalised the concept of PARs into "plans" which are files referring, by type name and version, to artifacts to be installed. A plan may be scoped (like a PAR) or unscoped and may be atomic (meaning the lifecycle of its contents is tied atomically to the lifcycle of the plan, like a PAR) or non-atomic.
Nested frameworks are also being investigated as a possible future OSGi standard to address application scoping requirements but with a rather different design point to dm Server scopes. A nested framework cannot automatically see the packages and services in its parent framework. So the model is one of isolation by default, whether that is isolation of child frameworks from each other or isolation of child and parent frameworks. dm Server scopes deliberately isolate children from each other but only isolate a child from its parent in one direction: a child can see all its parent's packages and services.
您可能有兴趣知道 Apache Ace（目前处于孵化和加速阶段）可以动态生成部署管理的部署包，并使用（默认情况下，当配置到 OSGi 目标时）Felix 的部署管理。
由于该网站正在开发中：Apache Ace 是一个软件分发框架，允许您集中管理软件组件、配置数据和其他工件并将其分发到目标系统。 它是使用 OSGi 构建的
可以部署在不同的拓扑中。 目标系统通常也是基于 OSGi 的，但不是必须如此。
You might be interested to know that Apache Ace (which is currently in incubation and ramping up) can dynamically generate deployment packages for Deployment Admin, and uses (by default, when provisioning to OSGi target) Felix's Deployment Admin.
Since the website is very much under development: Apache Ace is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. It is built using OSGi and
can be deployed in different topologies. The target systems are usually also OSGi based, but don't have to be.