我在维基百科和其他网站上读过关于OSGi的文章，但我真的没有看到大局。它说它是一个基于组件的平台，您可以在运行时重新加载模块。此外，到处给出的“实际示例”是Eclipse插件框架。
我的问题是：
OSGi的清晰和简单的定义是什么？
它解决了哪些常见问题？
我所说的“常见问题”是指我们每天面临的问题，比如“OSGi能做些什么来使我们的工作更有效率/更有趣/更简单？
降低复杂性 -使用OSGi技术进行开发意味着开发捆绑包：OSGi组件。捆绑包是模块。它们对其他捆绑包隐藏其内部，并通过定义良好的服务进行通信。隐藏内部意味着以后有更大的更改自由度。这不仅减少了 bug 的数量，还使捆绑包更易于开发，因为正确大小的捆绑包通过明确定义的接口实现一部分功能。有一个有趣的博客描述了OSGi技术为他们的开发过程做了什么。
再利用 -OSGi 组件模型使得在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目提供为OSGi准备的JAR。然而，商业图书馆也作为现成的捆绑包提供。
现实世界 -OSGi 框架是动态的。它可以动态更新捆绑包，服务可以来来去去。习惯于更传统的Java的开发人员认为这是一个非常有问题的功能，并且没有看到其优势。但是，事实证明，现实世界是高度动态的，并且具有可以来来去去的动态服务使服务成为许多现实世界场景的完美匹配。例如，服务可以对网络中的设备进行建模。如果检测到设备，则注册服务。如果设备消失，则服务未注册。与此动态服务模型匹配的现实世界方案数量惊人。因此，应用程序可以在自己的域中重用服务注册表的强大基元（注册，获取，使用富有表现力的过滤语言列出，以及等待服务出现和消失）。这不仅节省了编写代码的时间，还提供了全局可见性、调试工具以及比专用解决方案实现的更多功能。在这样一个动态环境中编写代码听起来像是一场噩梦，但幸运的是，有些支持类和框架可以消除大部分（如果不是全部）痛苦。
轻松部署 -OSGi技术不仅仅是组件的标准。它还指定如何安装和管理组件。许多捆绑包已使用此 API 来提供管理代理。此管理代理程序可以像命令 shell、TR-69 管理协议驱动程序、OMA DM 协议驱动程序、Amazon 的 EC2 的云计算接口或 IBM Tivoli 管理系统一样简单。标准化的管理API使得将OSGi技术集成到现有和未来的系统中变得非常容易。
动态更新 - OSGi 组件模型是一个动态模型。可以安装、启动、停止、更新和卸载捆绑包，而不会使整个系统瘫痪。许多Java开发人员不相信这可以可靠地完成，因此最初不会在生产中使用它。但是，在开发中使用它一段时间后，大多数人开始意识到它实际上有效并显着缩短了部署时间。
自适应 -OSGi组件模型从头开始设计，允许组件的混合和匹配。这要求需要指定组件的依赖项，并且要求组件位于其可选依赖项并不总是可用的环境中。OSGi 服务注册表是一个动态注册表，捆绑软件可以在其中注册、获取和侦听服务。此动态服务模型允许捆绑包找出系统上可用的功能，并调整它们可以提供的功能。这使得代码更加灵活，并且能够灵活应对更改。
透明度 -捆绑包和服务是 OSGi 环境中的一等公民。管理 API 提供对捆绑软件的内部状态以及它与其他捆绑软件的连接方式的访问。例如，大多数框架都提供显示此内部状态的命令 shell。可以停止应用程序的某些部分以调试某个问题，或者可以引入诊断捆绑包。OSGi 应用程序通常可以使用实时命令 shell 进行调试，而不是盯着数百万行日志记录输出和较长的重新启动时间。
版本控制 -OSGi技术解决了JAR地狱。JAR地狱是库A与库B;version=2一起工作的问题，但库C只能与B;version=3一起工作。在标准的Java中，你运气不好。在 OSGi 环境中，所有捆绑包都经过仔细的版本控制，并且只有可以协作的捆绑软件才能在同一类空间中连接在一起。这允许捆绑包 A 和 C 与自己的库一起工作。虽然不建议设计具有此版本控制问题的系统，但在某些情况下，它可以挽救生命。
简单 -OSGi API非常简单。核心 API 只有一个包，少于 30 个类/接口。此核心 API 足以写入捆绑包、安装捆绑包、启动、停止、更新和卸载它们，并且包括所有侦听器和安全类。很少有 API 可以为如此小的 API 提供如此多的功能。
小 -OSGi Release 4 Framework可以在大约300KB的JAR文件中实现。对于通过包含 OSGi 添加到应用程序的功能量而言，这是一个小开销。因此，OSGi可以在各种设备上运行：从非常小到小，再到大型机。它只要求运行一个最小的Java VM，并且在它上面添加很少。
快速 - OSGi 框架的主要职责之一是从捆绑包加载类。在传统的Java中，JAR是完全可见的，并放在线性列表中。搜索类需要搜索这个（通常很长，150并不罕见）列表。相反，OSGi 预先连接捆绑包，并为每个捆绑包确切地知道哪个捆绑包提供类。这种缺乏搜索是启动时的一个重要加速因素。
懒惰 -软件中的懒惰是好的，OSGi技术有许多机制，只有在真正需要时才做事情。例如，可以急切地启动捆绑软件，但也可以将其配置为仅在其他捆绑软件使用它们时才启动。可以注册服务，但只能在使用服务时创建服务。这些规范已经过多次优化，以允许这些可以节省大量运行时成本的懒惰方案。
安全 -Java在底部有一个非常强大的细粒度安全模型，但在实践中很难配置。结果是，大多数安全的Java应用程序都以二元选择运行：没有安全性或功能非常有限。OSGi 安全模型利用了细粒度的安全模型，但通过让捆绑包开发人员以易于审计的形式指定所请求的安全详细信息，同时环境操作员仍然完全负责，从而提高了可用性（以及强化原始模型）。总体而言，OSGi可能提供了最安全的应用程序环境之一，除了受硬件保护的计算平台之外，它仍然可用。
非侵入式 -OSGi 环境中的应用程序（捆绑包）留给它们自己。他们几乎可以使用VM的任何设施，而OSGi不会限制它们。OSGi的最佳实践是编写普通的旧Java对象，因此，OSGi服务不需要特殊的接口，即使是Java String对象也可以充当OSGi服务。此策略使应用程序代码更易于移植到另一个环境。
无处不在 -嗯，这要视情况而定。Java的最初目标是在任何地方运行。显然，不可能在任何地方运行所有代码，因为 Java VM 的功能不同。移动电话中的 VM 可能不支持与运行银行应用程序的 IBM 大型机相同的库。有两个问题需要处理。首先，OSGi API 不应使用并非在所有环境中都可用的类。其次，如果捆绑包包含执行环境中不可用的代码，则不应启动该捆绑包。这两个问题在OSGi规范中都得到了解决。
我发现OSGi具有以下优点：
这样，您就可以将应用程序构建为一组按需加载的版本化插件工件。每个插件都是一个独立的组件。正如 Maven 帮助您构建构建版本，使其可重复并由一组特定版本的工件定义一样，OSGi 可帮助您在运行时执行此操作。
