在《OSGI:让共享变得快乐(上)》中我们介绍了共享的好处以及为什么要进行共享。下面我们将介绍OSGi的引入对于模块化有什么作用。 在1998年,考虑到了这种合作模式,我们开始开发OSGi。我们需要一个模型,不同厂商的组件可以组合成一个点对点的方式,这些组件事先都不了解。
在一个受限的环境中,但是组件可以彼此找到并一起工作,而不用受限。为了实现这个目标,我们知道,我们必须解决共享问题,在这13年中,我们在模块化中学到了什么? 实施 没有实施的模块化不是模块化。你违反模块的边界,除非你受到惩罚,否则你就不能模块化工作。迁移到OSGi最另人失望的是:找出与架构不一样的模块化代码,和依赖关……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
在《OSGI:让共享变得快乐(上)》中我们介绍了共享的好处以及为什么要进行共享。下面我们将介绍OSGi的引入对于模块化有什么作用。
在1998年,考虑到了这种合作模式,我们开始开发OSGi。我们需要一个模型,不同厂商的组件可以组合成一个点对点的方式,这些组件事先都不了解。在一个受限的环境中,但是组件可以彼此找到并一起工作,而不用受限。为了实现这个目标,我们知道,我们必须解决共享问题,在这13年中,我们在模块化中学到了什么?
实施
没有实施的模块化不是模块化。你违反模块的边界,除非你受到惩罚,否则你就不能模块化工作。迁移到OSGi最另人失望的是:找出与架构不一样的模块化代码,和依赖关系图,使人们相信。不幸地是,人们往往会生气、并指责使者。
隐藏
迄今为止,共享问题最好的解决方案是不共享。任何共享都会在组件生命周期的后期阶段有一个隐性的开销。随着时间的推移,任何共享方面的内容都必须谨慎地修改版本,在他的演化过程中是有限制的。共享非常昂贵!出于这个原因,OSGi在bundle里为你提供了一个私有的Java命名空间,尽可能多地隐藏命名空间外的代码。无论你做什么,都不要影响bundle外的人。不同的bundle实际上可以包含相同的类,而不会引起命名问题。共享很好、隐藏更好、一开始就没有事情最好。
依赖的花销
每一个依赖都是有代价的,但是你会感到惊讶,到底有多少人不知道他们的依赖关系是来自哪里呢。一旦我发现超过30M的依赖,就会把他们放到一个单线程中,参照apache公共资源集合。很多WAR和Maven项目都有很多模糊的依赖链,因为很难估计出在现今的Java中实际有多少依赖。
包共享
我们发现,对于JAVA,包是共享的正确粒度。类对于共享来说粒度过细。在同一个包中,它们过多地链接到与其相邻的类中。输出类在Java包中也重叠了。JAR对于共享来说,太难处理,因为是一个在代码中共享的包聚合。这种聚合在版本控制和依赖管理上有让人不爽的副作用。
基于API编程的意外结果
基于API编程,指的是,一个API可以通过不同的实体实现,要求每一个再访问版本为我们所知道。在Unix包管理系统中,它是软件依赖管理模型的鼻祖,版本控制基于请求提供者的消费者。在Java中倾向于盲目追随这些模型,但是模型是错误的。对于白费力气重复工作而言是个很好的战略,但是使用基于API编程模型,我们实际上得到了一个第三方:API/接口/契约。结果是这个三元组对于兼容性规则具有重大意义,这就是依赖模型。
版本控制
为了让组件可以是当地连接,需要独立于其他组件的功能分解其需求。在这样一个线路模型中,包的正确描述是最重要的。OSGi中,一个输出可以声明版本,输入可以根据兼容性声明一个版本范围。OSGi规范指出了语义版本的规则,模型是版本的一部分,意味着有一个良好顶合一的兼容性。很多其他的模式只是执行反向兼容性,没有认识到消费者/接口/提供者这个三元组。OSGi版本模式通过自动化工具很好地实现了这个。OSGi中,你可以清晰无疑地声明,你不会和优先版本和谐相处。能表达你不支持旧版本的反向兼容性是组件系统中必不可少的内容。
多版本依赖
依赖于同一包的多版本不是每个人都渴求的,但是当应用使用了足够的外部依赖,就称为不可避免的了。在JAVA社区中,有一种倾向于忽略这种麻烦多版本的趋势,就好象他们没有这个问题。例如,Maven中第一个版本在依赖中还在使用,尽管随后的依赖有了更高的版本。在大型类路径上发现相同库的多版本很正常,之所以奇怪是因为我们希望花更多的时间在语言的类型安全上,但由于忽略版本,远离了运行时的诸多好处。OSGi中,依赖需要小心管理,它是一项精密科学,没有模糊性和启发性。OSGi框架通过链接bundle到期正确的版本解决了域问题,但是之允许没有冲突的bundle之间的协作。在DLL例子中,OSGi可以轻松处理App和COMM以及App和WIDGET之间的协作,而不用交换LOG对象。实际上,OSGi支持协作和共享,但是当需求的关键原因之一是应用服务器厂商过多地使用OSGi,它也是孤立的。
总结
OSGi核心规范的大部分是在模块层,这一层中我们定义了共享规则。这些规则通常是复杂的,难以理解,而且需要很多关于命名域、类型系统以及Java内部的知识。然而,这些规则只需要少量OSGi框架开发者理解。作为回馈,OSGi为模型开发者提供了稳固的共享模型,这个模型强大,而且具有惊人的易用性。
看到了Unix系统(如Debian)如何指导Jigsaw的设计,是一种悲哀,这里没有使用OSGi。然而,这些系统包强大之处是,他们解决的问题,表面上仅仅是类似于一个Java模块。就Jigsaw而言,Java社区面临一个漫长而又曲折的道路。看完这篇文章之后,可以清晰的知道,OSGi会让这条路变得通畅,它只是一个信使,告诉你必须运行无模块化的代码。
相关推荐
-
Java模块化项目Jigsaw能否重回正轨?
模块化的粉丝们会很高兴的听到这一消息,Jigsaw项目已经重新提上日程,至少也是部分回到了正轨。
-
OSGi中该使用Blueprint还是声明式服务?
在OSGi中,服务是实现bundle间交互和应用灵活性的基石。借助于服务,我们能够降低bundle之间的耦合,更加有利于软件的重用。
-
OSGi中的服务模型与扩展者模型
在OSGi中,实现bundle间交互和扩展性有两种常见的方式,也就是服务模型(service model)和扩展者模型(extender model)。
-
企业编程需从开源架构中汲取教训
在这个秘密地、利益至上的所有制软件开发世界中,开源社区因其标新立异而一直走在前端位置。