是什么让模块/服务/位应用程序功能成为OSGi模块特别好的候选者?
我有兴趣在我的应用程序中使用OSGi.我们是一家Java商店,我们使用Spring非常广泛,所以我倾向于使用Spring Dynamic Modules for 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是一个深度和广泛的组件模型,我建议的文档:
OSGi R4规范:获取Core和Compendium规范的PDF,它们具有规范性,权威性和可读性.在任何时候都有方便的捷径,你会咨询他们.
阅读上的OSGi最佳实践,有一个大的一套东西,你可以做,但一组稍小的事情,你应该做的,也有一些事情你应该永远不会做(DynamicImport:*为例).
一些链接:
OSGi最佳实践和使用Apache Felix
Peter Kriens和BJ Hargrave在一篇关于OSGi最佳实践的Sun演讲中
一个关键的OSGi概念是服务,了解他们为什么以及如何用Whiteboard模式取代Listener 模式
春天DM谷歌集团是在我的经验非常敏感和友好
的春天DM谷歌集团是不再有效,并已移到Eclipse.org作为具有论坛双子座蓝图项目在这里.
学习新技术时,丰富的工具可以帮助您轻松解决问题.此时,ops4j.org上的社区提供了一个名为"PAX"的丰富工具集,其中包括:
Pax Runner:轻松地在Felix,Equinox,Knopflerfish和Concierge之间运行和切换
Pax Construct:使用maven轻松构建,组织和构建OSGi项目
Pax Drone:使用Junit测试您的OSGi包,同时独立于框架(使用PaxRunner)
然后有许多OSGi概要服务的实现:
Pax Logging(日志记录),
Pax Web(http服务),
Pax Web Extender(战争支持),
Pax Coin(配置),
Pax Shell(shell实现,下一个osgi发布的一部分)
以及更多.
..并且有一个有用的,独立于框架的社区, - 但那就是广告;-)
问题提出后,这个答案将近3年,但我发现的链接非常好,特别是对于使用maven的初学者.逐步解释.