是什么使模块/服务/位应用程序功能成为OSGi模块的特别好的候选者？
我对在我的应用程序中使用OSGi感兴趣。我们是一家Java商店，我们广泛使用Spring，所以我倾向于将Spring Dynamic Modules用于OSGi（tm）服务平台。我正在寻找一种将一点点OSGi作为试用版合并到应用程序中的好方法。这里是否有人使用过这种或类似的OSGi技术？有什么陷阱吗？
@Nicolas - 谢谢，我见过那个。这是一个很好的教程，但我正在寻找更多关于如何做我的第一个“真正的”OSGi捆绑包的想法，而不是Hello World的例子。
@david - 感谢您的链接！理想情况下，使用绿地应用程序，我会将整个事情设计为动态的。不过，我现在正在寻找的是将其引入现有应用程序的一小部分中。假设我可以选择应用程序的任何部分，那么需要考虑哪些因素才能使该部分作为OSGi豚鼠变得更好或更糟？
好吧，由于你不能有一个部分OSGi和一个部分非OSGi，你需要让你的整个应用程序OSGi。在最简单的形式中，您可以从整个应用程序中创建一个OSGi捆绑包。显然，这不是一个最佳实践，但是了解在OSGi容器（Equinox，Felix，Knoplerfish等）中部署捆绑包的感觉是很有用的。
若要将其提升到一个新的级别，你将需要开始将应用拆分为组件，组件通常应具有一组职责，这些职责可以通过一组接口和类依赖项与应用程序的其余部分隔离。纯粹手动识别这些内容的范围从设计良好的高度内聚但松散耦合的应用程序的相当简单到您不熟悉的互锁源代码的噩梦。
一些帮助可以来自像JDepend这样的工具，它可以向你展示Java包与系统中其他包/类的耦合。具有低传出耦合的封装应该比具有高传出耦合的封装更容易提取到 OSGi 包中。使用结构 101 等专业工具可以获得更多的架构洞察力。
纯粹在技术层面上，每天使用由160个OSGi捆绑包组成的应用程序并使用Spring DM，我可以确认从“正常”Spring到Spring DM的过渡在很大程度上是无痛的。额外的命名空间以及您可以（并且应该）将特定于OSGi的Spring配置隔离在单独的文件中的事实，使得使用和不使用OSGi部署方案变得更加容易。
OSGi是一个深入而广泛的组件模型，我推荐的文档：
一些链接：
当学习一项新技术时，丰富的工具可以让你毫无头疼地进入事物。此时，ops4j.org 的社区提供了一个名为“PAX”的丰富工具集，其中包括：
然后，OSGi纲要服务有许多实现：
..并且有一个有用的，框架独立的社区，但现在已经是广告了;-）
