它还被用于在移动端带来额外的中间件和应用程序的可移植性。移动端可用于WinMo, Symbian, Android等。一旦与设备功能集成，就会出现碎片化。

在OSGi上让我抓狂的几件事:

1)实现和它们的上下文加载器有很多怪癖，并且可能有点异步(我们在confluence中使用felix)。与纯spring(没有DM)相比，[main]几乎运行了所有同步。

2)热加载后类不相等。例如，在hibernate上有一个tangosol缓存层。它被Fork.class填充，在OSGi作用域之外。你热加载了一个新的罐子，Fork没有改变。Class[Fork] != Class[Fork]。由于相同的潜在原因，它也会在序列化过程中出现。

3)集群。

您可以解决这些问题，但这是一个非常麻烦的问题，并且会使您的体系结构看起来有缺陷。

对于那些为热插拔做广告的人。OSGi的#1客户端?Eclipse。Eclipse在加载包之后做什么?

它重新启动。

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

对于使用Java的每个人来说，有很多好处(我现在只提醒了这些)。

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提供了现成的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.

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开发人员不相信这可以可靠地完成，因此最初没有在生产中使用它。然而，在开发中使用它一段时间后，大多数人开始意识到它实际上是有效的，并显著减少了部署时间。

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.

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.

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提供如此多的功能。

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

快速——OSGi框架的主要职责之一是从bundle中加载类。在传统Java中，jar是完全可见的，并放置在一个线性列表中。搜索类需要搜索这个列表(通常很长，150个也很常见)。相反，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 String对象也可以充当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让您考虑到模块化、代码重用、版本控制以及项目的一般管道。

其他人已经详细概述了OSGi的好处，我在此解释我所见过或使用过的实际用例。

In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done. It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.