使用osgi开发应用程序

Question

我正在开发基于语义的搜索应用程序在Java中。为了使应用程序模块化，我想使用osgi架构。但由于我是osgi的新手，我不知道使用它的优缺点。任何人都可以解释使用osgi的优点/缺点，以及通过使用osgi会使应用程序获益的是哪种应用程序？

谢谢！

Answer 1

简而言之，OSGi是一个用于构建模块化应用程序的标准。它增加了新的模块化级别 - 捆绑（即组件，模块）。每个包中包含的类和接口，什么才是最重要的是必须明确说明：

• 其中其他组件或Java包，它使用，
• 和包，它希望暴露给其他组件使用。

从技术角度来看捆绑包是jar文件，它有点扩展了META-INF/MANIFEST.MF文件。所有上述信息都存储在MANIFEST.MF文件中。

从实践的角度来看，这种显性既有优点也有缺点。对我来说，最大的优势是你不得不考虑你的架构，模块和它们之间的交互，而不是标准应用程序。这可能会创建更好的架构，其中每个模块负责定义明确的任务，并且可以重新使用模块。如果遇到缺点，创建大量模块有时可能会很痛苦。有很多模块是很容易的，如果你真的有很多模块，可能很难保持模块之间的所有依赖关系（依赖周期非常痛苦）。

OSGi不仅是建筑模块化应用的标准。它还指定捆绑包存在并运行的环境。这是您应该注意的事情 - 使用OSGi时，您必须在特殊环境中启动应用程序。此环境（例如Eclipse Equinox）负责运行您的应用程序。它提供了一些奇特的可能性。例如，你可以添加一个包到已经运行的应用程序，而不需要停止这个应用程序 - 这可能是一些非常重要的元素在某些类型的应用程序中（但恕我直言，没有那么多的应用程序真的需要这个）。

真正重要的还有一个事实，即某些开源库可能与OSGi基础架构不完全兼容，并且可能很难在标准Java应用程序中使用它们（请记住，在OSGi一切应该是一揽子）。然而，许多流行的库被包装成捆绑 - 例如Spring提供了其包含许多流行库（但不是全部）的bundles repository。

OSGi相当复杂，很难用几句话来描述它及其可能性。我写的只是OSGi中最重要的（IMO）元素。但OSGI更多，例如捆绑可以发送事件给对方，他们可以为对方提供服务。如果您对更多细节感兴趣，我建议您阅读教程。我可能会推荐this one in Java World。之后，你可以看看关于OSGi的this free e-book（它包含了很多细节）。关于OSGi的所有细节都可以在官方的规范中找到，但我不会说他们很容易阅读（至少在开始时） - 你可以找到他们here（在下载之前，你将不得不接受许可证和一些法律声明） 。

总而言之，我认为OSGi在构建模块化应用程序时很有用，但这肯定不是免费的。这是一个相当重的标准，可能会阻止你做一些事情，并迫使你做的东西OSGi方式。

SO一些相关的问题：

• What does OSGi solve?
• What's the best way to get started with OSGI?
• Can OSGi help reduce complexity?
• Has anyone found OSGi to be useful in corporate applications?

Answer 2

你需要写一本书才能正确回答这个问题。事实上，许多书都是关于这个主题的。如果你真的想了解OSGi，我建议你找一本这样的书。

OSGi是一个Java模块化框架。它在这个领域没有任何可信的竞争。任何应用程序都可以受益于更加模块化，但模块化不是免费的。把所有东西都放到一个巨大的类加载器中并且不要太想你的组件之间的关系更容易。如果您决定尝试使用OSGi，那么属于Eclipse的优秀PDE工具确实支持非Eclipse定位的OSGi开发，并且使OSGi更易于使用。

Answer 3

我个人的看法是，OSGi的带来的不仅仅是利益更多的痛苦。如果你真的需要一个可插入的应用程序，你可能会开始使用OSGi，但是你需要以可插入的方式编写代码，这是不简单的（即使在eclipse中安装插件时，它建议重新启动eclipse，不知道为什么它使用OSGi）

我在工作中使用OSGi开发了两个项目，它在项目开始时非常缓慢，因为您需要包装很多公共库，而不是所有这些库都可以包装，因为在使用代理对象时，由于类加载器问题，您可能会在运行时遇到ClassNotDefoundError。

我们在使用OSGi的项目中使用的所有模块化都可以使用maven来实现，当使用OSGi时，没有人会强制您编写大量细粒度的bundle，如果您希望您可以在一个大的束。

如果我们讨论组件之间的丢失耦合，可以使用spring-core或google-guice依赖注入框架中的自动布线来实现。

Answer 4

我个人（2年）在OSGI工作的经验是，技术账单数量级大于功能性收益。

我遇到过的情况是你将不得不创建/编辑25 + POM文件来实现单线模拟！
设计起着重要作用，但我觉得令人不安的是开发人员成为主题（如maven）的专家，这些主题对客户的价值没有影响。
此外，这种方法不能很好地应对敏捷。事实上，这将是一个非常适合... Waterfall
这是所有关于您的主要重点恕我直言。可交付成果与建设模式。

简而言之，OSGI不是邪恶的，但它是不适合小团队和快速上市时间。