Java OSGi 解决了什么问题？

What does OSGi solve?

提问by Pablo Fernandez

I've read on Wikipedia and other sites about OSGi, but I don't really see the big picture. It says that it's a component-based platform, and that you can reload modules at runtime. Also the "practical example" given everywhere is the Eclipse Plugin Framework.

我已经在维基百科和其他网站上阅读了关于OSGi 的内容，但我并没有真正看到大局。它说它是一个基于组件的平台，您可以在运行时重新加载模块。此外，随处可见的“实际示例”是 Eclipse 插件框架。

My questions are:

我的问题是：

1. What is the clear and simple definition of OSGi?

2. What common problems does it solve?

1. OSGi 清晰简单的定义是什么？

2. 它解决了哪些常见问题？

By "common problems" I mean problems we face everyday, like "What can OSGi do for making our jobs more efficient/fun/simple?"

“常见问题”是指我们每天面临的问题，例如“OSGi 可以做什么来使我们的工作更高效/有趣/简单？”

回答by scubabbl

edited for clarity. OSGi page gave a better simple answer than mine

为清楚起见进行了编辑。OSGi 页面给出了比我的更好的简单答案

A simple answer: An OSGi Service Platform provides a standardized, component-oriented computing environment for cooperating networked services. This architecture significantly reduces the overall complexity of building, maintaining and deploying applications. The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restarts.

一个简单的答案：OSGi 服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种架构显着降低了构建、维护和部署应用程序的整体复杂性。OSGi 服务平台提供了在各种网络的设备上动态更改组成的功能，而无需重新启动。

In a single application structure, say the Eclipse IDE, it's not a big deal to restart when you install a new plugin. Using the OSGi implementation completely, you should be able to add plugins at runtime, get the new functionality, but not have to restart eclipse at all.

在单个应用程序结构中，例如 Eclipse IDE，安装新插件时重新启动并不是什么大问题。完全使用 OSGi 实现，您应该能够在运行时添加插件，获得新功能，但根本不必重新启动 eclipse。

Again, not a big deal for every day, small application use.

同样，每天使用小应用程序也没什么大不了的。

But, when you start to look at multi-computer, distributed application frameworks, that's where it starts to get interesting. When you have to have 100% uptime for critical systems, the capability to hotswap components or add new functionality at runtime is useful. Granted, there are capabilities for doing this now for the most part, but OSGi is trying to bundle everything into a nice little framework with common interfaces.

但是，当您开始查看多计算机分布式应用程序框架时，这就是开始变得有趣的地方。当您必须为关键系统提供 100% 的正常运行时间时，热交换组件或在运行时添加新功能的功能非常有用。诚然，现在大多数情况下都有这样做的能力，但 OSGi 正试图将所有东西都捆绑到一个带有通用接口的漂亮小框架中。

Does OSGi solve common problems, I'm not sure about that. I mean, it can, but the overhead may not be worth it for simpler problems. But it's something to consider when you are starting to deal with larger, networked, applications.

OSGi 是否解决了常见问题，我不确定。我的意思是，它可以，但对于更简单的问题，开销可能不值得。但是，当您开始处理更大的、联网的应用程序时，需要考虑这一点。

回答by Travis B. Hartwell

I've found the following benefits from OSGi:

我发现 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.

• 每个插件都是一个版本化的工件，有自己的类加载器。
• 每个插件都取决于它包含的特定 jar 以及其他特定版本的插件。
• 由于版本控制和隔离的类加载器，可以同时加载同一工件的不同版本。如果应用程序的一个组件依赖于插件的一个版本而另一个依赖于另一个版本，则它们可以同时加载。

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.

有了这个，您可以将您的应用程序构建为一组按需加载的版本化插件工件。每个插件都是一个独立的组件。正如 Maven 帮助您构建构建，使其可重复并由创建它的一组特定版本的工件定义，OSGi 帮助您在运行时执行此操作。

回答by Olaf Kock

I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?

我不太关心 OSGi 模块的热插拔性（至少目前是这样）。更多的是强制模块化。在任何时候都没有在类路径上提供数百万个“公共”类可以很好地防止循环依赖：您必须真正考虑您的公共接口 - 不仅仅是在 Java 语言构造“公共”方面，而且在您的库方面/module：你想让其他人使用的组件（确切地说）是什么？您真正需要实现功能的（确切地）接口（其他模块的）是什么？

It's nice, that hotplug comes with it, but I'd rather restart my usual applications than testing all combinations of hotplugability...

很好，热插拔是随附的，但我宁愿重新启动我常用的应用程序，也不愿测试所有热插拔能力的组合......

回答by Olaf Kock

It is also being used to bring additional portability of middleware and applications on the mobile side. Mobile side is available for WinMo, Symbian, Android for example. As soon as integration with device features occurs, can get fragmented.

它还被用于为移动端的中间件和应用程序带来额外的可移植性。移动端可用于 WinMo、Symbian、Android 等。一旦与设备功能集成，就会变得支离破碎。

回答by John John Pichler

• You can, analogically speaking, change the motor of your car without turning it off.
• You can customize complex systems for the customers. See the power of Eclipse.
• You can reuse entire components. Better than just objects.
• You use a stable platform to develop component based Applications. The benefits of this are huge.
• You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces.
• You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem.
• With OSGi you develop thinking to architect systems with CBD

• 打个比方，您可以在不关闭汽车的情况下更换汽车的电机。
• 您可以为客户定制复杂的系统。了解 Eclipse 的强大功能。
• 您可以重复使用整个组件。比对象更好。
• 您使用稳定的平台来开发基于组件的应用程序。这样做的好处是巨大的。
• 您可以使用黑盒概念构建组件。其他组件不需要知道隐藏的接口，它们只看到发布的接口。
• 您可以在同一系统中使用多个相同的组件，但在不同的版本中，而不会影响应用程序。OSGi 解决了 Jar Hell 问题。
• 使用 OSGi，您可以开发使用CBD构建系统的思维

There are a lot of benefits (I reminded just these now), available for everyone who uses Java.

有很多好处（我现在只提醒这些），每个使用 Java 的人都可以使用。

回答by Leen Toelen

At the very least, OSGi makes you THINK about modularity, code reuse, versioning and in general the plumbing of a project.

至少，OSGi 让你思考模块化、代码重用、版本控制以及一般的项目管道。

回答by eric

A Few Things that drive me nuts on OSGi:

一些让我对 OSGi 感到抓狂的事情：

1) The implentations and their context loaders have a lot of quirks to them, and can be somewhat async (We use felix inside of confluence). Compared to a pure spring (no DM) where [main] is pretty much running through everything sync.

1) 实现和它们的上下文加载器有很多怪癖，并且可能有点异步（我们在 confluence 中使用 felix）。与纯弹簧（无 DM）相比，[main] 几乎贯穿所有同步。

2)Classes are not equal after a hot load. Say, for instance you have a tangosol cache layer on hibernate. It is filled with Fork.class, outside of the OSGi scope. You hotload a new jar, and Fork has not changed. Class[Fork] != Class[Fork]. It also appears during serialization, for the same underlying causes.

2) 热加载后类不相等。比如说，例如您在休眠状态下有一个 tangosol 缓存层。它填充了 Fork.class，在 OSGi 范围之外。您热加载了一个新 jar，而 Fork 没有改变。类[叉] != 类[叉]。出于相同的根本原因，它也会在序列化期间出现。

3)Clustering.

3）聚类。

You can work around these things, but it is a major major pain, and makes your architecture look flawed.

您可以解决这些问题，但这是一个主要的痛点，并使您的架构看起来有缺陷。

And to those of you advertising the hotplugging.. OSGi's #1 Client? Eclipse. What does Eclipse do after loading the bundle?

还有那些宣传热插拔的人.. OSGi 的#1 客户端？蚀。加载包后 Eclipse 会做什么？

It restarts.

它重新启动。

回答by Abhishek Goel

what benefits does OSGi's component system provide you?
Well, Here is quite a list:

OSGi 的组件系统给你带来了什么好处？
好吧，这里有一个清单：

Reduced Complexity -Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well defined services. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.

降低复杂性 -使用 OSGi 技术进行开发意味着开发包：OSGi 组件。捆绑包是模块。它们对其他 bundle 隐藏其内部结构，并通过定义良好的服务进行通信。隐藏内部结构意味着以后可以更自由地进行更改。这不仅减少了错误的数量，还使包的开发更简单，因为大小合适的包通过定义良好的接口实现了一个功能。有一个有趣的博客描述了 OSGi 技术为他们的开发过程做了什么。

Reuse -The OSGi component model makes it very easy to use many third party components in an application. An increasing number of open source projects provide their JARs ready made for OSGi. However, commercial libraries are also becoming available as ready made bundles.

重用 -OSGi 组件模型使得在应用程序中使用许多第三方组件变得非常容易。越来越多的开源项目提供了为 OSGi 准备的 JAR。然而，商业图书馆也可以作为现成的捆绑包使用。

Real World -The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.

真实世界 -OSGi 框架是动态的。它可以动态更新包，服务可以来来去去。习惯于更传统 Java 的开发人员认为这是一个非常有问题的特性，而没有看到它的优势。然而，事实证明，现实世界是高度动态的，拥有可以来来去去的动态服务使这些服务与许多现实世界场景完美匹配。例如，服务可以为网络中的设备建模。如果检测到设备，则注册该服务。如果设备消失，则服务将被取消注册。与这种动态服务模型相匹配的真实场景数量惊人。因此，应用程序可以在它们自己的域中重用服务注册中心的强大原语（注册、获取、使用表达过滤器语言列出，以及等待服务出现和消失）。这不仅节省了编写代码的时间，还提供了全局可见性、调试工具以及比专用解决方案实现的更多功能。在这样一个动态环境中编写代码听起来像是一场噩梦，但幸运的是，有一些支持类和框架可以解决大部分（如果不是全部）痛苦。

Easy Deployment -The OSGi technology is not just a standard for components. It also specifies how components are installed and managed. This API has been used by many bundles to provide a management agent. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.

轻松部署 -OSGi 技术不仅仅是组件的标准。它还指定如何安装和管理组件。许多捆绑软件都使用此 API 来提供管理代理。该管理代理可以像命令外壳、TR-69 管理协议驱动程序、OMA DM 协议驱动程序、Amazon EC2 的云计算接口或 IBM Tivoli 管理系统一样简单。标准化的管理 API 使得在现有和未来系统中集成 OSGi 技术变得非常容易。

Dynamic Updates- The OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system. Many Java developers do not believe this can be done reliably and therefore initially do not use this in production. However, after using this in development for some time, most start to realize that it actually works and significantly reduces deployment times.

动态更新- OSGi 组件模型是一个动态模型。可以在不关闭整个系统的情况下安装、启动、停止、更新和卸载捆绑包。许多 Java 开发人员不相信这可以可靠地完成，因此最初不会在生产中使用它。但是，在开发中使用它一段时间后，大多数人开始意识到它确实有效并显着减少了部署时间。

Adaptive -The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide. This makes code more flexible and resilient to changes.

自适应 -OSGi 组件模型是从头开始设计的，以允许组件的混合和匹配。这要求需要指定组件的依赖关系，并且需要组件生活在其可选依赖项并不总是可用的环境中。OSGi 服务注册中心是一个动态注册中心，bundle 可以在其中注册、获取和监听服务。这种动态服务模型允许捆绑包找出系统上可用的功能并调整它们可以提供的功能。这使得代码更灵活，更能适应变化。

Transparency -Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles. For example, most frameworks provide a command shell that shows this internal state. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell.

透明度 -包和服务是 OSGi 环境中的一等公民。管理 API 提供对包的内部状态以及它如何连接到其他包的访问。例如，大多数框架都提供了一个显示这种内部状态的命令外壳。可以停止部分应用程序以调试某个问题，或者可以引入诊断包。 OSGi 应用程序通常可以使用实时命令 shell 进行调试，而不是盯着数百万行的日志输出和长时间的重启。

Versioning -OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.

版本控制 -OSGi 技术解决了 JAR 地狱。JAR 地狱是库 A 与库 B;version=2 一起工作，而库 C 只能与 B;version=3 一起工作的问题。在标准 Java 中，您很不走运。在 OSGi 环境中，所有 bundle 都经过仔细的版本控制，并且只有可以协作的 bundle 才会在同一个类空间中连接在一起。这允许包 A 和 C 使用它们自己的库运行。尽管不建议设计具有此版本控制问题的系统，但在某些情况下它可以挽救生命。

Simple -The OSGi API is surprisingly simple. The core API is only one package and less than 30 classes/interfaces. This core API is sufficient to write bundles, install them, start, stop, update, and uninstall them and includes all listener and security classes. There are very few APIs that provide so much functionality for so little API.

简单 -OSGi API 非常简单。核心API只有一个包，不到30个类/接口。这个核心 API 足以编写包、安装它们、启动、停止、更新和卸载它们，并且包括所有侦听器和安全类。很少有 API 能够为如此少的 API 提供如此多的功能。

Small -The OSGi Release 4 Framework can be implemented in about a 300KB JAR file. This is a small overhead for the amount of functionality that is added to an application by including OSGi. OSGi therefore runs on a large range of devices: from very small, to small, to mainframes. It only asks for a minimal Java VM to run and adds very little on top of it.

Small -OSGi Release 4 Framework 可以在大约 300KB 的 JAR 文件中实现。对于通过包含 OSGi 添加到应用程序的功能量来说，这是一个很小的开销。因此，OSGi 可以在各种设备上运行：从非常小的设备到小型的设备，再到大型机。它只需要一个最小的 Java VM 来运行，并且在它上面添加很少的内容。

Fast- One of the primary responsibilities of the OSGi framework is loading the classes from bundles. In traditional Java, the JARs are completely visible and placed on a linear list. Searching a class requires searching through this (often very long, 150 is not uncommon) list. In contrast, OSGi pre-wires bundles and knows for each bundle exactly which bundle provides the class. This lack of searching is a significant speed up factor at startup.

快速- OSGi 框架的主要职责之一是从包中加载类。在传统的 Java 中，JAR 是完全可见的并放置在一个线性列表中。搜索一个类需要搜索这个（通常很长，150 个并不少见）列表。相比之下，OSGi 预先连接了 bundle 并且知道每个 bundle 确切地是哪个 bundle 提供了类。缺乏搜索是启动时的一个重要加速因素。

Lazy -Lazy in software is good and the OSGi technology has many mechanisms in place to do things only when they are really needed. For example, bundles can be started eagerly, but they can also be configured to only start when other bundles are using them. Services can be registered, but only created when they are used. The specifications have been optimized several times to allow for these kind of lazy scenarios that can save tremendous runtime costs.

懒惰 -软件懒惰是好的，OSGi 技术有很多机制可以只在真正需要时才做事情。例如，bundle 可以急切地启动，但也可以将它们配置为仅在其他 bundle 使用它们时启动。服务可以被注册，但只能在使用时创建。规范已经过多次优化，以允许这种可以节省大量运行时间成本的惰性场景。

Secure -Java has a very powerful fine grained security model at the bottom but it has turned out very hard to configure in practice. The result is that most secure Java applications are running with a binary choice: no security or very limited capabilities. The OSGi security model leverages the fine grained security model but improves the usability (as well as hardening the original model) by having the bundle developer specify the requested security details in an easily audited form while the operator of the environment remains fully in charge. Overall, OSGi likely provides one of the most secure application environments that is still usable short of hardware protected computing platforms.

安全 -Java 在底层有一个非常强大的细粒度安全模型，但结果证明在实践中很难配置。结果是大多数安全的 Java 应用程序都以二元选择运行：没有安全性或功能非常有限。OSGi 安全模型利用了细粒度的安全模型，但通过让捆绑开发人员以易于审核的形式指定请求的安全详细信息，同时环境操作员仍然完全负责，从而提高了可用性（以及强化了原始模型）。总体而言，OSGi 可能提供了最安全的应用程序环境之一，除了受硬件保护的计算平台外，它仍然可用。

Non Intrusive -Applications (bundles) in an OSGi environment are left to their own. They can use virtually any facility of the VM without the OSGi restricting them. Best practice in OSGi is to write Plain Old Java Objects and for this reason, there is no special interface required for OSGi services, even a Java String object can act as an OSGi service. This strategy makes application code easier to port to another environment.

非侵入性 -OSGi 环境中的应用程序（包）由它们自己决定。他们几乎可以使用 VM 的任何设施，而不受 OSGi 的限制。OSGi 中的最佳实践是编写普通的旧 Java 对象，因此，OSGi 服务不需要特殊的接口，即使 Java 字符串对象也可以充当 OSGi 服务。这种策略使应用程序代码更容易移植到另一个环境。

Runs Everywhere -Well, that depends. The original goal of Java was to run anywhere. Obviously, it is not possible to run all code everywhere because the capabilities of the Java VMs differ. A VM in a mobile phone will likely not support the same libraries as an IBM mainframe running a banking application. There are two issue to take care of. First, the OSGi APIs should not use classes that are not available on all environments. Second, a bundle should not start if it contains code that is not available in the execution environment. Both of these issues have been taken care of in the OSGi specifications.

无处不在 -嗯，这取决于。Java 的最初目标是在任何地方运行。显然，由于 Java VM 的功能不同，因此不可能在任何地方运行所有代码。移动电话中的 VM 可能不支持与运行银行应用程序的 IBM 大型机相同的库。有两个问题需要处理。首先，OSGi API 不应使用并非在所有环境中都可用的类。其次，如果 bundle 包含在执行环境中不可用的代码，则不应启动它。OSGi 规范中已经解决了这两个问题。

Source : www.osgi.org/Technology/WhyOSGi

来源：www.osgi.org/Technology/WhyOSGi

回答by Masudul

The OSGi provides following benefit:

OSGi 提供以下好处：

■ A portable and secure execution environment based on Java

■ 基于Java 的可移植且安全的执行环境

■ A service management system, which can be used to register and share services across bundles and decouple service providers from service consumers

■ 一个服务管理系统，可用于跨捆绑注册和共享服务，并将服务提供者与服务消费者分离

■ A dynamic module system, which can be used to dynamically install and uninstall Java modules, which OSGi calls bundles

■ 动态模块系统，可用于动态安装和卸载 Java 模块，OSGi 称之为 bundles

■ A lightweight and scalable solution

■ 轻量级且可扩展的解决方案

回答by Kevin R

I am yet to be a "fan" of OSGi...

我还不是 OSGi 的“粉丝”...

I have been working with an enterprise application at Fortune 100 companies. Recently, the product we use has "upgraded" to an OSGi implementation.

我一直在财富 100 强公司使用企业应用程序。最近，我们使用的产品已“升级”为 OSGi 实现。

starting local cba deployment... [2/18/14 8:47:23:727 EST] 00000347 CheckForOasis

开始本地 cba 部署... [2/18/14 8:47:23:727 EST] 00000347 CheckForOasis

finally deployed and "the following bundles will be quiesced and then restarted" [2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I: As part of an update operation for application

最终部署并且“以下包将被停顿然后重新启动”[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I：作为应用程序更新操作的一部分

51 minutes... each time code changes... The previous version (non-OSGi) would deploy in less than 5 minutes on older development machines.

51 分钟...每次代码更改...之前的版本（非 OSGi）将在不到 5 分钟的时间内部署到旧的开发机器上。

on a machine with 16 gig ram and 40 free gig disk and Intel i5-3437U 1.9 GHz CPU

在具有 16 gig ram 和 40 个空闲 gig 磁盘和 Intel i5-3437U 1.9 GHz CPU 的机器上

The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.

这种升级的“好处”被作为改进（生产）部署出售——我们每年大约进行 4 次活动，每年可能进行 2-4 次小型修复部署。每天为 15 个人（QA 和开发人员）增加 45 分钟，我无法想象这是合理的。在大型企业应用程序中，如果您的应用程序是核心应用程序，那么更改它是正确的（小的更改有可能产生深远的影响 - 必须与整个企业的消费者进行沟通和计划），一个不朽的活动 - 错误的架构操作系统。如果您的应用程序不是企业应用程序 - 即每个消费者都可以拥有自己定制的模块，可能会在自己的孤岛数据库中访问自己的数据孤岛，并在托管许多应用程序的服务器上运行，那么也许可以看看 OSGi。至少，