我在维基百科和其他网站上读过有关OSGi的内容，但我并没有真正看到全局。它说它是一个基于组件的平台，您可以在运行时重新加载模块。另外，给出的“实际示例”是Eclipse插件框架。
我的问题是：
OSGi的清晰简单定义是什么？
它解决了哪些常见问题？
“常见问题”我指的是我们每天面临的问题，例如“OSGi可以做些什么来提高我们的工作效率/乐趣/简单？”
答案 0 :(得分：89)
降低复杂性 - 使用OSGi技术开发意味着开发捆绑包：OSGi组件。捆绑包是模块。他们将自己的内部隐藏在其他捆绑包中，并通过定义良好的服务进行通信。隐藏内部意味着以后可以更自由地改变。这不仅减少了错误的数量，而且还使捆绑包更容易开发，因为正确大小的捆绑包通过定义良好的接口实现了一项功能。有一个有趣的博客描述了OSGi技术为其开发过程所做的工作。
重用 - OSGi组件模型使得在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目为OSGi提供了准备好的JAR。但是，商业图书馆也可以作为现成的捆绑包使用。
真实世界 - OSGi框架是动态的。它可以动态更新捆绑包，服务可以来去。过去使用更传统的Java的开发人员认为这是一个非常有问题的功能，并且看不到优势。然而，事实证明，现实世界是高度动态的，并且具有可以来来去去的动态服务使得服务成为许多现实世界场景的完美匹配。例如，服务可以为网络中的设备建模。如果检测到设备，则注册该服务。如果设备消失，则服务未注册。有许多与这种动态服务模型相匹配的真实场景。因此，应用程序可以在自己的域中重用服务注册表的强大原语（注册，获取，使用富有表现力的过滤语言列表，并等待服务出现和消失）。这不仅节省了编写代码，还提供了全局可见性，调试工具以及比专用解决方案实现的更多功能。在这样一个动态环境中编写代码听起来像是一场噩梦，但幸运的是，有一些支持类和框架可以消除大部分（如果不是全部）痛苦。
轻松部署 - OSGi技术不仅仅是组件的标准。它还指定了如何安装和管理组件。许多捆绑包使用此API来提供管理代理。该管理代理可以像命令外壳，TR-69管理协议驱动程序，OMA DM协议驱动程序，用于Amazon EC2的云计算接口或IBM Tivoli管理系统一样简单。标准化管理API使OSGi技术在现有和未来系统中的集成变得非常容易。
动态更新 - OSGi组件模型是动态模型。可以安装，启动，停止，更新和卸载软件包，而无需关闭整个系统。许多Java开发人员不相信这可以可靠地完成，因此最初不会在生产中使用它。但是，在开发中使用它一段时间之后，大多数人开始意识到它确实可以工作并显着缩短了部署时间。
自适应 - OSGi组件模型从头开始设计，允许组件的混合和匹配。这要求需要指定组件的依赖关系，并且它要求组件存在于其可选依赖关系并不总是可用的环境中。 OSGi服务注册表是一个动态注册表，捆绑包可以注册，获取和侦听服务。这种动态服务模型允许捆绑包找出系统上可用的功能并调整它们可以提供的功能。这使代码更灵活，更适应变化。
透明度 - 捆绑包和服务是OSGi环境中的一等公民。管理API提供对捆绑包内部状态的访问以及它与其他捆绑包的连接方式。例如，大多数框架都提供了一个显示此内部状态的命令shell。可以停止部分应用程序来调试某个问题，或者可以引入诊断包。而不是盯着数百万行日志记录输出和长启动时间，OSGi应用程序通常可以使用实时命令shell进行调试。
版本控制 - OSGi技术解决了JAR地狱问题。 JAR地狱是库A与库B一起工作的问题;版本= 2，但库C只能用于B;版本= 3。在标准Java中，你运气不好。在OSGi环境中，所有捆绑包都经过精心版本化，只有可以协作的捆绑包在同一个类空间中连接在一起。这允许bundle A和C都可以使用自己的库。虽然不建议设计具有此版本问题的系统，但在某些情况下它可以节省生命。
简单 - OSGi API非常简单。核心API只有一个包，少于30个类/接口。这个核心API足以编写捆绑包，安装它们，启动，停止，更新和卸载它们，并包括所有监听器和安全类。很少有API为这么少的API提供如此多的功能。
小 - OSGi第4版框架可以在大约300KB的JAR文件中实现。对于通过包含OSGi添加到应用程序的功能量来说，这是一个很小的开销。因此，OSGi可以在很多设备上运行：从小型到小型，再到大型机。它只要求运行一个最小的Java VM，并且在它之上添加很少。
快速 - OSGi框架的主要职责之一是从bundle加载类。在传统的Java中，JAR完全可见并放在线性列表中。搜索一个类需要搜索这个（通常很长，150并不罕见）列表。相比之下，OSGi预先捆绑捆绑并且知道每个捆绑包确切地提供了哪个捆绑类。缺乏搜索是启动时显着的加速因素。
懒惰 - 懒惰的软件很好，OSGi技术有很多机制可以在真正需要的时候做事。例如，可以急切地启动bundle，但也可以将它们配置为仅在其他bundle使用它们时启动。服务可以注册，但只能在使用时创建。规范已经多次优化，以允许这种可以节省巨大运行时成本的惰性场景。
安全 - Java在底部有一个非常强大的细粒度安全模型，但实际上很难配置。结果是大多数安全的Java应用程序都以二进制选择运行：没有安全性或功能非常有限。 OSGi安全模型利用细粒度安全模型，但通过让开发人员以易于审核的形式指定所请求的安全性详细信息，同时环境操作员仍然完全负责，从而提高可用性（以及加强原始模型）。总的来说，OSGi可能提供最安全的应用程序环境之一，仍然可以使用硬件保护的计算平台。
非侵入性 OSGi环境中的应用程序（软件包）由它们自己保留。他们几乎可以使用虚拟机的任何设施，而无需OSGi限制它们。 OSGi中的最佳实践是编写Plain Old Java Objects，因此，OSGi服务不需要特殊的接口，即使Java String对象也可以充当OSGi服务。此策略使应用程序代码更容易移植到另一个环境。
无处不在 - 嗯，这取决于。 Java的最初目标是在任何地方运行。显然，由于Java VM的功能不同，所以无法在任何地方运行所有代码。移动电话中的VM可能不支持与运行银行应用程序的IBM大型机相同的库。有两个问题要照顾。首先，OSGi API不应使用并非在所有环境中都可用的类。其次，如果bundle包含执行环境中不可用的代码，则不应该启动它。这两个问题都已在OSGi规范中得到了解决。
答案 1 :(得分：87)
我从OSGi中找到了以下好处：
通过这种方式，您可以将应用程序构建为一组按需加载的版本化插件工件。每个插件都是一个独立的组件。正如Maven帮助您构建构建所以它是可重复的并由它创建的一组特定版本的工件定义，OSGi可以帮助您在运行时执行此操作。
答案 2 :(得分：57)
我不太关心OSGi模块的热插拔（至少目前）。它更像是强制模块化。在任何时候类路径上都没有数百万个“公共”类可以很好地保护循环依赖：你必须真正考虑你的公共接口 - 不只是在java语言结构“public”方面，而是在你的库方面/ module：您希望为其他人提供哪些（确切）组件？你真正需要实现功能的接口（确切地）是什么（确切）？
很好，热插拔附带它，但我宁愿重新启动我常用的应用程序而不是测试所有热插拔组合......
答案 3 :(得分：19)
有许多好处（我现在提醒了这些好处），适用于使用Java的每个人。
答案 4 :(得分：13)
为了清晰起见而编辑。 OSGi页面提供了比我的更简单的答案
一个简单的答案：OSGi服务平台为合作的网络服务提供标准化的，面向组件的计算环境。此体系结构显着降低了构建，维护和部署应用程序的总体复杂性。 OSGi服务平台提供了在各种网络设备上动态更改组合的功能，无需重启。
在单个应用程序结构中，比如Eclipse IDE，在安装新插件时重启并不是什么大问题。完全使用OSGi实现，您应该能够在运行时添加插件，获得新功能，但根本不必重新启动eclipse。
同样，对于每天使用不多的小应用程序来说并不是什么大问题。
但是，当你开始关注多计算机，分布式应用程序框架时，它就开始变得有趣了。当您必须为关键系统提供100％的正常运行时间时，在运行时热交换组件或添加新功能的功能非常有用。当然，大多数情况下都有这样做的功能，但OSGi正试图将所有内容捆绑到一个带有通用接口的漂亮小框架中。
OSGi是否解决了常见问题，我对此并不确定。我的意思是，它可以，但对于更简单的问题，开销可能不值得。但是，当您开始处理更大的网络应用程序时，需要考虑这一点。
答案 5 :(得分：10)
一些让我对OSGi感到困惑的事情：
1）实现及其上下文加载器对它们有很多怪癖，并且可能有点异步（我们在汇合中使用felix）。与纯弹簧（无DM）相比，[main]几乎贯穿所有同步。
2）热负荷后类不相等。比方说，例如你在休眠上有一个tangosol缓存层。它在OSGi范围之外填充了Fork.class。你热装了一个新的jar，而且没有改变。 Class [Fork]！= Class [Fork]。在序列化期间，它也会出现相同的潜在原因。
3）的聚类。
你可以解决这些问题，但这是一个重大的痛苦，并使你的架构看起来有缺陷。
对于那些广告热插拔的人... OSGi的＃1客户？日食。 Eclipse加载捆绑包后会做什么？
重启。
答案 6 :(得分：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个免费演出磁盘以及Intel i5-3437U 1.9 GHz CPU的计算机上
此升级的“好处”作为改进（生产）部署出售 - 我们每年进行4次活动，每年可能进行2-4次小型修复部署。每天给15个人（QA和开发人员）增加45分钟，我无法想象有没有理由。在大型企业应用程序中，如果您的应用程序是核心应用程序，那么改变它就是正确的（小的变化有可能产生深远的影响 - 必须与整个企业的消费者进行沟通和规划），这是一项巨大的活动 - 错误的架构OSGi的。如果您的应用程序不是企业应用程序 - 即每个消费者可以拥有自己的定制模块，可能在自己的孤岛数据库中点击他们自己的数据孤岛并在托管许多应用程序的服务器上运行，那么可以查看OSGi。至少，这是我迄今为止的经历。
答案 7 :(得分：5)
OSGi使您的代码抛出NoClassDefFoundError和ClassNotFoundException没有明显的原因（很可能是因为您忘记在OSGi配置文件中导出包）;由于它具有ClassLoader，因此它可以使您的类com.example.Foo无法转换为com.example.Foo，因为它实际上是由两个不同的类加载器加载的两个不同的类。它可以在安装Eclipse插件后将Eclipse引导到OSGi控制台。
对我来说，OSGi只增加了复杂性（因为它为我增加了一个心理模型），因为例外而增加了烦恼;我从来没有真正需要它“提供”的动态性。它是侵入性的，因为它需要所有模块的OSGi捆绑配置;这绝对不简单（在一个更大的项目中）。
由于我的经历不好，我倾向于远离那个怪物，非常感谢你。我宁愿忍受jar依赖地狱，因为这比OSGi引入的类加载器更容易理解。
答案 8 :(得分：4)
如果基于Java的应用程序需要添加或删除模块（扩展应用程序的基本功能），而无需关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本更高，只需更新或增强功能。
<强>实施例：
注意：Spring框架停止支持OSGI spring捆绑包，将其视为基于事务的应用程序或这些行中的某些点的不必要的复杂性。我个人不会考虑OSGI，除非它是绝对必要的，比如建立一个平台。
答案 9 :(得分：2)
OSGi提供以下好处：
■基于Java的可移植且安全的执行环境
■服务管理系统，可用于跨捆绑注册和共享服务，并将服务提供者与服务使用者分离
■动态模块系统，可用于动态安装和卸载 Java模块，OSGi称之为捆绑包
■轻量级且可扩展的解决方案
答案 10 :(得分：1)
它还被用于在移动端带来中间件和应用程序的额外可移植性。移动端可用于WinMo，Symbian，Android等。一旦与设备功能集成，就会出现碎片。
答案 11 :(得分：1)
至少，OSGi让您思考模块化，代码重用，版本控制以及项目的管道。
答案 12 :(得分：1)
其他人已经详细说明了这些好处，我在此解释了我见过或使用过OSGi的实用用例。
答案 13 :(得分：1)
我使用OSGi已有将近8年的时间，我不得不说，只有在业务需要在运行时更新，删除，安装或更换组件的情况下，才应考虑使用OSGi。这也意味着您应该具有模块化的心态，并了解模块化的含义。有一些论点认为OSGi是轻量级的-是的，的确如此，但是还有其他一些轻量级的框架，它们易于维护和开发。安全java等等也是如此。
OSGi需要可靠的体系结构才能正确使用，并且很容易使OSGi系统成为独立运行的jar，而无需涉及任何OSGi。
答案 14 :(得分：0)
在其官方网站上已经有一个令人信服的声明，我可以引用为
OSGi技术如此成功的关键原因在于，它提供了非常强大的成熟组件系统，该系统实际上可以在各种环境中工作。 OSGi组件系统实际上用于构建高度复杂的应用程序，例如IDE（Eclipse），应用程序服务器（GlassFish，IBM Websphere，Oracle / BEA Weblogic，Jonas，JBoss），应用程序框架（Spring，Guice），工业自动化，住宅网关，手机等等。
至于对开发人员的好处？
开发人员：OSGi通过为当今的大型分布式系统以及小型嵌入式应用程序提供模块化体系结构来降低复杂性。内部和现成的模块构建系统大大降低了复杂性，从而降低了开发和维护费用。 OSGi编程模型实现了基于组件的系统的承诺。
请检查Benefits of Using OSGi中的详细信息。