写点什么

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

  • 2010-11-29
  • 本文字数:1694 字

    阅读完需:约 6 分钟

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 的起源——嵌入式——造成的。

OSGi 对中间件厂商来说是个很棒的规范,……但 OSGi 绝不是为了应用开发人员的需求才创建的。它的起因是,在用户不干预的情况下远程更新部署在机顶盒里的软件。OSGi 对这类软件的部署来说是个很好的规范,因为只有中间件厂商才需要处理 Bundle 的部署。

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

OSGi 承诺会对软件堆栈进行模块化,并让中间件基础设施即插即用。遗憾的是,有些 Bundle 就没有兑现这样的承诺,这些 Bundle 跨容器之后就不能以相同的方式正常运行了。

Ross 认为 OSGi 背后的原则正好适用于永久异构的堆栈。但他说:

既然 OSGi 现在主要针对普通的应用开发,那就要重新思考一下它的用户交互部分。从实际情况来说,不用 OSGi 也可能在 JVM 上做到模块化和热部署,但 OSGi 日常开发的痛苦却比它具备的优势多多了。

Neil Bartlett 对 Ross 作出了如下的回应:

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

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

OSGi 在概念层次上是个很好的模型,只是被那些本身不支持它的语言给拖累了。大家不愿意使用不支持 OSGi 的语言,这就意味着 OSGi 永远都是个令人讨厌的笨拙的框架,没有人会真正喜欢用它(据我所知,如果你经常使用 OSGi,那你的体验显然会不一样)。

Richard S. Hall 也提出了一点儿忠告:

如果你开始使用 OSGi,期望所有遗留的 JAR 包都能正常工作,还想尝到模块化的甜头,那你还不如不尝试。这跟二十世纪八十年从 C 切换到 C++ 有几分相像,那时人们希望所有内容都能自动变成面向对象的。

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

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

查看英文原文: Is OSGi the Right Foundation for Java Middleware?

2010-11-29 04:544049
用户头像

发布了 151 篇内容, 共 61.8 次阅读, 收获喜欢 18 次。

关注

评论

发布
暂无评论
发现更多内容

5000字解读《低代码发展白皮书(2022年)》

信通院IOMM数字化转型团队

低代码 无代码 低代码报告 IOMM

牛掰!阿里十年架构师总结的分布式原理、设计与实战笔记

小小怪下士

Java 程序员 面试 分布式

软件测试面试真题 | 请介绍一下Python中的深拷贝和浅拷贝

测试人

Python 软件测试 面试题 测试开发

NFT质押挖矿分红dapp系统开发功能介绍

开发微hkkf5566

颠覆性突破重构企业价值

通明湖

负载均衡 云原生

【web 开发基础】PHP 中的特殊流程控制(continue) -PHP 快速入门 (21)

迷彩

continue 10月月更 循环控制 PHP基础

“程”风破浪的开发者|架构师的思维转变

CTO技术共享

学习方法 架构师 “程”风破浪的开发者

去摩尔纹不用再凹姿势拍照了!合合信息智能文字识别“黑科技”上线扫描全能王

合合技术团队

人工智能 摩尔纹

API 动态更新 Upstream

通明湖

API upstream 动态更新

云科通明湖:金融业务可持续性能力建设,少不了这块“拼图”!

通明湖

负载均衡

千企千面,WorkPlus面向政企提供个性化的数智办公平台解决方案

WorkPlus

数字政府行业趋势洞察报告(2022年)解读

信通院IOMM数字化转型团队

数字政府 IOMM 政府数字化转型

低代码又又又“出圈”了

优秀

低代码

云原生颠覆实践,可持续性应用创新引擎

通明湖

负载均衡 云原生

沉浸其境,共赴云栖数智硬核美学

阿里云视频云

VR/AR 云栖大会 数智融合 超高清视频 云游戏

MySql浅析

Andy

“程”风破浪的开发者|Web 3.0 是泡沫还是金矿?

架构精进之路

1024 Web3.0 “程”风破浪的开发者

消失与存续——应用交付行业的跌宕演进

通明湖

负载均衡 高可用 云原生 信创

SAP | 如何全局处理消息文本

暮春零贰

SAP 10月月更 动态消息

数据可视化大屏酷炫秘籍之前端开发者自己动手

葡萄城技术团队

前端 BI 可视化数据

即时通讯IM WorkPlus支持国产化信创环境

WorkPlus

【网易云信】Sanitizers 系列之 address sanitizer 用法篇

网易智企

算法 开发语言

如何引发一场信创负载均衡领域的大变革?

通明湖

负载均衡 信创

数据库浅析

Andy

中台“不火”了,企业“底座”却火了

WorkPlus

“程”风破浪的开发者|CTO浅谈数字化转型

CTO技术共享

学习方法 CTO 数字化转型 “程”风破浪的开发者

“程”风破浪的开发者|CTO浅谈数字化转型失败原因

CTO技术共享

学习方法 数字化转型 “程”风破浪的开发者

Sanitizers 系列之 address sanitizer 用法篇

网易云信

算法 语言 & 开发

信息技术国产化浪潮中,云科通明湖如何助力企业转型蝶变?

通明湖

双活 高可用架构 自主可控

Flink 读写多套 Kerberos 认证的 Kafka 方案

移动云大数据

【10.21-10.28】写作社区优质技术博文回顾

InfoQ写作社区官方

优质创作周报

OSGi适合作为Java中间件的基础么?_Java_Jean-Jacques Dubray_InfoQ精选文章