OSGi 社区大会

  • Alex Blewitt
  • 侯伯薇

2010 年 10 月 23 日

话题:Java语言 & 开发架构

上周OSGi 社区大会在伦敦召开,它是和JAX 伦敦大会一起举办的。 会上演讲的内容涉及到的范围非常广泛,从 Java EE 的迁移和云计算,到嵌入式设备和 Android 都有涉及。

OSGi 上的企业级 Java 应用

最近几年以来,人们越来越多地在服务器上使用 OSGi;OSGi 不仅被用于实现大多数 Java EE 应用程序,并且它还深入到应用程序的模型中,从而可以直接在 OSGi 运行时中运行。 上面的情况来源于企业规范(Enterprise Specification)的发布,它实现了一些通用的 Java EE 服务与 OSGi 服务(JTA、JPA、JNDI 等等)之间的映射。 这在平台提供商之间形成了共通性,有了Apache AriesEclipse Gemini(为Eclipse Virgo所用,也就是之前的 Spring DM Server),我们就可以为那些正在开发中的 Java EE 应用程序提供迁移的方法。 大量教程和演讲的目标都是要把这些内容告诉听众,像 Ian Robinson 的 Apache Aries 以及 Glyn Normington 的 Ecipse Virgo 更新

关于向 OSGi 运行时迁移,有很多真实的故事,它也为想要迁移的人们提供了一些建议。 首先 SAP 的 Katya Todorova 讨论了从 NetWeaver 平台到 OSGi 上的迁移。 最初的方法是试图将所有程序都进行封装,并从高级别上隐藏 OSGi,结果这被证明是无法工作的,很大程度上是因为他们试图把应用程序工作的方式转换为组织 OSGi 的方式。 第二项尝试与上述相比显得更成功一些;它如愿使用了 OSGi,然后提供了 OSGi 服务来与组件交互。 (Peter Kriens 说,他长久持有的信念就是 OSGi 的 μService 是规范中最重要的部分,比大多数人所关注的模块性更加重要。)

Gerd Kachel 讨论了如何将应用程序从 JBoss 迁移到 OSGi 上。 他发现,架构良好的项目(拥有多个组件)通常比“大泥团”式的组件更易于迁移到 OSGi 上,因为对模块进行切分的工作已经完成了。 然而,一旦你迁移到 OSGi,那么这种迁移就会在编译时和运行时都会执行。 在 Gerd 的案例中,他的应用程序已经使用 MBean 服务进行了隔离,这就可以让它本身实现对 OSGi 服务的简单映射,使用特性作为服务属性,使用方法作为服务接口上的方法,并使用依赖关系作为相关联的服务。 Katya 和 Gerd 都对他们迁移到 OSGi 的经验作了总结,如下:

  • 开发者需要一个月左右来熟悉 OSGi。
  • 对于现存的模块,大概需要花费一天来转换成为 OSGi 服务。
  • 如果你与 OSGi 模型对抗,你就会失败。 如果你使用它,你就会成功。
  • 如果你的应用程序架构良好,那么就会比架构很差的应用更易于映射成 bundle。
  • 如果你是用 MBean,那么就会有很简单的策略让你可以把它们映射成为 OSGi 服务。
  • 如果你已经在应用程序中使用了 classloader,那么在向 OSGi 迁移时,处理 classloader 就会有问题。
  • 如果你使用了动态类加载(class.forName),那么通常需要对它们进行修改,但还是可以映射成为 OSGi 服务的。
  • 如果你已经使用了 IOC 模型(Guice,Sprint 等等),那么通常迁移会容易得多。

另一主题

这次大会的另一个主题是关于嵌入式和微型设备的。 好几个演讲都关注于 OSGi 在工业或者嵌入式应用程序中的使用,像 Bernhard Dorminger 的在工业化应用程序中使用 OSGi 的经验、Dimitar Valtchev 的 针对家庭自动化系统的 OSGi,以及 Takefumi Yamazaki 的 基于 OSGi 的 i-House 试验等。 它们都使用了更小的嵌入式系统,像ProSyst's mBS运行时。

在移动领域也有一些讨论,如 Andy Piper 的OSGi 和 Android以及 Andre Bottaro 的OSGi ME。 这些演讲也关注弱电设备,但更多地是关注于移动领域。 Apache Harmony 项目的模块化特性引出了进一步的讨论,其中非正式地建议要拥有大量比 J2SE-1.5 更小型的 profile,其中我们可以用更新的运行时(像java.beans)中的包来装饰更少的 profile(像 Foundation-1.0)。 由于 OSGi 意味着不会从java.*命名空间中引入包,所以使用Import-Package做到这一点并不容易,但是我们可以使用更新的 OSGi 4.3 Require-Capability这个头声明来做到。

基调和更新

Jim Colson 发表了漫长曲折的道路演讲,其中讲述了 OSGi 的发展历史,从 1999 年JSR 8的开始,经过在 Eclipse 3.0 中的采用,直到当前在企业中应用的情况。 同时,在其中还回顾了在早期 Eclipse 和 OSGi 一起发展的事情,它显示出在过去的五年中对 OSGi 的采用有了多大的进展。 现在,每个 Java EE 的厂商都让他们的运行时基于 OSGi(除了 JBoss,他们正在编写自己的 OSGi 运行时)。

Jim 还邀请了Apache Harmony项目中的 Tim Ellison 来说明当前的状态。 现在他们已经完成了 Java 5 API 的 99% 以及 Java 6 API 的 96% 的改造工作,Java 运行时已经能够运行大多数应用程序,包括基于 Eclipse 的 RCP 应用程序和 web 服务器。 更重要的是,和 all-in-one Oracle JDK 不同,Harmony xDK 的类库和 VM 最小可以达到 10Mb。 它们被封装为多个组,名字分别是:Harmony Select、Harmony Core、Harmony More 和 Harmony Out。 只有 Harmony Out 中包含了所有的 UI 代码(既便如此对于 SWT 的使用也是不够的),其中还有不断增长的依赖关系。

James Governor 发表了一场充满激情的演讲,题目是OSGi 的显著之处,(其中的主要内容都在他的博客Java the Unipolar Moment中有反映),同时 Peter Kriens 还发表了关于 OSGi 的将来的演讲,其中涉及到在之前的 bundle.update中所提出的观点。

稍后我们会陆续发布特定演讲更进一步的信息。

查看英文原文:OSGi Community Event

Java语言 & 开发架构