是什么让模块/服务/位应用程序功能成为OSGi模块特别好的候选者?
我有兴趣在我的应用程序中使用OSGi.我们是一家Java商店,我们使用Spring非常广泛,所以我倾向于使用Spring Dynamic Modules for OSGi(tm)服务平台.我正在寻找一种将OSGi作为试用版纳入应用程序的好方法.有没有人在这里使用过这种或类似的OSGi技术?有任何陷阱吗?
@Nicolas - 谢谢,我见过那个.这是一个很好的教程,但我正在寻找更多关于如何做我的第一个"真正的"OSGi包的想法,而不是Hello World示例.
@david - 感谢您的链接!理想情况下,使用绿地应用程序,我会将整个事物设计为动态的.不过,我现在正在寻找的是将其引入现有应用程序的一小部分.假设我可以选择应用程序的任何一部分,有哪些因素可以使这件作为OSGi豚鼠变得更好或更差?
Bor*_*zic 39
好吧,既然你不能拥有一部分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概要服务的实现:
..并且有一个有用的,独立于框架的社区, - 但那就是广告;-)
| 归档时间: |
|
| 查看次数: |
11542 次 |
| 最近记录: |