我在 Wikipedia 和其他网站上阅读过有关OSGi的信息，但我并没有真正看到全局。它说它是一个基于组件的平台，并且您可以在运行时重新加载模块。此外，随处可见的“实际示例”是 Eclipse 插件框架。
我的问题是：
OSGi 的清晰和简单的定义是什么？
它解决了哪些常见问题？
我所说的“常见问题”是指我们每天面临的问题，例如“OSGi 可以做些什么来让我们的工作更高效/有趣/简单？”
Pablo Fernandez
问问题
71612 次
15 回答
101
OSGi 的组件系统为您提供了哪些好处？
好吧，这是一个相当多的清单：
降低复杂性 -使用 OSGi 技术进行开发意味着开发捆绑包：OSGi 组件。捆绑包是模块。它们对其他捆绑包隐藏其内部结构，并通过定义明确的服务进行通信。隐藏内部结构意味着以后可以更自由地进行更改。这不仅减少了 bug 的数量，而且还使 bundle 更易于开发，因为正确大小的 bundle 通过定义良好的接口实现了一项功能。有一个有趣的博客描述了 OSGi 技术为他们的开发过程做了什么。
重用——OSGi 组件模型使得在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目为 OSGi 提供了现成的 JAR。但是，商业库也可以作为现成的捆绑包使用。
真实世界 -OSGi 框架是动态的。它可以即时更新捆绑包，服务可以来来去去。习惯于更传统 Java 的开发人员认为这是一个非常有问题的特性，而看不到它的优势。然而，事实证明，现实世界是高度动态的，并且具有可以来去去去的动态服务使得这些服务非常适合许多现实世界的场景。例如，服务可以为网络中的设备建模。如果检测到设备，则注册服务。如果设备消失，则服务未注册。与这种动态服务模型相匹配的现实世界场景数量惊人。因此，应用程序可以在自己的域中重用服务注册中心的强大原语（注册、获取、使用表达性过滤语言列出，并等待服务出现和消失）。这不仅节省了编写代码，还提供了全局可见性、调试工具和比专用解决方案实现的更多功能。在这样的动态环境中编写代码听起来像是一场噩梦，但幸运的是，有一些支持类和框架可以减轻大部分（如果不是全部）的痛苦。
易于部署 - OSGi 技术不仅仅是组件的标准。它还指定如何安装和管理组件。许多捆绑软件都使用此 API 来提供管理代理。该管理代理可以像命令外壳、TR-69 管理协议驱动程序、OMA DM 协议驱动程序、亚马逊 EC2 的云计算接口或 IBM Tivoli 管理系统一样简单。标准化的管理 API 使得将 OSGi 技术集成到现有和未来系统中变得非常容易。
动态更新——OSGi 组件模型是一个动态模型。可以在不关闭整个系统的情况下安装、启动、停止、更新和卸载捆绑包。许多 Java 开发人员不相信这可以可靠地完成，因此最初不会在生产中使用它。然而，在开发中使用它一段时间后，大多数人开始意识到它确实有效并且显着减少了部署时间。
自适应 - OSGi 组件模型是从头开始设计的，允许组件的混合和匹配。这要求需要指定组件的依赖关系，并且要求组件生活在其可选依赖关系并不总是可用的环境中。OSGi 服务注册中心是一个动态注册中心，bundle 可以在其中注册、获取和监听服务。这种动态服务模型允许捆绑包找出系统上可用的功能并调整它们可以提供的功能。这使代码更灵活，更能适应变化。
透明度 -捆绑包和服务是 OSGi 环境中的一等公民。管理 API 提供对 bundle 内部状态以及它如何连接到其他 bundle 的访问。例如，大多数框架都提供了一个显示这种内部状态的命令 shell。可以停止部分应用程序以调试某个问题，或者可以引入诊断包。OSGi 应用程序通常可以使用实时命令 shell 来调试，而不是盯着数百万行的日志输出和漫长的重启时间。
版本控制——OSGi 技术解决了 JAR 问题。JAR 地狱是库 A 与库 B;version=2 一起工作的问题，但库 C 只能与 B;version=3 一起工作。在标准 Java 中，你不走运。在 OSGi 环境中，所有的 bundle 都经过仔细的版本控制，只有可以协作的 bundle 在同一个类空间中连接在一起。这允许包 A 和 C 使用它们自己的库来运行。尽管不建议设计具有此版本控制问题的系统，但在某些情况下它可以挽救生命。
简单 - OSGi API 非常简单。核心 API 只有一个包，不到 30 个类/接口。这个核心 API 足以编写包、安装包、启动、停止、更新和卸载包，并且包括所有侦听器和安全类。很少有 API 能够为这么少的 API 提供这么多的功能。
小——OSGi Release 4 框架可以在大约 300KB 的 JAR 文件中实现。对于通过包含 OSGi 添加到应用程序的大量功能来说，这是一个很小的开销。因此，OSGi 可以在各种设备上运行：从非常小的设备到小型设备，再到大型机。它只要求运行一个最小的 Java VM，并且在其上添加的东西很少。
快速- OSGi 框架的主要职责之一是从包中加载类。在传统的 Java 中，JAR 是完全可见的并放在一个线性列表中。搜索一个类需要搜索这个（通常很长，150 个并不少见）列表。相反，OSGi 预先连接捆绑包，并为每个捆绑包准确地知道哪个捆绑包提供了类。这种缺乏搜索是启动时的重要加速因素。
懒惰 -软件中的懒惰是好的，OSGi 技术有许多机制，只有在真正需要时才做事。例如，bundle 可以立即启动，但也可以配置为仅在其他 bundle 使用它们时启动。服务可以注册，但只能在使用时创建。规范已经过多次优化，以允许这种可以节省大量运行时成本的惰性场景。
安全 - Java 在底部有一个非常强大的细粒度安全模型，但在实践中却很难配置。结果是大多数安全的 Java 应用程序都以二元选择运行：没有安全性或功能非常有限。OSGi 安全模型利用了细粒度的安全模型，但通过让包开发人员以易于审计的形式指定请求的安全细节，同时环境的操作员仍然完全负责，从而提高了可用性（以及强化原始模型）。总体而言，OSGi 可能提供了最安全的应用程序环境之一，在没有硬件保护的计算平台的情况下仍然可用。
非侵入式 - OSGi 环境中的应用程序（捆绑包）由它们自己处理。他们几乎可以使用 VM 的任何设施，而不受 OSGi 的限制。OSGi 的最佳实践是编写普通的旧 Java 对象，因此，OSGi 服务不需要特殊的接口，即使是 Java 字符串对象也可以充当 OSGi 服务。这种策略使应用程序代码更容易移植到另一个环境。
到处跑——嗯，这取决于。Java 最初的目标是在任何地方运行。显然，不可能在任何地方运行所有代码，因为 Java VM 的功能不同。移动电话中的 VM 可能不支持与运行银行应用程序的 IBM 大型机相同的库。有两个问题需要处理。首先，OSGi API 不应使用并非在所有环境中都可用的类。其次，如果包包含在执行环境中不可用的代码，则不应启动它。这两个问题都在 OSGi 规范中得到了解决。
于 2013-07-26T08:39:38.223 回答
93
I've found the following benefits from OSGi:
- Each plugin is a versioned artifact that has its own classloader.
- Each plugin depends on both specific jars that it contains and also other specific versioned plug-ins.
- Because of the versioning and isolated classloaders, different versions of the same artifact can be loaded at the same time. If one component of your application relies on one version of a plug-in and another depends on another version, they both can be loaded at the same time.
With this, you can structure your application as a set of versioned plugin artifacts that are loaded on demand. Each plugin is a standalone component. Just as Maven helps you structure your build so it is repeatable and defined by a set of specific versions of artifacts it is created by, OSGi helps you do this at runtime.
于 2008-09-19T23:16:33.937 回答
61
我不太关心 OSGi 模块的热插拔性（至少目前是这样）。它更多的是强制模块化。在类路径上随时没有数百万个“公共”类可以很好地防止循环依赖：您必须真正考虑您的公共接口 - 不仅在 java 语言构造“公共”方面，而且在您的库方面/module：您想为其他人提供哪些（确切地说）是哪些组件？您真正需要实现功能的（其他模块的）接口是什么（确切地说）是什么？
很好，带有热插拔功能，但我宁愿重新启动我常用的应用程序，也不愿测试所有热插拔性组合......
于 2008-09-20T16:43:45.493 回答
22
- 以此类推，您可以在不关闭汽车的情况下更换汽车的电机。
- 您可以为客户定制复杂的系统。了解 Eclipse 的强大功能。
- 您可以重用整个组件。比仅仅对象更好。
- 您使用稳定的平台来开发基于组件的应用程序。这样做的好处是巨大的。
- 您可以使用黑盒概念构建组件。其他组件不需要知道隐藏接口，它们只看到已发布的接口。
- 您可以在同一系统中使用多个相同的组件，但在不同的版本中，而不会影响应用程序。OSGi 解决了 Jar Hell 问题。
- 使用 OSGi，您可以开发思维以使用CBD构建系统
有很多好处（我现在只提醒了这些），适用于所有使用 Java 的人。
于 2010-11-23T16:21:30.627 回答
15
为清楚起见进行了编辑。OSGi 页面给出了比我更好的简单答案
一个简单的答案：OSGi 服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种架构显着降低了构建、维护和部署应用程序的整体复杂性。OSGi 服务平台提供了在各种网络的设备上动态更改组合的功能，无需重新启动。
在单个应用程序结构中，比如 Eclipse IDE，安装新插件时重新启动并不是什么大问题。完全使用 OSGi 实现，您应该能够在运行时添加插件，获得新功能，但根本不必重新启动 eclipse。
同样，对于每天的小型应用程序使用而言，这没什么大不了的。
但是，当您开始研究多计算机、分布式应用程序框架时，它就会开始变得有趣。当您必须为关键系统提供 100% 的正常运行时间时，热插拔组件或在运行时添加新功能的功能非常有用。诚然，现在大多数情况下都有执行此操作的功能，但 OSGi 正试图将所有内容捆绑到一个带有通用接口的漂亮小框架中。
OSGi 是否解决了常见问题，我不确定。我的意思是，它可以，但对于更简单的问题，开销可能不值得。但是当您开始处理更大的网络应用程序时，这是需要考虑的事情。
于 2008-09-19T22:55:47.543 回答
13
一些让我对 OSGi 疯狂的事情：
1) 实现和它们的上下文加载器有很多怪癖，并且可能有点异步（我们在 confluence 中使用 felix）。与纯弹簧（无 DM）相比，[main] 几乎所有东西都同步运行。
2）热加载后类不相等。比如说，你在休眠时有一个 tangosol 缓存层。它充满了 OSGi 范围之外的 Fork.class。你热加载了一个新的 jar，而 Fork 并没有改变。类[叉子]！=类[叉子]。由于相同的根本原因，它也会在序列化过程中出现。
3）聚类。
您可以解决这些问题，但这是一个主要的痛苦，并使您的架构看起来有缺陷。
对于那些为热插拔做广告的人...... OSGi 的#1 客户端？蚀。Eclipse 在加载包后会做什么？
它重新启动。
于 2013-04-22T22:16:08.570 回答
8
OSGi 使您的代码抛出NoClassDefFoundError并且ClassNotFoundException没有明显的原因（很可能是因为您忘记在 OSGi 配置文件中导出包）；因为它有 ClassLoaders 它可以使你的类com.example.Foo无法被强制转换，com.example.Foo因为它实际上是由两个不同的类加载器加载的两个不同的类。安装 Eclipse 插件后，它可以让你的 Eclipse 启动到 OSGi 控制台。
对我来说，OSGi 只是增加了复杂性（因为它增加了一个让我去思考的心理模型），因为异常而增加了烦恼；我从来没有真正需要它“提供”的动态性。它是侵入性的，因为它需要对所有模块进行 OSGi 捆绑配置；这绝对不简单（在一个更大的项目中）。
由于我的经历不好，我倾向于远离那个怪物，非常感谢。我宁愿忍受 jar 依赖地狱，因为这比 OSGi 引入的类加载器地狱更容易理解。
于 2017-06-14T13:17:39.467 回答
5
我还不是 OSGi 的“粉丝”……
我一直在财富 100 强公司使用企业应用程序。最近，我们使用的产品“升级”到了 OSGi 实现。
开始本地 cba 部署... [2/18/14 8:47:23:727 EST] 00000347 CheckForOasis
最终部署并且“以下捆绑包将被静默然后重新启动”[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I：作为应用程序更新操作的一部分
51 分钟...每次代码更改...以前的版本（非 OSGi）将在不到 5 分钟的时间内部署在较旧的开发机器上。
在具有 16 gig ram 和 40 个可用 gig 磁盘和 Intel i5-3437U 1.9 GHz CPU 的机器上
这次升级的“好处”作为改进（生产）部署出售——我们每年进行大约 4 次活动，每年可能进行 2-4 次小型修复部署。每天为 15 人（QA 和开发人员）增加 45 分钟我无法想象这是合理的。在大型企业应用程序中，如果您的应用程序是核心应用程序，那么更改它是正确的（小的更改可能会产生深远的影响 - 必须与整个企业的消费者进行沟通和计划），这是一项巨大的活动 - 错误的架构操作系统吉。如果您的应用程序不是企业应用程序 - 即每个消费者都可以拥有自己定制的模块，可能会在他们自己的孤岛数据库中访问他们自己的数据孤岛并在托管许多应用程序的服务器上运行，那么也许看看 OSGi。至少，
于 2014-02-18T15:26:21.103 回答
5
如果基于 Java 的应用程序需要添加或删除模块（扩展应用程序的基本功能），而无需关闭 JVM，则可以使用 OSGI。通常如果关闭JVM的成本更高，只是为了更新或增强功能。
例子：
- Eclipse：为插件提供安装、卸载、更新和相互依赖的平台。
- AEM：WCM 应用程序，其中功能更改将由业务驱动，无法承受停机维护时间。
注意：Spring 框架停止支持 OSGI spring 包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。除非绝对必要，否则我个人不会考虑 OSGI，例如构建平台。
于 2016-02-24T13:28:10.743 回答
4
我使用 OSGi 已经有将近 8 年的时间了，我不得不说，只有当您有业务需要在运行时更新、删除、安装或替换组件时，您才应该考虑使用 OSGi。这也意味着您应该具有模块化的思维方式并了解模块化的含义。有一些争论说 OSGi 是轻量级的——是的，这是真的，但也有一些其他的框架是轻量级的，更容易维护和开发。保护 java blah blah 也是如此。
OSGi 需要一个可靠的体系结构才能正确使用，并且很容易制作 OSGi 系统，它可以很容易地成为一个独立运行的 jar，而不涉及任何 OSGi。
于 2019-08-27T10:25:45.460 回答
2
OSGi 提供以下好处：
■ 基于 Java 的可移植且安全的执行环境
■ 服务管理系统，可用于跨包注册和共享服务，将服务提供者与服务消费者解耦
■ 动态模块系统，可用于动态安装和卸载 Java 模块，OSGi 将其称为捆绑包
■ 轻量级和可扩展的解决方案
于 2013-11-18T17:21:32.103 回答
1
至少，OSGi 让您思考模块化、代码重用、版本控制以及一般的项目管道。
于 2011-03-10T22:05:52.060 回答
1
它还被用来为移动端的中间件和应用程序带来额外的可移植性。例如，移动端可用于 WinMo、Symbian、Android。一旦与设备功能集成，就会变得支离破碎。
于 2009-04-30T20:38:21.580 回答
1
在它的官网上已经有一个相当有说服力的说法，我可以引用为
OSGi 技术如此成功的关键原因在于它提供了一个非常成熟的组件系统，该系统实际上可以在数量惊人的环境中工作。OSGi 组件系统实际上用于构建高度复杂的应用程序，如 IDE (Eclipse)、应用程序服务器（GlassFish、IBM Websphere、Oracle/BEA Weblogic、Jonas、JBoss）、应用程序框架（Spring、Guice）、工业自动化、住宅网关、电话，还有更多。
至于对开发商的好处？
开发人员：OSGi 通过为当今的大型分布式系统以及小型嵌入式应用程序提供模块化架构来降低复杂性。从内部和现成的模块构建系统显着降低了复杂性，从而降低了开发和维护费用。OSGi 编程模型实现了基于组件的系统的承诺。
请查看使用 OSGi 的好处中的详细信息。
于 2019-05-05T04:23:53.833 回答
1
其他人已经详细描述了它的好处，我在此解释一下我看到或使用过 OSGi 的实际用例。
- 在我们的一个应用程序中，我们有基于事件的流程，并且流程是在基于 OSGi 平台的插件中定义的，所以明天如果一些客户想要不同/额外的流程，那么他只需要再部署一个插件，从我们的控制台配置它，他就完成了.
- 它用于部署不同的 Store 连接器，例如，假设我们已经有 Oracle DB 连接器，明天需要连接 mongodb，然后编写一个新的连接器并部署它并通过控制台配置详细信息，然后您就完成了。连接器的部署由 OSGi 插件框架处理。
于 2016-12-23T07:39:00.203 回答