OSGi 解决什么问题？
我在维基百科和其他网站上阅读过有关 OSGi 的内容，但我并没有真正看到什么图片。 它说它是一个基于组件的平台，并且您可以在运行时重新加载模块。 另外，到处给出的“实际示例”是 Eclipse Plugin Framework。
我的问题是：
OSGi 的清晰简单的定义是什么？
它解决了哪些常见问题？
我所说的“常见问题”是指我们每天面临的问题，例如“OSGi 可以做些什么来让我们的工作更高效/有趣/简单？”
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.
My questions are:
What is the clear and simple definition of OSGi?
What common problems does it solve?
By "common problems" I mean problems we face everyday, like "What can OSGi do for making our jobs more efficient/fun/simple?"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
虽然我认为 Abhishek Goel 的帖子是正确的，但我可以提出一个更简单的回应吗？
OSGi 允许您将功能单元（即插件）添加到您出色的软件中，而不会遇到通常涉及的许多令人头疼的问题。
一些例子：
已安装并且可以使用”
对于我的插件。
很难在我的代码中实现。
OSGi 解决了这些问题以及更多问题。
它可以帮助您创建编写起来并不那么困难的扩展，让您[大部分]摆脱“类加载器地狱”，一旦您掌握了它的窍门，它就会有很大的帮助。
只是想让你知道，这里涉及到一个学习曲线 - 不要指望在一周内掌握 OSGi，根据我的经验，将代码分解为模块化单元似乎有很大帮助，我不必重新编译整个应用程序，只需小部件并将其放入捆绑目录中，我们就可以开始使用了。 我使用 OSGi 已经有两个月了，我想我已经基本了解它了。 我认为时间花得值。
While I think the post by Abhishek Goel is right on the money, may I present a simpler response?
OSGi lets you add units of functionality (ie plugins) to your awesome software with out a lot of the headaches that are normally involved.
Some examples:
installed and it works'
for my plugin.
hard to implement in my code.
OSGi address these issues and more.
It can help you create extensions that are not all that hard to write, keeps you [mostly] out of 'classloader hell' and once you get the hang of it its a great help.
just to let you know, there IS a learning curve involved - dont expect to master OSGi in a week, its been my experience that breaking up code on to modular units seems to help a lot, I dont have to recompile the whole app, just small parts and drop it in to the bundles directory and we're ready to rock and roll. I've been using OSGi a LOT for just about 2 months now and I think I have it mostly figured out. I think its time well spent.
其官方网站上已经有一个相当有说服力的声明，我可以引用为
至于对开发商的好处？
请查看使用 OSGi 的好处中的详细信息。
There is already a quite convincing statement in its official site, I may quote as
As for the benefits to developer?
Please check the details in Benefits of Using OSGi.
它还用于为移动端的中间件和应用程序带来额外的可移植性。 移动端可用于 WinMo、Symbian、Android 等。 一旦与设备功能集成，就会变得支离破碎。
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.
至少，OSGi 让您思考模块化、代码重用、版本控制以及项目的总体管理。
At the very least, OSGi makes you THINK about modularity, code reuse, versioning and in general the plumbing of a project.
OSGi 具有以下优势：
■ 基于 Java 的可移植且安全的执行环境
■ 服务管理系统，可用于跨捆绑包注册和共享服务，并将服务提供者与服务使用者解耦
■ 动态模块系统，可使用动态安装和卸载
Java 模块，OSGi 将其称为捆绑包
■ 轻量级且可扩展的解决方案
The OSGi provides following benefit:
■ A portable and secure execution environment based on 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
■ A lightweight and scalable solution
其他人已经详细概述了 OSGi 的好处，我在此解释一下我见过或使用过 OSGi 的实际用例。
Others have already outlined the benefits in detail, I hereby explain the practical usecases I have either seen or used OSGi.
我已经使用 OSGi 工作了近 8 年左右，我不得不说，只有当您有在运行时更新、删除、安装或替换组件的业务需求时，您才应该考虑 OSGi。 这也意味着您应该具有模块化思维并理解模块化的含义。 有人认为 OSGi 是轻量级的 - 是的，确实如此，但还有一些其他轻量级且更易于维护和开发的框架。 确保java的安全也是如此。
OSGi 需要一个可靠的架构才能正确使用，并且制作 OSGi 系统非常容易，它可以很容易地成为一个独立的可运行 jar，而不涉及任何 OSGi。
I've been doing work with OSGi almost 8 or so years and I have to say that you should consider OSGi only if you have a business need to update, remove, install or replace a component on runtime. This also means that you should have a modular mindset and understanding what modularity means. There's some arguments that OSGi is lightweight - yes, that is true but there are also some other frameworks that are lightweight and easier to maintain and develop. Same goes to secure java blah blah.
OSGi requires a solid architecture to be used correctly and it's quite easy to make OSGi-system that could just as easily be a standalone-runnable-jar without any OSGi being involved.
我还不是 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 GB 内存和 40 GB 可用磁盘以及 Intel i5-3437U 1.9 GHz CPU 的机器上
这次升级的“好处”是作为改进（生产）部署而出售的 - 我们每年大约进行 4 次活动，可能有 2 次 -每年 4 次小型修复部署。 每天增加 45 分钟的时间给 15 个人（QA 和开发人员），我无法想象这是否合理。 在大型企业应用程序中，如果您的应用程序是核心应用程序，那么对其进行更改是正确的（微小的更改有可能产生深远的影响 - 必须与整个企业的消费者进行沟通和规划），这是一项重大活动 - 错误的架构操作系统Gi。 如果您的应用程序不是企业应用程序 - 即每个使用者都可以拥有自己定制的模块，可能会在自己的孤岛数据库中访问自己的数据孤岛并在托管许多应用程序的服务器上运行，那么也许可以看看 OSGi。 至少，这是我迄今为止的经验。
I am yet to be a "fan" of OSGi...
I have been working with an enterprise application at Fortune 100 companies. Recently, the product we use has "upgraded" to an OSGi implementation.
starting local cba deployment...
[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
51 minutes... each time code changes... The previous version (non-OSGi) would deploy in less than 5 minutes on older development machines.
on a machine with 16 gig ram and 40 free gig disk and 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.
如果基于 Java 的应用程序需要添加或删除模块（扩展应用程序的基本功能），而不关闭 JVM，则可以使用 OSGI。 通常如果关闭JVM的成本比较多，只是为了更新或者增强功能。
示例：
注意：Spring 框架停止支持 OSGI spring 捆绑包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。 我个人不会考虑 OSGI，除非它是绝对必要的，比如构建一个平台这样的大事情。
If a Java based application requires adding or removing modules (extending the base functionality of application), without shutting down the JVM, OSGI can be employed. Usually if the cost of shutting down JVM is more, just to update or to enhance functionality.
Examples:
Note: Spring framework stopped supporting OSGI spring bundles, considering it as unnecessary complexity for transaction based applications or for some point in these lines. I personally do not consider OSGI unless it is absolutely necessary, in something big like building a platform.
OSGi 让您的代码无缘无故地抛出
NoClassDefFoundError和ClassNotFoundException（很可能是因为您忘记在 OSGi 配置文件中导出包）； 因为它有 ClassLoaders，所以它可能会使您的类com.example.Foo无法转换为com.example.Foo，因为它实际上是由两个不同的类加载器加载的两个不同的类。 安装 Eclipse 插件后，它可以使您的 Eclipse 启动到 OSGi 控制台。对我来说，OSGi 只是增加了复杂性（因为它为我增加了一种心智模型），因为异常而增加了烦恼； 我从来没有真正需要它“提供”的活力。 它具有侵入性，因为它需要对所有模块进行 OSGi 捆绑配置； 这绝对不简单（在一个更大的项目中）。
因为我的不好的经历，我倾向于远离那个怪物，非常感谢。 我宁愿遭受 jar 依赖地狱的痛苦，因为这比 OSGi 引入的类加载器地狱更容易理解。
OSGi makes your code throw
NoClassDefFoundErrorandClassNotFoundExceptionfor no apparent reason (most probably because you forgot to export a package in OSGi configuration file); since it has ClassLoaders it can make your classcom.example.Foofail to be cast tocom.example.Foosince it's actually two different classes loaded by two different classloaders. It can make your Eclipse boot into an OSGi console after installing an Eclipse plugin.For me, OSGi only added complexity (because it added one more mental model for me to grok), added annoyances because of exceptions; I never really needed the dynamicity it "offers". It was intrusive since it required OSGi bundle configuration for all modules; it was definitely not simple (in a larger project).
Because of my bad experience, I tend to stay away from that monster, thank you very much. I'd rather suffer from jar dependency hell, since that's way way more easily understandable than the classloader hell OSGi introduces.
有几件事让我对 OSGi 着迷：
1）实现及其上下文加载器有很多怪癖，并且可能有点异步（我们在 confluence 内部使用 felix）。 与纯 spring（无 DM）相比，[main] 几乎同步运行所有内容。
2）热加载后类不相等。 比如说，您在 hibernate 上有一个 tangosol 缓存层。 它充满了 OSGi 范围之外的 Fork.class。 你热加载了一个新的 jar，并且 Fork 没有改变。 类[叉] != 类[叉]。 出于相同的根本原因，它也会在序列化期间出现。
3）聚类。
您可以解决这些问题，但这是一个主要的痛苦，并且使您的架构看起来有缺陷。
对于那些热插拔广告的人来说……OSGi 的#1 客户端？ 蚀。 加载包后 Eclipse 会做什么？
它重新启动。
A Few Things that drive me nuts on 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.
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.
3)Clustering.
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?
It restarts.
为清楚起见进行了编辑。 OSGi 页面给出了比我的更好的简单答案
一个简单的答案：OSGi 服务平台为协作网络服务提供了标准化的、面向组件的计算环境。 这种架构显着降低了构建、维护和部署应用程序的整体复杂性。
OSGi服务平台提供了在各种网络的设备上动态更改组合的功能，而无需重新启动。
在单个应用程序结构中，例如 Eclipse IDE，安装新插件时重新启动并不是什么大问题。 完全使用 OSGi 实现，您应该能够在运行时添加插件，获得新功能，但根本不必重新启动 eclipse。
再说一遍，对于日常小型应用程序使用来说没什么大不了的。
但是，当您开始研究多计算机、分布式应用程序框架时，它就开始变得有趣了。 当关键系统必须具有 100% 的正常运行时间时，热插拔组件或在运行时添加新功能的功能非常有用。 诚然，现在大多数情况下都有执行此操作的功能，但 OSGi 正在尝试将所有内容捆绑到一个具有通用接口的漂亮小框架中。
OSGi 是否解决了常见问题，我不确定。 我的意思是，它可以，但对于更简单的问题来说，开销可能不值得。 但当您开始处理更大的网络应用程序时，这是需要考虑的事情。
edited for clarity. OSGi page gave a better simple answer than mine
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.
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.
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.
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 模块的热插拔性（至少目前如此）。 这更多的是强制的模块化。 类路径上任何时候都没有数以百万计的“公共”类可以很好地防止循环依赖：您必须真正考虑您的公共接口 - 不仅是在 java 语言构造“公共”方面，而且是在您的库方面/module：您希望向其他人提供哪些（确切的）组件？ 您真正需要哪些（确切的）接口（其他模块的）来实现您的功能？
很好，它附带了热插拔功能，但我宁愿重新启动我常用的应用程序，也不愿测试所有热插拔性组合......
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?
It's nice, that hotplug comes with it, but I'd rather restart my usual applications than testing all combinations of hotplugability...
有很多好处（我提醒现在就这些），适用于所有使用 Java 的人。
There are a lot of benefits (I reminded just these now), available for everyone who uses Java.
我发现 OSGi 有以下好处：
这样，您可以将应用程序构建为一组按需加载的版本化插件工件。 每个插件都是一个独立的组件。 正如 Maven 帮助您构建构建，使其可重复并由创建它的一组特定版本的工件定义一样，OSGi 可以帮助您在运行时执行此操作。
I've found the following benefits from OSGi:
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.
OSGi 的组件系统为您提供了哪些好处？
好吧，这里有一个相当多的列表：
降低复杂性 - 使用 OSGi 技术进行开发意味着开发捆绑包：OSGi 组件。 捆绑包是模块。 它们向其他包隐藏其内部结构，并通过明确定义的服务进行通信。 隐藏内部结构意味着以后可以更自由地进行更改。 这不仅减少了错误的数量，还使捆绑包的开发更加简单，因为正确大小的捆绑包通过定义良好的接口实现了一项功能。 有一个有趣的博客描述了 OSGi 技术对其开发过程的作用。
重用 - OSGi 组件模型使得在应用程序中使用许多第三方组件变得非常容易。 越来越多的开源项目为 OSGi 提供现成的 JAR。 然而，商业库也可以作为现成的捆绑包提供。
现实世界- OSGi 框架是动态的。 它可以动态更新捆绑包，并且服务可以来来去去。 习惯使用传统 Java 的开发人员认为这是一个非常有问题的功能，并且看不到其中的优势。 然而，事实证明，现实世界是高度动态的，并且具有可来可去的动态服务，使得这些服务能够完美匹配许多现实世界场景。 例如，服务可以对网络中的设备进行建模。 如果检测到该设备，则注册该服务。 如果设备消失，则服务将被取消注册。 有数量惊人的现实场景与这种动态服务模型相匹配。 因此，应用程序可以在自己的域中重用服务注册表的强大原语（使用表达过滤器语言注册、获取、列出，以及等待服务出现和消失）。 这不仅节省了编写代码的时间，还提供了全局可见性、调试工具以及比专用解决方案实现的更多功能。 在这样的动态环境中编写代码听起来像是一场噩梦，但幸运的是，有支持类和框架可以减轻大部分（如果不是全部）痛苦。
轻松部署 - OSGi 技术不仅仅是组件标准。 它还指定如何安装和管理组件。 许多捆绑包都使用此 API 来提供管理代理。 该管理代理可以像命令 shell、TR-69 管理协议驱动程序、OMA DM 协议驱动程序、Amazon EC2 的云计算接口或 IBM Tivoli 管理系统一样简单。 标准化的管理 API 使得将 OSGi 技术集成到现有和未来的系统中变得非常容易。
动态更新 - OSGi 组件模型是一个动态模型。 可以安装、启动、停止、更新和卸载捆绑包，而无需关闭整个系统。 许多 Java 开发人员认为这不能可靠地完成，因此最初不在生产中使用它。 然而，在开发中使用它一段时间后，大多数人开始意识到它确实有效并且显着减少了部署时间。
自适应 - OSGi 组件模型是从头开始设计的，允许组件的混合和匹配。 这要求需要指定组件的依赖关系，并且要求组件生活在其可选依赖关系并不总是可用的环境中。 OSGi 服务注册表是一个动态注册表，bundle 可以在其中注册、获取和侦听服务。 这种动态服务模型允许捆绑包找出系统上可用的功能并调整它们可以提供的功能。 这使得代码更加灵活并且能够适应变化。
透明度 - 捆绑包和服务是 OSGi 环境中的一流公民。 管理 API 提供对包的内部状态以及它如何连接到其他包的访问。 例如，大多数框架都提供显示此内部状态的命令 shell。 可以停止部分应用程序来调试某个问题，或者可以引入诊断包。通常可以使用实时命令 shell 来调试 OSGi 应用程序，而不是盯着数百万行日志输出和长时间的重新启动时间。
版本控制 - OSGi 技术解决了 JAR 地狱问题。 JAR hell 的问题是库 A 可以与库 B;version=2 一起使用，但库 C 只能与 B;version=3 一起使用。 在标准 Java 中，你运气不好。 在 OSGi 环境中，所有捆绑包都经过仔细的版本控制，并且只有可以协作的捆绑包才会在同一类空间中连接在一起。 这允许捆绑包 A 和 C 都可以使用自己的库运行。 尽管不建议设计具有此版本控制问题的系统，但在某些情况下它可以成为救星。
简单 - OSGi API 非常简单。 核心API只有一个包，不到30个类/接口。 此核心 API 足以编写捆绑包、安装它们、启动、停止、更新和卸载它们，并包含所有侦听器和安全类。 很少有 API 能够为如此少的 API 提供如此多的功能。
小 - OSGi Release 4 框架可以在大约 300KB 的 JAR 文件中实现。 对于通过包含 OSGi 添加到应用程序的功能量来说，这是一个很小的开销。 因此，OSGi 可以在多种设备上运行：从非常小的设备到小型设备，再到大型机。 它只要求运行一个最小的 Java VM，并且在其之上添加很少的内容。
快速 - OSGi 框架的主要职责之一是从包中加载类。 在传统的 Java 中，JAR 是完全可见的并放置在线性列表中。 搜索一个类需要搜索这个列表（通常很长，150 个并不罕见）。 相比之下，OSGi 预先连接捆绑包，并准确地知道每个捆绑包是哪个捆绑包提供该类。 缺乏搜索是启动时的一个重要加速因素。
惰性 - 软件中的惰性是好的，OSGi 技术有许多机制，仅在真正需要时才执行操作。 例如，捆绑包可以立即启动，但也可以将它们配置为仅在其他捆绑包使用它们时启动。 服务可以注册，但只有在使用时才创建。 该规范已经过多次优化，以允许此类惰性场景，从而节省巨大的运行时间成本。
安全 - Java 在底层有一个非常强大的细粒度安全模型，但在实践中却很难配置。 结果是大多数安全的 Java 应用程序都以二元选择运行：没有安全性或功能非常有限。 OSGi 安全模型利用细粒度安全模型，但通过让捆绑包开发人员以易于审核的形式指定所请求的安全详细信息，同时环境操作员仍然完全负责，从而提高了可用性（以及强化原始模型）。 总体而言，OSGi 可能提供最安全的应用程序环境之一，在缺乏硬件保护的计算平台的情况下仍然可用。
非侵入式 - OSGi 环境中的应用程序（捆绑包）由其自己管理。 他们几乎可以使用虚拟机的任何功能，而不受 OSGi 的限制。 OSGi 中的最佳实践是编写普通的旧 Java 对象，因此，OSGi 服务不需要特殊的接口，甚至 Java String 对象也可以充当 OSGi 服务。 此策略使应用程序代码更容易移植到另一个环境。
到处运行 - 嗯，这要看情况。 Java 最初的目标是在任何地方运行。 显然，不可能在任何地方运行所有代码，因为 Java VM 的功能不同。 移动电话中的虚拟机可能不支持与运行银行应用程序的 IBM 大型机相同的库。 有两个问题需要注意。 首先，OSGi API 不应使用并非在所有环境中都可用的类。 其次，如果包包含执行环境中不可用的代码，则不应启动该包。 OSGi 规范中已经解决了这两个问题。
来源：www.osgi.org/Technology/WhyOSGi
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.
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.
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.
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.
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.
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 - 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.
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 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.
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.
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.
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.
Source : www.osgi.org/Technology/WhyOSGi