BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

OSGi纲要规范添加了子系统、Repository等内容

| 作者 Alex Blewitt 关注 4 他的粉丝 ,译者 张卫滨 关注 13 他的粉丝 发布于 2013年9月24日. 估计阅读时间: 9 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

OSGi联盟最新发布了第五版的OSGi纲要规范(Compendium)。第五版的OSGi核心规范(Core)已经于2012年6月份发布,企业级规范(Enterprise)发布于今年的早些时候。

纲要是一组服务的集合,除此之外还有版本信息以及API定义,它们不是OSGi核心释放规范的一部分,但是可能会用于模块化风格的应用之中。Equniox、Felix以及其他的OSGi项目已经实现了一些(不一定是全部)OSGi纲要规范。

读者可能会意外地发现在纲要规范中已经没有Service Tracker API以及SCA Configuration API了;但是,它们分别被转移到了核心和企业级规范之中了。对应编号的RFC创建了其API(Tracker的编号是701,SCA Configuration的编号是129);最近,OSGi联盟开放了审阅过程,所以一些规范可以在GitHub上找到

那么,纲要规范的第五版究竟有什么新内容呢?配置管理(ConfigAdmin)——用于将配置信息传递给bundle——版本号从1.4升级到了1.5;还有一些新的API包括Repository服务、Service Loader Mediator、子系统(Subsystem)、通用的命名空间(Common Namespaces)以及Resolver服务。

配置管理(Config Admin)

配置管理1.5针对目标PID(targeted PID)提供了新的规范。它会使用特定的格式化PID(持久化标示,Persistent IDentity)以及竖线来指向bundle的不同版本。如:

  • com.example.config|com.example.bundle|1.2.3|http://example.com/config.jar
  • com.example.config|com.example.bundle|1.2.3
  • com.example.config|com.example.bundle

持久化标示符可以包含特定bundle的信息,会使用它的Bundle-SymbolicName和Bundle-Version(甚至它的安装位置)来进一步精确特定可选项的配置。在运行时,会使用最为具体化的配置,这很类似于Java中资源bundle的国际化路由选择策略,如果能够找到的话,它会为特定的语言使用一个目标值。托管服务工厂(managed service factory)也有所变化,它会使用这种新的查找目标逻辑。

Repository与Resolver服务

Repository服务以及Resolver服务在特定的仓库类型(如Maven、P2、OBR以及NuGet等)之上抽象出了存储与网络协议,并且提供了一种基于一个或更多这种仓库解析限制的方式。这种限制使用了通用的OSGi需求功能(OSGi Requirement Capability),它表示特定OSGi模块所需要的内容(如包导入、最小的运行时环境以及针对平台和处理器的过滤条件)。

与Maven中心库(Maven Central)这种仓库不同,OSGi仓库需要详细了解它所包含的组件,并且要能够返回一个综合的XML文件,这个文件描述了仓库的完整内容。对于基于本地文件的仓库,它可能运行得很好(能够以完全遍历的方式生成完整的元数据),但并不能扩展到更大型的仓库。在此之前,曾经制定过仓库规范,是形式是obr;与这个规范的不同之处在于,它能够包含其他潜在的仓库类型,如P2。

为了保证依赖能够解析,resolver服务能够了解一组通用的需求和资产,确定那些资产能够满足需求的规划。在Maven中,这类似于Aether的解析功能;对于OSGi来说,这会通过像Equinox和Felix这样的运行时引擎来进行提供,这些引擎会基于本地的JAR解析bundle。resolver服务会以外部服务的形式提供这种机制,这样就能够允许工具或程序使用这些之前提到的内部API,同时也能提升出现错误时的一致性。

Service Loader Mediator

Java的Service Loader是一种有缺陷的通用服务加载机制;在设计之时,它就只能基于一个ClassLoader操作并为所返回的对象提供了静态绑定。因为OSGi会使用多个ClassLoader并且会处理动态的解决方案,因此Service Loader必须要进行修正。

Service Loader Mediator提供了一种修正方式,通过启用像字节码织入这样的方案来替代对Java Service Loader的调用,会有一个合适的包装器以理解多个类加载器。通过探查需要启用Service Loader的bundle,代码能够减少预先要处理的工作,同时允许已有的JAR使用Java包。通过往manifest中添加OSGi属性并选择Service Loader Mediator处理,bundle能够马上进行升级,而不需要明显的重构。

Mediator还能够用于将服务发布为OSGi服务,这样它就能够被运行时中的任意客户端所使用。

子系统(Subsystem)服务

OSGi子系统允许在单个OSGi环境中托管多个部分所组成的应用程序。这样能够允许应用程序声明精确的bundle依赖(如log4j 1.2.14),而同一个OSGi框架中的其他应用(不同子系统)可能所绑定的是不同的版本(如log4j 1.2.16)。

子系统是OSGi中一个长期研究的结果,其目的在于按照各部分组成的方式运行多个应用程序。之前为大家所熟知的是复合bundle(Composite Bundle)或嵌套框架(Nested Framework),子系统的目标在于概括在同一个地方运行多个bundle的需求。OSGi第五版的释放第一次将其规范化;其他所有的迭代已经处于RFC级别。

Eclipse Equinox曾经实现过以前版本的嵌套框架;它们在Luna版本中会将其移除,因为这个规范只是一个过程性的成果。另一方面,对于这种组合系统来讲,Eclipse Virgo成为了重要的参与者,它提供了“用户区(user region)”以及“核心区”(借助Spring框架,在很大程度上分离出了潜在的依赖冲突问题,这是Virgo设计中重要的特点)。

通用命名空间(Common Namespace)

OSGi 5的需求功能模型(requirement-capability model )基于一组命名空间化的需求。这包括字符串形式的bundle-versionbundle-symbolic-name可以用来提供额外的限制。对于大多数的用户可能并不需要了解它,因为它实际上是一个粘合规范,会被repository和resolver服务所使用。

结论

OSGi纲要涵盖了所有不适合放在核心规范或其他垂直规范(如企业级或Residential规范)中的内容。它们每隔一年或两年以一组服务的形式发布,以前的发布形式就是一些最终的规范。随着审阅过程的开放,可能这些规范将来会以更加迭代化的形式交付。具有讽刺意味的是,对于一个关注模块化的组织,它们的很多规范文档都是大量的各种API组合而成,这些API的进化速度各不相同;有很多(如HttpService)在过去的多个释放版本中毫无变化,但在每年的纲要文档中都重复相同的文本。

云提供商——尤其是那些参与到Eclipse Virgo或其他高度模块化环境的——将会被子系统规范所吸引,它是这个释放版本的新内容。Repository规范对那些目前使用OBR的人可能会感兴趣,但是在未来的几个释放版本期间,P2可能不会转移到新的通用Repository服务。对所有人都会带来好处的是Service Loader Mediator,它尝试解决了Java的Service Loader API缺乏类加载器支持的问题。

原文链接:OSGi Compendium 5 Adds Subsystems, Repositories and More

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT