OSGi社区大会

作者 Alex Blewitt 译者 侯伯薇 发布于 2010年10月23日

领域

企业架构,

架构 & 设计,

语言 & 开发

主题

Java SE ,

Java ME ,

Java EE ,

Java ,

语言 ,

编程 ,

模块化 ,

Apache Harmony

分享到

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

OSGi上的企业级Java应用

最近几年以来，人们越来越多地在服务器上使用OSGi；OSGi不仅被用于实现大多数Java EE应用程序，并且它还深入到应用程序的模型中，从而可以直接在OSGi运行时中运行。 上面的情况来源于企业规范（Enterprise Specification）的发布，它实现了一些通用的Java EE服务与OSGi服务（JTA、JPA、JNDI等等）之间的映射。 这在平台提供商之间形成了共通性，有了Apache Aries和Eclipse 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

译者 侯伯薇 是InfoQ中文站架构社区编辑，有多年对日和国内项目开发经验，目前关注企业中技术与实际业务之间的融合和协作。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！