概要
Rod Johnson谈到了Spring Portfolio、Oracle对BEA及Sun对MySQL的收购、Java EE 6、Tomcat和Spring、Spring动态模块、企业级Java的未来、OSGi为应用开发者带来的好处、对Covalent的收购以及 Spring 3.0。Johnson还提到了SpringSource应用平台——它会在该访谈制作好的一个月后发布。
个人简介
Rod是Java和J2EE开发方面的权威人士。他是畅销书作者、极具经验的咨询师以及开源的开发者,同时他还是深受欢迎的演讲者。Rod是Spring 框架的创建者,该框架源自已出版的Expert One-on-One J2EE Design and Development一书的代码。Rod将与Juergen Hoeller一起继续领导Spring的开发。
我是Ryan Slobojan,我现在与Rod Johnson在QCon呢。感觉如何?
非常棒,我很享受这个会议,也很高兴能重回伦敦。
太好了,很高兴你能这么说。我想问你的第一件事就是在3月20日将发布Spring portfolio相关的一系列产品,你能详细说一下么?
是的,我们向Spring portfolio增加了大量新功能,包括Spring Security2.0。这是Acegi Security针对Spring的演变,很明显它将成为Spring portfolio的核心组成部分,同时该变化使得Acegi Security更易于使用。Acegi Security的一个历史遗留问题就是它虽然很强大,但不那么容易使用。我们对Spring的座右铭就是“简单而强大”,并且我认为现在已经做到了这一点:通过Spring 2的命名空间大幅简化配置并使得Spring Security简单好用。即将发布的还有Spring Web Flow 2.0。围绕着易用性我们对Spring Web Flow进行了大量的增强,同时也增加了JSF和AJAX相关的一些功能。因此我们敢说,对于使用JSF的用户,Spring Web Flow是他们最自然的框架选择。接下来的一两个月中,我们还会发布多种SpringSource产品,包括SpringSource工具套件,这是一个 Eclipse增值包,为我们的付费客户提供了很多新特性。另外我们还会发布SpringSource应用管理套件,这是一个管理和操作监控产品,可以在生产阶段提供关于Spring应用的详细深入的信息。同时还会提供针对Oracle数据库的SpringSource高级包,它提供了与Oracle RAC、Oracle AQ及Oracle其他产品的增值连接。
很好,你提到了Oracle。最近软件开发领域的一个变化就是Oracle收购了BEA,Sun收购了MySQL。你认为这将对开源和Java产生什么影响呢?
这个问题很有意思。我认为Oracle对BEA的收购不会对开源产生太大影响,因为很显然这两个公司都不是开源公司。我们与BEA和Oracle都保持着很好的关系,因此我们认为大家还可以继续使用Spring和WebLogic,尤其是两者合用,没什么好担心的。关于开源,我猜BEA要比Oracle使用了更多的开源软件,比如他在WebLogic 10核心中使用了Spring。另一方面,Oracle也越来越多地使用开源软件,因此我希望他能将这个趋势更进一步。我想这对JCP会有一些重要的暗示,因为现在的应用服务器市场越来越呈现出两强相争的局面。如果你看一下传统的服务器市场就会发现这已经完全被IBM和Oracle统治了(在 Oracle获得了大量的WebLogic客户后)。同时,BEA所面临的挑战,尤其是来自于JBoss的挑战自从Red Hat收购了JBoss后看起来已经在减弱了。因此,我认为这会产生一些有意思的副作用。本质上,成熟的Java EE服务器市场在很大程度上将会出现两强相争的局面。这会促使更多的人寻求轻量级的解决方案如Tomcat。关于Sun对MySQL的收购,我觉得这对 Java是件好事。显然这会帮助Sun推动其开源的承诺,我也很期望通过这件事会使JCP变得更加开放、更像一个开源过程。
太棒了,你刚提到未来的一个趋势是转向轻量级解决方案如Tomcat。那么你认为Java EE 6规范及其profiles的想法是否会对其有所帮助呢,或者说这种趋势根本不会受到规范的束缚?
我觉得这事迟早都会发生。从个人角度来说,我觉得Java EE 6首先需要回答这个问题:它能否按计划发布、能否保证Java EE的相关性。我认为Java EE规范塑造市场的时代已经过去了。Java EE 6中的很多东西都是非常积极的。其中之一就是profiles了。很明显人们很重视JCP标准,这些标准要比其他一些标准更具价值,同时用户也希望拥有标准化和一致的子集。因此我认为profiles是个非常好的想法,可扩展性的目标也是个好主意,Java EE的部分作用在于开创一个供创新生长的大舞台而不是交付企业级Java所需的全部东西。当然,SpringSource也对Java EE 6做出了巨大的贡献。我是Java EE 6专家组成员,我尤其看好profiles的前景。看看Tomcat的统计数据吧——我在几个月前的博客中已经提到了这一点——我认为Tomcat差不多占据了统治地位。毫无疑问,Tomcat已经成为应用服务器市场上的老大了。它遥遥领先于WebSphere,而在大多数调查中WebSphere都处于第二位。因此我觉得Java EE已经在特定的方向上取得了长足的进步,至少从Java EE 6看是这样的,很多人都会说“嘿,这就是我们想要的一个子集”。
最近Spring Dynamic Modules 1.0发布了,你认为这是Spring portfolio策略的一部分么?
当然是了。Spring Dynamic Modules是个非常重要的项目,因为我们相信Spring与OSGi的组合是Java中间件的未来。毫无疑问,OSGi已经做好了重塑服务器端的准备,其采取的方式与获得极大成功的Eclipse插件架构如出一辙。不过,虽然OSGi赐予了我们非常棒的动态模块化解决方案,可以解决版本标定、热部署等诸多问题,但是它并没有提供组件模型、也没有企业服务,而且还不会赐给企业级开发者所需的经验。你只要在企业服务中将OSGi和Spring组件模型放到一起,你就得到了既易于使用且功能强大的一个东西。因此我们将Spring Dynamic Modules看作是Spring portfolio策略的重要组成部分。
我还有一个问题。过去几年中我们看到了企业级技术的很多问题,POJO要比EJB更流行。现在J2EE 6中又出现了profiles,那么我想知道你对未来的看法。Tomcat和Spring会成为企业级服务器的主流么?重量级、复杂、功能完全的J2EE 服务器还有生存空间么?
这个问题问的好。我认为Spring和Tomcat会成为主流的企业级Java平台。我们已经委托研究分析机构做过一些调研,尽管我不能说出具体的数字,但基本上这些调研结果都表明Spring和Tomcat要比WebSphere、WebLogic等更加流行,很明显市场已经发生了一些变化。还有很多数据也都证明了这个事实。
我的意思是不要光听我说,你可以看看工作列表,相对于EJB来说,更多的工作需要Spring。我并不认为J2EE或Java EE平台已死,profiles可以保持其长青。坦率地说,我觉得功能完全的应用服务器已死,但这是件好事。然而并不是说WebSphere和 WebLogic这样的产品就没有市场价值了。
这些产品还有些价值,但我觉得人们可能以不同的方式利用这个价值。大家都不想要过于庞大的东西了——他们想要可选择的东西。事实上你可以看看那些供应商所采取的方式,比如BEA的MSA(Micro Services Architecture),他们都使用了OSGi。
实际上他们正在不断更新产品以使其更加模块化。很明显Java EE应用服务器是由委员会设计的,它并没有真正解决应该解决的问题,世界也在不断变化着,这使得规范的相关性相比之前变得更加弱了。就拿SOA来说吧,随着SOA的出现,越来越少的应用会采取那种大而全的架构了。就Java EE具体的组件技术来说,我认为其中一些技术还是有着光明的未来的,而其他一些则不然。Servlet API就有着光明的未来且相关性很好,因为它还是非常基础的。
很多技术或是API比如JMS和JTA定义了基本的中间件契约,我认为他们还会继续发挥重要的作用。JPA很有可能会成功。相对于EJB,我更看好 JPA。我的意思是EJB是个很差劲的技术。我实在是不明白Sun和其他一些供应商为什么还要维护EJB。我认为EJB已经是穷途末路了。因此很多大的组织比如银行已经放弃了EJB。我觉得有两种选择:其一是彻底放弃EJB,其二是不再让其向后兼容了,这样的话一切都要重头开始,很显然这更可行,因为丢掉了一个大包袱。
OSGi对于服务器或IDE的好处显而易见,但应用开发者在什么情况下需要使用OSGi呢?
其实对于应用开发者来说,这机会与服务器的基础设施一样。其中一个好处就是模块化并且只运行想要的东西而不是整个重量级的平台,凭借OSGi,你可以在运行中只启动需要的bundle。这样计算机的运行速度就会更快。如果你只想加载所需的东西,OSGI非常胜任。
主要的一个好处是可以得到更加模块化的中间件平台,只加载所需的组件完成特定的目标。这意味着在一年到两年的时间内,我们会看到能做任何事情的功能完全的企业级平台,而启动速度要比现在快得多。我认为版本标定和热部署这些特性是非常重要的,因为企业级Java中的版本冲突问题变得越来越严重了。
我相信很多人有过这样的经历:不同项目中的类使用了不同的开源库。就拿Hibernate 3来说吧,第一次用其做查询时就将导致WebLogic 8.1或9服务器停止,我说的停止是指控制台打印出这样的消息“CharScanner; panic”。原因在于WebLogic和Hibernate都使用了ANTLR,但他们所用的ANTLR版本是不一样的。随着很多商业应用服务器也越来越多的开始使用开源产品,这些问题变得更糟了。
基本上Java EE对其的解决方案就是“哦,我们还没有遇到过这个问题,请使用供应商给你的东西吧”。因此出现了很多小技巧来改变类的加载顺序,这些技巧无法移植,并不是真正的解决之道,只是权宜之计罢了。看看OSGi吧,它真正的解决了这个问题。其解决方式是标准化的,可以在不同的环境下移植。它是可预测的方案。
凭借OSGi,我们还可以并发运行相同应用、同一个类的不同版本,还可以实现商业应用组件的精细化重新部署。我想其真正的优势在于提高无故障运行时间。你无需停下应用以替换账单系统中的某些类,在运行时替换就可以了。我们还需解决很多问题以简化其使用方式。因此如果现在就使用Spring、Spring Dynamic Modules及OSGi,你会发现还是有点复杂的。
慢慢的我们会看到更多的集成产品,他们会将这些特性放到单独的解决方案中。但技术方案是确定的,OSGi会解决像版本标定和可维护性等问题,而目前 Java EE并没有提供好的解决方案。未来我们会看到隔离的好处,比如AspectJ的加载时编织和OSGi的集成。一旦根据bundle定义好了部署模型(独立于任何特定的环境如Java EE服务器),你就可以用加载时编织实现很多有趣的事情了,比如自动的策略增强。这为我们提供了无限的可能。
我们再来谈谈收购吧,SpringSource最近收购了Covalent。你对此有何想法?
我们做了一笔好买卖,因为在进行收购时,Sun也宣布用十亿美元收购LAMP中的M——MySQL,而我们只用不到十亿美元就收购了LAMP中的A—— Apache!这么说有点没礼貌,没人能独享Apache项目,我的意思是我们完全理解Apache社区。对Covalent的收购折射出很多因素:首先,就像任何成功的收购一样,这是由客户驱动的。我们已经与Covalent的客户进行过讨论,他们希望得到Covalent对Tomcat和 Apache Web Server的支持,还希望得到SpringSource对Spring的支持。显然我们需要进行一些合作了。
对于那些不熟悉Covalent的人我得做些解释,Covalent是Tomcat和Apache Web Server支持和服务的主要提供者。Spring与Tomcat的组合事实上已经成为企业级Java最流行的平台,我们两家合并可以为这两者提供更高质量的服务。我们这两个公司的利益有很多共同点。我一直坚信只有积极参与到开源项目中并贡献知识产权,你才能为开源项目提供高质量的支持。Covalent 也和我有一样的想法。
一些Covalent工程师包括大多数积极的Tomcat提交者也都有这种想法,其中还有Bill Rowe,他编写了大量的Apache 2代码,同时也参与到Apache的开发中。因为有共同的看法和这么多相互尊重的人,所以这次收购是自然而然的事情。最后这是我们在成为企业级Java开源领域中领头羊的自然一步,同时这也是一个机会,能为企业级Java事实上的标准提供支持。
谈谈未来吧,Spring Framework 3.0有什么新特性呢?
Spring Framework 3.0将会继续对2.5版中Spring MVC所引入的特性提供增强。从最终用户的角度来看,2.5版最大的改变就是对注解的使用,这样我们就可以跨越Spring IoC容器和Spring MVC使用注解了。在Spring 3.0中,我们会进一步促进MVC和Web Flow之间的编程模的融合。我们希望提供一个单一的编程模型,它既可以使用在Web MVC经典的请求——响应导航上,也能用在Spring Web Flow提供的直接导航上。我们还打算支持REST,比如处理Spring MVC RESTful URL,同时不再支持Java 5之前的版本。我们已经拥有了对Java 5和Java 6的扩展支持,所以其影响范围很小,但我们可以更轻松的维护纯Java 5+所编写的代码了。
我还有最后一个问题,有没有新的针对于Spring portfolio的项目呢?
最近新加入的就是Spring Integration,这是在十二月份的Spring Experience上宣布的。它为构建在Spring组件模型上的企业集成提供了模型。它还提供了一种创新的编程模型,该模型大量使用注解来简化模式的处理,如聚合、转换和路由等。最近还不打算向Spring portfolio中添加新的项目,但你已经看到过几个月将要发布很多项目,我们在Spring portfolio上还是非常积极的。当然了,SpringSource还会继续发布新的产品,到JavaOne举办之时,我们将会演示很多重要的新产品。
- 大小: 296 Bytes
分享到:
相关推荐
综上所述,Spring OSGi结合了Spring的便利性和OSGi的模块化优势,为Java企业级应用提供了一种高效、灵活的开发和部署方式。通过学习和掌握Spring DM Server的使用以及Spring OSGi的相关库,开发者可以更好地在OSGi...
Spring OSGi适用于大型企业级应用,尤其是那些需要高可扩展性和动态部署能力的系统,如云计算平台、嵌入式设备和物联网解决方案。 6. **开发实践** 开发者在使用Spring OSGi时,需要了解如何编写OSGi兼容的jar包...
Spring OSGi通过结合Spring框架的强大特性和OSGi的动态模块化能力,为企业级应用提供了更为灵活、高效和易于维护的解决方案。它不仅简化了开发流程,还增强了系统的可扩展性和稳定性。开发者可以充分利用这两种技术...
1. Spring Framework:Spring是一个全面的Java企业级应用开发框架,提供依赖注入、AOP(面向切面编程)、数据访问、事务管理等功能,简化了Java应用的构建。 2. OSGi:OSGi是一套用于Java平台的动态模块系统,它...
内容全面,系统讲解了利用Eclipse RCP和Spring OSGi开发大规模Java应用的核心技术;实战性强,包含大量易于操作的案例和最佳实践。 《Eclipse RCP与Spring OSGi:技术详解与最佳实践》共分3个部分:基础篇(第1-5章)...
Spring OSGi是Spring框架与OSGi(Open Service Gateway Initiative)规范相结合的产物,它允许在OSGi容器中使用和管理Spring应用。OSGi是一种Java模块化系统,它提供了动态部署、版本控制和依赖管理等功能,极大地...
其次,Spring框架是一个广泛使用的Java企业级应用开发框架,它简化了依赖注入、AOP(面向切面编程)、数据访问和事务管理等任务。OSGi(Open Services Gateway Initiative)是一种Java模块化系统,允许组件动态地...
**Spring OSGi 快速入门中文教程** OSGi(Open Service Gateway Initiative)是一种Java模块化系统,它允许开发者创建可热更新、可隔离且互相依赖管理的模块。Spring OSGi是Spring框架与OSGi服务的结合,使得在OSGi...
OSGI是一种模块化系统和Java应用程序执行环境,它允许开发者将应用程序分解为独立的服务组件,而Spring是Java企业级应用开发的主流框架,提供依赖注入和面向切面编程等功能。 描述中的"OSGISpringOSGISpring"可能是...
Spring OSGi是Spring框架与OSGi(Open Service Gateway Initiative)规范集成的产物,它使得在OSGi环境中使用Spring变得更加方便。OSGi是一种模块化系统,用于Java应用程序,提供了动态服务发现、版本控制和依赖管理...
在IT行业中,Spring框架以其强大的功能和灵活性在企业级应用开发中占据着重要地位。而Spring OSGi则是Spring框架与OSGi(Open Service Gateway Initiative)规范的结合,它为Spring应用提供了在OSGi容器中运行的能力...
标题中的“tomcat-osgi.rar_OsgiContentFactory_osgi_osgi tomcat 集成_osgi tom”表明这是一个关于Tomcat服务器与OSGi框架集成的资源包,其中可能包含了如何在Tomcat中使用OsgiContentFactory来管理OSGi服务的内容...
Spring OSGi 是 Spring 框架与开放服务网关规范(OSGi)的结合,它为基于 Java 的应用程序提供了模块化开发的能力。OSGi 是一个动态的、模块化的运行时环境,使得开发者可以创建可热插拔的模块,这些模块称为“服务...
Spring则是一个流行的Java企业级应用框架,提供依赖注入、AOP(面向切面编程)、事务管理等功能。 标题"OSGi Spring实例"表明这是一个关于如何在OSGi环境中集成和使用Spring框架的实际应用示例。这个实例可能包含了...
Spring框架是一个强大的轻量级Java应用程序框架,而OSGi则是一种模块化系统,用于管理和部署Java应用程序。在Spring OSGi中,Spring的应用组件可以作为OSGi服务来发布和消费,从而实现更灵活、可插拔的架构。 标题...
标题中的“tomcat嵌入OSGI容器”是指在Apache Tomcat服务器中集成OSGI(Open Service Gateway Initiative)框架,使得Tomcat能够支持模块化的应用程序部署和管理。OSGI是一种Java平台上的服务导向架构,它允许动态地...
SpringOSGi.jar
总的来说,Spring OSGi规范为Java开发者提供了一种利用Spring框架的强大功能和OSGi的动态模块化能力的途径,使企业级应用的开发和维护变得更加灵活和高效。结合这两者的优点,开发者可以创建更可扩展、更易于维护的...
### 基于OSGi和Spring开发企业级Web应用 #### OSGi与Spring结合的重要性 随着企业级应用复杂度的不断提升,对于软件架构的要求也越来越高。为了更好地满足这一需求,许多开发团队开始关注并采用OSGi(Open Service...
dmServer,全称为Dynamic Modules Server,是一个完全模块化的Java服务器,其基于OSGi,专为运行企业级Java应用和Spring应用而设计。dmServer的模块化特性使得它能够提供更加灵活和可靠的部署环境,对于那些需要频繁...