osgi已经被淘汰了吗,os正式发布_1

  osgi已经被淘汰了吗,os正式发布

  OSGi联盟最近

  技术总监Peter Krien

  在英国OSGi用户组

  (作者帕雷默斯

  当然,伦敦的技能很重要

  Held)就即将到来的OSGi 4.2发表了主题演讲。整个事件都被录了下来,还有演讲的视频。

  将于今年8月底发布的OSGi 4.2有许多新功能,其中一些已被Equinox采用。

  (Eclipse后面的OSGi引擎)被实现。

  OSGi核心的新功能包括:

  的标准启动框架

  这将简化OSGi系统的启动过程,而不管底层实现如何(例如,可以通过更改类路径来使用Felix

  替换Equinox

  服务挂钩

  有了它,OSGi捆绑包可以拦截和过滤去往其他捆绑包的服务(这样做可以执行安全检查,等等)。

  捆绑跟踪器

  ,它可以监视包的启动和停止。

  增强的安全机制

  这样,正反许可证都可以自定义授权机制。

  标准捆绑包-许可证标题

  以便该包可以出于管理目的定义其协议要求。

  OSGi大纲涵盖了可能出现的其他服务。它规定下一个版本应该遵循核心,但也将包括:

  信息初始化

  初始化信息可以存储在包的清单中。

  声明服务

  现在BND已经支持声明式服务,同时消除了一些限制。

  先前发布的OSGi(即RFC

  19)通过远程技术连接不同虚拟机之间的OSGi服务。捆绑包的外部配置可以定义服务的连接方式。与RMI不同,这些服务不需要

  Checked exception(显然,如果出现通信错误,将会抛出RuntimeException)。这已经被日蚀的ECF用过了

  还有菲利克斯CXF

  蓝图扩展器

  提供配置驱动的服务模型(类似于声明式服务),但基于Spring模式。将来,服务可以在启动时被实例化并绑定到代理,并且可以在以后更改。

  企业OSGi服务并不孤单,它将包含一个基于OSGi的事务。

  API(基于JTA)通过OSGi服务提供JDBC和JNDI,并与JMX一起管理OSGi系统。企业

  OSGi的难点之一是Web容器,它应该能够将WAR安装到正在运行的OSGi系统中,就像Spring DM Server一样。

  那条路。

  还有几个实验性的服务(规范中没有定义),比如创建嵌套框架的能力(OSGi引擎可以在上面实例化另一个OSGi引擎来运行应用)和TSL。

  3354基于外壳的脚本语言外壳,用于与OSGi服务交互并支持运行时命令。后者的目标是实现一个标准的shell来控制任何OSGi引擎,而不是

  特定系统的特定外壳。像POSH和Pax-Shell这样的系统已经开始使用TSL。

  OSGi的那些实验服务的实验手段与JCP定义的那些实验系统有很大的不同,相比之下要花很长的时间来定义规范,然后获得其工作模式的反馈信。

  RFC采用不同的策略:首先提供临时细节,然后采用几种实现(Felix、Knopflerfish、Equinox等。)获取其反馈信。

  接下来,根据反馈,细化规范,直到规范稳定,而不是发布一些不确定的东西(与Java的发布形成鲜明对比)。在发布最终规范之前,有机会测试并获得相反的结果。

  信息反馈意味着未来的变化不太可能对最终规范产生严重影响。

  这个讲座的一些结论与JSR 294的结果相吻合。目前很多需求和实现已经合并。由于JavaC处理元模块系统的方式,有人提出改变Java中可见性的工作模式(包括新引入的module关键字)。关于每个人元模块的含义,有一场关于keyword的热烈讨论。Sun的工程师和Felix的提交者Richard Hall说:

  就我而言,我理解Peter的担心:我们定义的东西的含义太不清晰,最终会毁了Java的愿景:“写一次,到处跑”。我希望在定义事物时能更具体一些。

  好在JSR 294还有时间改进;最近对JSR 294的许多评论表明,每个人都希望对这些问题有一个合理的解决方案。

  查看英文原文:

  OSGi:下一个版本

  转自:http://www。infoq。OSGi-下一次发布

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: