入门OSGI的最佳方法是什么？

Question

是什么使应用程序功能的模块/服务/位成为OSGi模块的特别好的候选者？

我对在我的应用程序中使用OSGi感兴趣。我们是一家Java商店，我们广泛使用Spring，因此我倾向于将Spring动态模块用于OSGi（tm）服务平台。我正在寻找一种将OSGi一点点集成到应用程序中作为试用的好方法。这里有人使用过此技术或类似的OSGi技术吗？有陷阱吗？

@Nicolas-谢谢，我已经看过那个了。这是一个很好的教程，但是我正在寻找更多关于如何制作我的第一个“真实” OSGi软件包的想法，而不是HelloWorld示例。

@david-
感谢您的链接！理想情况下，使用未开发的应用程序，我会将整个设计设计为动态的。不过，我现在正在寻找的是将其引入现有应用程序的一小部分。假设我可以选择该应用程序的任何部分，那么有哪些因素需要考虑才能使该部分作为OSGi豚鼠变得更好或更糟？

Answer 1

好吧，由于您不能拥有一份OSGi和一份非OSGi，因此您需要使整个应用程序成为OSGi。以最简单的形式，您可以在整个应用程序中制作一个OSGi捆绑包。显然，这不是最佳实践，但是对于在OSGi容器（Equinox，Felix，Knoplerfish等）中部署捆绑软件很有用。

为了将其提升到一个新的水平，您将需要开始将应用程序拆分为多个组件，这些组件通常应具有一组职责，这些职责可以通过一组接口和类依赖关系与应用程序的其余部分隔离。纯粹是手工识别它们，范围很广，对于设计良好的高内聚性但松散耦合的应用程序来说，很简单，对您不熟悉的互锁源代码的噩梦也是如此。

诸如JDepend之类的工具可以提供一些帮助，该工具可以向您展示Java软件包与系统中其他软件包/类的耦合。具有低传出耦合的包装比具有高传出耦合的包装更容易提取到OSGi捆中。使用诸如Structure
101之
类的专业工具，甚至可以拥有更多的体系结构见解。

纯粹从技术层面上讲，每天使用包含160个OSGi捆绑软件的应用程序并使用Spring DM，我可以确认从“正常” Spring到Spring
DM的过渡基本上没有痛苦。额外的名称空间以及您可以（并且应该）将OSGi特定的Spring配置隔离在单独的文件中的事实，使得无论有没有OSGi部署方案都可以更轻松地拥有。

OSGi是一个广泛的组件模型，我建议您使用以下文档：

• OSGi R4规范：获取Core和Compendium规范的PDF，它们是规范，权威和易于阅读的。随时都有方便的快捷方式，您将向他们咨询。
• 阅读OSGi最佳实践，您 可以 做很多事情，但是 应该 做的事情 要少 一些，有些事情则 永远不要做 （例如，DynamicImport：*）。

一些链接：

• OSGi最佳实践和使用Apache Felix
• Peter Kriens和BJ Hargrave在有关OSGi最佳实践的Sun演示中
• OSGi的一个关键概念是服务，了解为什么以及如何用白板模式取代侦听器模式
• 春天DM谷歌集团 是在我的经验非常敏感和友好
  的春天DM谷歌集团是不再有效，并已移到Eclipse.org作为具有论坛双子座蓝图项目在这里。