Ross Mason在Mulesoft最近的博客中说"OSGi - no thanks"。Ross是个聪明的人,他通常会说一些有趣的事情。在这个方面,我认为Ross已经提出了许多好的意见:

  • Ross是对的---对中间件厂商而言,OSGi是一个很好的技术。
  • Ross是对的---开发人员不应被迫并乱用OSGi。
  • Ross是对的---你可以将这两方面结合在一起。

在WSO2,我们经历了同样的问题,只是我们得到了一个不同的结论 - 我们可以在不给客户制造麻烦情况下提供OSGi的优势(OSGi的模块化设 计,可插拔性,动态加载等)。在我们的WSO2 Carbon项目中,客户能像采用OSGi之前 一样的方式那样部署他们的系统。

我们为什么选择OSGi?我们其实也尝试过构建自己的动态加载方案。事实上从第一天开始,我们已经具备在自己平台上动态加载的能力。我们使用OSGi的原因是:

  • 结构化和版本化动态类装载方法

  • 一个行业标准化的方法 - 从而能使我们更好地理解该方法,具备更好的技术和更好的资源

  • 它不仅仅解决动态加载,它同时提供了适当的模块化设计 - 这意味着尽可能尝试隐藏类或者暴露类。

  • 它提供了(通过Equinox P2 )适当的供给模型(Provision Model)。

这并不是一项容易的工作。开始采用OSGi时我们经过了痛苦的探索,但最终我们得到了比我们原来动态加载方法更好的解决方案。而且我们做了一些很大的改善。我们新的Carbon Studio 工具给出了一个生成完整的端到端应用程序,并对最终用户完全隐藏 OSGi的简单模型。Web 管理员控制和部署模型使得应用的部署对OSGi完全透明。加入一个 JAR包, 我们的工具会处理接下来OSGi Bundle化的所有事情。

结果 - 两全其美 - 易于使用的开发者和伟大的中间件。


译自Paul Fremantle的博客


罗俊杰 2013-08-07 18:20

回复J Liu: What a pity~~

顶(0) 踩(0) 回复

J Liu 2013-08-06 12:14

Because of no OSGi support Mulesoft lost a big, no, a huge customer.

顶(0) 踩(0) 回复

最受欢迎的文章

最新评论