•  

您现在的位置:主页 > 彩83 >

OSGi 适合作为 Java 中间件的基础么?

发布时间:2019-05-19 19:06 作者:彩83

  OSGi(JSR 8)工作组成立于 1997 年,主要关注嵌入式 Java,以支持嵌入式软件的模块化升级。在成功解决了Eclipse 插件不可避免的依赖关系之后,OSGi 成为主流。大概在 2005 年,好几种方法都开始利用装配机制和定义良好的依赖关系在企业 Java 中引入更进一步的模块化,其中包括Spring服务组件体系架构,而 EJB 却慢慢消失了。现在,大多数企业 Java 厂商都在 OSGi 的基础上重写了他们的中间件。

  但 OSGi 技术也让很多人觉得懊恼,MuleSource 的创始人 Ross Mason 前几天就在他的博客上毫不掩饰地对此发表了议论。

  OSGi 想要改变一切,依赖关系会完全隔离(不再受制于冲突的依赖关系版本),而且会严格要求 Bundle 彼此可见。和很多人一样,我就这样买了 OSGi 的账,让我们的工程人员改造 Mule、让它支持 OSGi。

  我们的团队有好几个月都在 Manifest 上扯皮、打包自己的 Bundle、无休止地摆弄构建,OSGi 的优势在这之后变得越来越弱。我们认同“不劳无获”,但后来这却成了作茧自缚。

  Ross 的工程团队不知道如何向中间件开发人员隐藏 OSGi 的复杂性。他认为这个问题是由 OSGi 的起源——嵌入式——造成的。

  模块化和版本化是中间件项目的两个核心问题。服务实现经常会发生变化(有时每个季度就会改变一次),而大型组织过去也常把所有的服务部署在一个 ear 文件中,每过三个月,就算 ear 中的很多内容从未发生变化、也不依赖于新的或更新过的服务,消费者和服务提供者还是要进行一次大规模的同步,更别说还要一直测试所有的服务了。有人可能会说, 缺少模块化和版本化正是 SOA 失败的原因所在。Ross 补充说:

  bnd 之类的工具已经对开发人员隐藏了 OSGi 的细节。我认为现在的问题是,基于 OSGi 进行开发的替代方法和工具过于泛滥。我仍然相信,不用 OSGi 进行日常 JVM 开发会比任何短期利益都要痛苦……你上次手工编写.class 文件是什么时候呢?也许你永远没手工写过,只是编译 Java 源文件来生成。OSGi 的 MANIFEST 也是类似的内容,它应该是类编译器工具的输出。

  Joe Sampson 从测试和构建的角度分享了他使用 OSGi 的经验,这些经验都是他发现不太容易使用的部分。Hani Suleiman 指出:

  WSO2 的 CTO Paul Fremantle 在给 Ross 的回应中解释到,WSO2 Carbon 不仅是基于 OSGi 构建的,还完全向开发人员隐藏了 OSGi 的细节。Paul 承认这并不容易,但用自己的构建方式实现模块化、版本化和配置却要更难一些。

  你对 OSGi 持什么看法?你有没有遇到什么困难?OSGi 对你来说是透明的么?你的中间件是否充分模块化,且支持一流的版本控制策略?就像 Hani 所指出的,现代架构的核心问题往往是缺少语义、架构的语义与底层编程语言的语义不匹配,难道我们就要因此将这个架构打入地狱么?

      彩83,彩83投注,彩83首页

所属类别: 公司新闻

该资讯的关键词为:



        版权所有:中国彩83电子系统有限公司 | 京ICP备05021924号网站地图 | 京公网安备11010622004691号 中企动力提供技术支持