虽然目前正值假期,但自从上次的Bundle.update以来还是发生了很多事情。
最重磅的新闻当属Eclipse Virgo项目提案(上周InfoQ对此曾有过深入报道)。目前的dm Server版本是2.0.0,这也就意味着接下来的2.1版将在Eclipse下进行开发和发布。
现有项目与新提案之间的一个显著差别在于协议的不同。这意味着dm Server今后将基于EPL而非现在的GPL,EPL是一个更有利于商业行为的协议。此举的目的在于提升社区的贡献,同时鼓励这种软件开发方式。
目前的企业OSGi和dm Server引起了很多人的兴趣,围绕其的创新也一刻没有停止过。这种兴趣尤其以早期的使用者以及那些需求符合OSGi Service Platform动态模块特性的项目为甚。但对于主流的开发团队来说(只希望尽快构建好企业应用,麻烦越来越少),目前采用企业OSGi的代价可能会超出其短期的收益。在企业OSGi成为主流的企业应用开发方式事实上的标准前需要重点考虑这个问题。
本周出版了一本介绍OSGi和Equinox的新书,这也是Eclipse RunTime系列书籍的第一本。本书介绍了如何通过OSGi构建模块化Java应用,虽然书中的示例基于Equinox,但对于那些想在其他OSGi平台上进行开发的开发者来说该书也是颇具价值的。
该书还从头到尾实现了一个Toast示例项目,目的就在于通过具体的示例代码为该系列的后续图书铺平道路(这样读完此书的开发者就能很快上手其他书了)。本书分为四大部分:首先是OSGi概览、接下来是构建Toast示例指南、第三部分深入探索了OSGi的种种细节、最后是参考书目部分。
近日,Eclipse Communications Framework项目实现了OSGi Remote Services规范,可以通过多种异构协议跨越VM连接OSGi服务,这些协议包括REST、WS-*、JMS、XMPP、Skype及一个ECF Generic实现。
不仅如此,还有多种不同的探测机制,比如ZeroConf、SLP以及静态的、基于文件的探测。
OSGi Remote Services的Apache Felix实现也已经发布(Apache CXF),这也是OSGi的参考实现。但是该实现关注于通过WS-*传输层进行访问,而ECF则独立于传输层。不管哪种实现,最终用户和开发者所使用的API都是一样的。这样用户就可以在运行期对实现进行替换了。
近日,Peter Kriens宣布OSGi Enterprise Expert Group即将完成,同时Enterprise Expert Group draft 4也于前不久发布了,该草案提供了大量的Java EE特性。我们有理由期待最终版将于今年3月发布,这正是OSGi DevCon和EclipseCon举办的时间。
EEG将会提供新的查询机制以通过OSGi实现JNDI风格的查找、使用JMX管理OSGi运行时、通过JTA、JPA以及DataSources进行数据库访问,还会提供对Remote Services和Service Component Architecture的管理。此外,还将发布一种新的部署bundle:WAB,这样Web应用bundle就可以像WAR那样被安装到容器中了。InfoQ会在EEG发布其成果后对其进行深入报道。
IBM WebSphere已经基于OSGi开发一段时间了,近日其发布了Alpha版的OSGi应用。该应用基于Apache Aries,同时包含了OSGi Blueprint容器(这类似于SpringSource提出的Eclipse Gemini)。这些项目都希望解决JNDI和JTA面临的一些问题,这也是Enterprise Expert Group重点要解决的问题。
这些容器都在拓展OSGi运行时的边界以容纳多个应用。未来将可以通过OSGi Nested Frameworks对应用进行切分(类似于Web应用服务器切分WAR的方式)。但与Web应用服务器不同(WAR被完全分离,无法共享代码),WAB可以集成OSGi运行时,那时就可以像使用私有bundle和服务一样来轻松共享代码和服务了。
近日Sonatype发布了Tycho 0.6.0,使用的是新版Maven 3。Tycho是一套Maven构建器,可以根据OSGi Manifest.MF推断出依赖,而不是假想依赖存在于Maven POM中。这样就可以根据POM优先(在Manifest会自动生成的时候)或是Manifest优先的方式创建OSGi bundle了。
虽然使用Maven的大多数OSGi开发者(比如Apache Felix下的开发者)更习惯于POM优先的开发方式,但Manifest优先的开发方式对此是个补充,可以通过Eclipse PDE(Plug-in Development Environment)更加方便地开发OSGi bundle。
在众多的Eclipse项目中,使用Maven而非Ant进行构建的有EGit(http://www.eclipse.org/egit/、http://www.eclipse.org/jgit/)和孵化项目Tigerstripe等。
Maven项目正在朝Maven 3迈进,该版本进行了大量的重构,使用了Google Guice。此外,Maven repository(由Sonatype进行管理)的成功也用事实印证了使用多依赖的Java开发并不难。使用OSGi bundle仓库(比如OBR和SpringSource仓库)的人也越来越多,而且可以跨越不同的提供商进行分发。目前就提供一套统一的OSGi仓库(借助于Nexus,被Tycho所用)这个主题正进行一项探索性研究。试验仓库位于bundles.sonatype.org和osgi.sonatype.org。未来的目标是提供多种格式(OBR、P2等等)的访问,这样OSGi bundle的使用就能像Maven JAR那样简单了。
如果只是获取OSGi bundle的话,那么使用OSGi bundle解析器会是个比较好的选择。近日Paremus发布了Nimble——用于获取并下载OSGi bundle的解析器。
Paremus将POSH(Paremus OSGi Shell)绑定到了Nimble解析器上。这样就可以使用同一套命令初始化并管理一般的OSGi框架了(这么做可以简化Felix、Equinox及Knopflerfish的测试工作),再加上Nimble的帮助就可以很快启动OSGi运行时了,正如Dave Savage所述。通过下面这两行命令可以安装并运行基于Spring的OSGi Web应用:
posh -kc "repos -l springdm;add org.springframework.osgi.samples.simplewebapp@active" open http://localhost:8080/simple-web-app/
感兴趣的读者可以到DZone上了解关于Nimble的更多信息。
OSGi UK User Group正在蓬勃发展,已经有100多名会员了。最近的一次讲座来自于Marcel Offerman(来自Luminis)和Graham Charters(来自IBM)。过几天其站点就会发布讲座的相关视频和材料了。
讲座的第一部分是对孵化项目Apache ACE的介绍,该项目旨在简化OSGi在多种设备上(包括远程)的使用。
在通过可重用组件组装软件的过程中,最难以解决的问题就是如何将软件部署到日益增长的连接设备上去。如果设备上的软件栈是异构的,同时需要不同的组件时情况会变得更糟。该讲座向我们介绍了如何基于Apache ACE(开源、基于OSGi的解决)将软件组件分发到不同类型的设备上去,从移动电话到云中节点都有覆盖。
Apache Ace项目基于Luminis去年初所捐献的软件,该软件已经应用到了不少真实项目中,如On-ship Radar systems、field X-Ray Equipment、CMS的软件更新与协议管理以及机场行李处理系统等。
第二个讲座介绍了OSGi Remote Services(已经包含在了OSGi 4.2中)及其如何与Service Component Architecture(SCA)进行交互,以Apache Tuscany为例进行讲解。
OASIS一直在致力于开发Service Component Architecture(SCA)规范。SCA提供了一种异构的SOA编程模型,该模型跨越了众多的实现技术(EJB、BPEL、C++及COBOL等)、bindings(Web services、JMS、IIOP等)和policy(WS-Policy等)。
该讲座对OSGi Remote Services和Service Component Architecture技术进行了简要的介绍,接下来谈到了如何将这二者整合起来让OSGi应用可以通过Remote Services访问多种SCA实现技术、bindings和policy框架等。
即将到来的OSGi DevCon London和JAX London已经宣布了大会日程安排。优惠到今天截止,但OSGi UK User Group成员可以获得额外的折扣。
很明显,将有越来越多的大型服务器系统采用OSGi,同时OSGi也开始向中小系统进军。随着构建工具的不断发展,开发者可以在多种IDE中开发OSGi bundle了;与此同时,用于共享OSGi bundle的新仓库也在不断涌现,模块化Java应用的开发将变得越来越容易。基于此,Kirk Knoernschild断言:2010将是Java模块化的一年。
查看英文原文:Bundle.update: The Year of Modularity