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-下一次发布