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的每个人来说，有很多好处(我现在只提醒了这些)。

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的每个人来说，有很多好处(我现在只提醒了这些)。

如果基于Java的应用程序需要添加或删除模块(扩展应用程序的基本功能)，而不需要关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本比较高，那么仅仅是为了更新或增强功能。

例子:

Eclipse:为插件的安装、卸载、更新和相互依赖提供了平台。 AEM: WCM应用程序，其中功能更改将由业务驱动，无法承担维护停机时间。

注意:Spring框架停止支持OSGI Spring包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。我个人是不会考虑OSGI的，除非绝对必要，比如在构建平台这样的大项目中。

OSGi提供了以下好处:

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

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

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

轻量级和可扩展的解决方案

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

我还不是OSGi的“粉丝”…

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

启动本地cba部署… [2/18/14 8:47:23 727 EST] 00000347 CheckForOasis

最终部署，“以下包将暂停，然后重新启动” 00000143 AriesApplicat I CWSAI0054I:作为应用程序更新操作的一部分

51分钟……每次代码改变…以前的版本(非osgi)在旧的开发机器上部署不到5分钟。

在一台有16g内存和40g空闲磁盘和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.