BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

SpringSource新应用服务器发布 摒弃Java EE

| 作者 Scott Delap 关注 0 他的粉丝 , Floyd Marinescu 关注 38 他的粉丝 ,译者 Jason Lai(赖翥翔)& 郭晓刚 关注 0 他的粉丝 发布于 2008年5月1日. 估计阅读时间: 13 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

获得一千万美元风投开始算起刚满一年,如今SpringSource(Spring框架背后的公司)摇身一变,成为应用服务器提供商,并且举着SpringSource应用平台(SpringSource Application Platform)的黄钺白旄对现有的Java EE服务器阵营发起挑战。SpringSource应用平台是构建在Spring、OSGi和Apache Tomcat之上的应用服务器,这个新的应用服务器摒弃了原有的Java EE服务器标准,自然而然地将Spring编程模型展现其中,随之而来的还有一套基于OSGi内核构建的全新部署和打包系统。今天是该项目在SpringSource评估许可下Beta发布版发布的重要里程碑。在随后一个月内会有基于开源许可(GPLv3)版本和订阅版本的通用发布版(General Availability,GA)放出。

SpringSource应用平台不是Java EE应用服务器。尽管对于WAR部署它提供了支持,但EAR部署和其它EE的规范,如EJB等,都不在支持范围之列。SpringSource应用平台被重新设计,并把关注点直接放在对被开源项目所广泛使用的Spring组合的支持上。特别地,这个应用服务器是基于Spring组合编程模型构建的,利用Spring Dynamic Module实现基于OSGi的部署。SpringSource在Eclipse基金会的Equinox OSGi运行时环境的基础上创建了一个具备日志、跟踪、启动、类加载、管理和其它特性的“内核”,Tomcat被作为一个包(bundle)纳入到平台当中,从而实现对Web功能的支持。

InfoQ借此机会对Spring框架的共同创始人兼SpringSource的CEO Rod Johnson进行一次采访,对这个新的应用服务器展开探讨。在阐释这个新平台的必要性时,Rod一针见血地指向目前开发和生产环境的许多痛处,比如跨配置文件出现的元数据重复现象,还有本质上在项目中常常在服务器上再部署服务器(即在部署应用时,在同一个部署单元附带部署许多工具和框架),而与此同时这些部件却主要只使用它们应用服务器中的Web容器部分的事实。因此,SpringSource希望在当今的开发需要的基础上提供一个更为简单的平台。

在谈到这个新应用服务器的优点时,Johnson强调了模块化:对于服务器本身以及提供给开发人员的打包和部署模式来说,这是个两全之策。通过利用OSGi,以及OSGi包之间依赖关系相互作用的性质,运行的应用服务器只会激活在它上面运行的应用所需要的特性,从而削减服务器的内存占用和启动时间。这个依赖关系支持的功能还允许依赖类库的多个版本共存,以支持不同应用;因而应用服务器的某些部分就可以很容易地更新和重启,而无需重启整个服务器。从开发的角度看,服务器的模块化也使得在代码变化时,可以很快地进行极其细粒度的重部署。

Johnson在言及OSGi和SpringSource对Eclipse Equinox OSGi的使用时,高度评价了OSGi规范的运行时实现所带来的基础平台,但也表示OSGi在日常的应用开发上属于比较底层的地位。Johnson阐述到,SpringSource希望帮助开发人员在企业环境中轻松获得价值。在新的编程模式的构造背后,这个新的应用服务器将OSGi的许多复杂性抽象了出来。Johnson接着说,应用服务器将会支持PAR,一套新的可部署单元,简化企业应用在使用OSGi上的复杂性(下文会详细说明)。

当被问到对于没有对OSGi提供原生支持的遗留类库的支持时,Johnson回应到,他们已经在上面花费了很大心血,使得应用服务器环境和类加载功能能够以兼容的方式和遗留类库协作。

当被问到对不提供OSGi原生支持的类库的遗留支持时,Johnson回答说他们已经在这方面投入了大量精力,保证应用服务器环境和类加载功能可以和遗留类库兼容工作。SpringSource还会为他们在如Tomcat之类的项目上所做的任何变更给这些项目提交补丁,使这些类库可以和OSGi包兼容。

Johnson解释到,应用服务器的主题代码将在GPL v3的许可证下发布。开发人员在服务器、编程模式和部署单元上要接触到的所有部分都会以开源的形式提供。SpringSource还将提供应用服务器的商业版本,包括支持、保障、管理和监控的功能。


谈到Spring应用平台发布之后对Spring组合继续支持JavaEE有什么影响,Johnson回答说:

……我们从根本上说并不打算把Spring用户社区驱赶到任何方向。我们仅仅是给用户另一种选择。Spring的哲学是用户总是正确的。用户是聪明的,他们完全明白自己的需要。不管用户是否选择SpringSource应用平台,我们觉得用户总会欢迎多一点选择的……

Johnson保证SpringSource一定会继续确保Spring组合以及其他SpringSource产品兼容于其它应用平台。接着Johnson还评论了即将到来的Java EE 6规范:

Java EE 6重点在模块性,这个方向是正确的。很可能SpringSource应用服务器会在一定程度上符合Java EE 6。Java EE 6分成A、B、C三种规格(profile)。我们几乎肯定会实现A和B规格,C规格里面我非常确定将实现Entity Beans 1.1模型以及一些遗留技术。我还不能说是100%确定,因为Java EE 6规范还没有定案。

最后,InfoQ和Johnson讨论到了SpringSource应用平台的大局方面。对于转换到OSGi,他的回答是:

传统的应用服务器模型正逐渐过时。BEA和IBM正在用OSGi逐步重新实现他们的应用服务器。 SpringSource现在就提供OSGi支持。从统计数字上看,大多数人都不会部署到完整的平台上,他们部署到Tomcat。他们选择了Spring 编程模型而非Java EE。市场已经作出了选择,问题只是开发者还要和服务器斗争多长时间。

Johnson解释说他对SpringSource应用平台成功的自信来自三个原因:

  • 它是第一个建立在现代技术基础上的产品。符合Java EE规范已经不是至高无上的目标。干净的代码基础是我们的一项竞争优势。我们在设计和实现中满足的是现今的需求,而不是10年前的需求。
  • POJO编程是现在行业的方向所在。过去POJO编程是被强行嫁接到其它产品上的。在我们的产品中,POJO编程是设计的前提。
  • SpringSource应用平台采用的OSGi技术是下一代技术的基础。

除了Rod Johnson,InfoQ还与SpringSource的Rob Harrop探讨了新应用服务器的一些技术细节。对于与传统Java EE应用服务器相比有何增减,他说:

……JPA和JMS都支持,但我们没有包含任何特定实现。对于JPA,我们支持Hibernate、 OpenJPA和Toplink。我们在OSGi环境中增加了对加载时织入的支持,而且会尊重应用的边界,因此不会意外污染应用间共享的库。不包括 JNDI,我们用OSGi Service Registry来取代它。Servlets是通过内嵌的Tomcat来支持的。JEE中有而SpringSource应用平台没有的东西包括 Entity Beans等等。

接下来InfoQ问到Spring Dynamic Modules。Spring DM成为公开项目已经有一段时间了。对于模块化部署,我们向Harrop询问Spring DM是否增加了什么新东西:

这个平台引入了应用的概念,应用由一个或多个Bundle组成。应用中的包有明确的作用域,可以防止发生应用间的冲突。在应用把服务发布到OSGi service registry的情况下,防止冲突尤其重要,谁也不想见到服务之间发生冲突。

我们引入了Import-Library语句,因此在应用中使用第三方库变得更加简单。你不需要再写一大串不直观的 Import-Package声明,Import-Library可以自动为指定的库引入所有必需的package。像Hibernate JPA这样的库还可以跨多个Bundle,可见Import-Library确实物有所值。

至于为了让Spring DM在平台中运行而进行的扩展,为数不多。

Harrop接下来说明了新的PAR格式:

Spring DM掌控下的Bundle(Spring DM powered bundles)是包含META-INF/spring/*.xml文件的普通OSG Bundle。Bundle启动的时候META-INF/spring/*.xml文件会自动成为该Bundle的 ApplicationContext。Spring DM提供了一种机制让各Bundle通过Spring NamespaceHandler导入和导出服务。

一个PAR(Platform ARchive)本质上是一组OSGi Bundle,通常其中有一部分是在Spring DM掌控下的。这些Bundle共同组成了一个逻辑上的应用。编程的时候完全是纯粹的OSGi、Spring和Spring DM——PAR没有改变什么。

以前一般用Buddy Classloaders之类的技术来解决遗留/非OSGi库的问题,SpringSource这次是怎么做的呢?Rob回答说:

简单来说我们避免做这样的事。Buddy类装载、动态import、require-bundle,这些我们都明确回避,因为维持一致的类空间太困难了。我们也不会提供任何专有的替代机制。

相反,我们给Equinox增加了一些低级的钩子,以实现典型的场景下的资源装载。我们扩展了类装载来支持加载时织入,并且把装载语义丢到一边。我们操纵context classloader,让第三方一如既往地看到类。PAR是其中的核心角色,因为它定义了上下文类装载以及加载时织入的可见范围。

对于一些最糟糕的情况,我们会提供修补版的库,让它们能在OSGi中工作。修补版的库可以通过SpringSource Enterprise Bundle Repository获得,我们的修改也会提交回相应的项目。

最后Harrrop着重强调了这个应用服务器在模块化上的优势,应用服务器因此可以维持最低的内存占用。平台在运行中才设置依赖项,因此只有确实用到的依赖项才会被装载。

最近几年中有过许多关于Java EE标准是否已经死亡的讨论,而今天我们看到一个可能很重要的应用服务器不带Java EE支持。这种变化对于未来有何影响?你怎么看?

查看英文原文:SpringSource Launches New Application Server without Java EE

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

想想谁是Spring的主人 by Wu Chunguang

Spring已经是M$旗下的战将,微软一直以来都在不遗余力的与java对抗。摧毁javaee,将使java阵营返回战国时代,这正是M$想看到的。

Re: 想想谁是Spring的主人 by Lin Tony

Spring已经是M$旗下的战将,微软一直以来都在不遗余力的与java对抗。摧毁javaee,将使java阵营返回战国时代,这正是M$想看到的。

这位大哥,你是不是弄错些什么东西??Spring成了微软的战将?
拜托,不用把愚人节的玩笑当作事实……

Re: 想想谁是Spring的主人 by Wang Denis

大哥,你的幽默感真的是很强啊。你是强人,崇拜中......

Re: 想想谁是Spring的主人 by cao yi

今天已经五一了,你还在娱乐大众呀。。。

SpringSource新应用服务器发布 摒弃Java EE by zx bnm

不管怎么说 技术的方向始终是受利益指引的

Rod 大叔又开始玩标题党了,Spring早就加入Java EE 6的阵营了 by 刘 长炯

JSR 316: Java EE 6, jcp.org/en/jsr/detail?id=316.

成员列表(以前的反叛者,号称不用EJB的Spring后台公司,红字部分,也加入了Java EE 6 的大家庭,看来新版Java EE也许是大势所趋啊,呵呵):

Interface21 Inc
再看Spring直接开始了作为EJB容器的实现的支持项目,我一直说Spring只不过是另一个Application Server(而且还不是性能很好的那种),现在终于得到了验证,红字的就是 Rod 大叔(Java的开源,大多数最后都会成立公司,成为商业项目来运营,从Hibernate,JBoss再到Spring,无一例外,盖项目代码大了以后,就是开源了,外人也看不懂):

static.interface21.com/projects/pitchfork/files...

Rod 大叔是个聪明人,他也知道企图把所有人呢都帮到Spring上,那是不可能的。只有规范化才是当前的大势所趋,现在的专有格式的配置文件和开源框架,已经足够多了。要不然也不会有JPA的出现。

Re: 想想谁是Spring的主人 by Lee Balan

你太猛了.....人们如此渴望表达自己的观点,以至于可以引用任何不加分析的论据。

是呀 可怜现在带论据说话的人更少 就跟抵制JLF 一样 都是口号 没一点事实根据 by 刘 长炯

那怕是假消息来源地址也没,就跟好多人发帖从来不留出处一样。

Re: Rod 大叔又开始玩标题党了,Spring早就加入Java EE 6的阵营了 by liu ozzzzzz

这个事情还难说。加入委员会并不是啥标志,关键还是要看最终他是否能够影响最终的结果。
想做和能做到最终做出自己希望的结果差距太大了。

Re:Re: Rod 大叔又开始玩标题党了,Spring早就加入Java EE 6的阵营了 by 刘 长炯

Java EE 是厂商之间妥协的产物,Spring 现在正式把自己定位为服务器提供者,“关键还是要看最终他是否能够影响最终的结果”,影响肯定是有,但是所有的公司都想加入自己的新功能,换句话说每个参与者都能影响最终结果,我想你能明白我的意思。呵呵,各位大大不要以为把自己的应用绑定到某特定服务器上迁移不得,就是个好事,要不然Java EE 规范根本就没有出现的必要。

Re:Re: Rod 大叔又开始玩标题党了,Spring早就加入Java EE 6的阵营了 by 刘 长炯

换句话说就是有钱大家赚,看看Eclipse的经营模式就知道了,公司主导的开源项目,大家都要分一杯,Java EE也是公司主导。开源软件消费者:我们,并不能主导Spring,JBoss的发展方向,甚至有朝一日人家搞成完全商业的,也没办法。看看ExtJS,Jive论坛,就知道了。Java中的开源,大多都是先做免费广告,用户量上来了,就开始走商业化了。

明明皈依了JavaEE,明明选择性实现了JavaEE6 by Lee Balan

不完全实现一个标准,就是摒弃一个标准吗?

Re: 明明皈依了JavaEE,明明选择性实现了JavaEE6 by 刘 长炯

也如 Rod 大叔认为只有 EJB 才是 Java EE,JSP, Servlet不算,WAR也不算。

回复 by 果 林

OSGi 终于要大举进入程序员的视野了.

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

14 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT