What does OSGi solve?(OSGi 解决了什么问题?)

问题描述

我在 Wikipedia 和其他网站上阅读过有关 OSGi 的信息，但我并不真正了解看大图.它说它是一个基于组件的平台，并且您可以在运行时重新加载模块.此外，到处给出的实际示例"是 Eclipse 插件框架.

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.

我的问题是:

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

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

解决了哪些常见问题?

我所说的常见问题"是指我们每天面临的问题，例如OSGi 可以做些什么来让我们的工作更高效/有趣/简单?"

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

推荐答案

OSGi的组件系统给你带来了什么好处?
嗯，这是一个相当多的清单:

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

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

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 提供了现成的 JAR.但是，商业库也可以作为现成的捆绑包提供.

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

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

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

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

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

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

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 API 非常简单.核心 API 只有一个包，不到 30 个类/接口.这个核心 API 足以编写包、安装包、启动、停止、更新和卸载包，并且包括所有侦听器和安全类.很少有 API 能够为这么少的 API 提供这么多的功能.

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.

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

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.

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

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.

Lazy - 软件中的 Lazy 是好的，OSGi 技术有许多机制可以只在真正需要时才做事.例如，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.

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

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.

非侵入式 - OSGi 环境中的应用程序(捆绑包)由它们自己处理.他们几乎可以使用 VM 的任何设施，而不受 OSGi 的限制.OSGi 的最佳实践是编写普通的旧 Java 对象，因此，OSGi 服务不需要特殊的接口，即使是 Java 字符串对象也可以充当 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.

无处不在 - 好吧，这取决于.Java 最初的目标是在任何地方运行.显然，不可能在任何地方运行所有代码，因为 Java VM 的功能不同.移动电话中的 VM 可能不支持与运行银行应用程序的 IBM 大型机相同的库.有两个问题需要处理.首先，OSGi API 不应使用并非在所有环境中都可用的类.其次，如果包包含在执行环境中不可用的代码，则不应启动它.这两个问题都在 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.

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

这篇关于OSGi 解决了什么问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！