Rod 是Spring的缔造者，Spring开源项目开启于2003年2月，并基于此出版了极其
叫卖的一本书<Expert One-on-One J2EE Design and Development>.
    Rod 也是世界上顶尖的Java，J2EE开发专家之一，畅销书作家，富有经验的咨询师，
开源项目的开发者，还是一个为人所熟之的技术研讨大会的演讲者。
    Rod 的畅销书<Expert One-on-One J2EE Design and Development>(2002)给J2EE领域
带来了很大的影响力和冲击力,另一本<J2EE without EJB>(2004)，也表达了同样的信息，也
就是，基于一个易懂的，轻量级的框架开发，已经是后EJB时代的趋势。
     
    Rod在行业咨询领域有着广泛的经验:主要是金融，媒体和保险业。他从1996年开始专门
从事java的服务器端开发.更早些时候，他主要用C和C++,他长期从事咨询师的经验，使得他
能够经常以客户的角度而不是一个技术人员的角度去看待问题，更驱使他在深入J2EE后，对
J2EE架构的批判,因为他认为，传统的J2EE架构过于臃肿，低效率，给关注它的人们带来的优点
和益处很有限。
    
    Rod 是Spring框架的创始人，Spring的开始就是从<Expert One-on-One J2EE Design and
Development>这本书中的代码衍生而来的，连同Juergen Hoeller一起，Rod继续领导着Spring的开发.
    他经常在技术大会上做演讲，足迹遍布美国，欧洲，亚洲，包括 the ServerSide研讨会
(2003,04,05 and 06),JavaPolis(欧洲顶级的java大会)2005,2006,JAVAZONE(2004,2005)还有
JAOO(2004).他被评为2005年JavaOne大会的表现最佳20人之一,另外他的发言也为2005年六月东京
的JavaWorld大会，2005年十月幕尼黑的JAX大会,以及2005年十二月在佛罗里达Bal Harbour海港
召开的Spring经验交流会奠定了基调。
    Rod 是JCP的一员，是Servlet2.4和JDO2.0规范制定专家组的成员，他在java社区的领导地位
早自他在SUN公司的java程序设计冠军挑战赛中已经得到大家的认识。
    Rod 将继续潜心服务于Interface21(Rod是此公司的CEO)的客户，同时继续Spring的开发和推广.

Rod和Ted,Don之间关于EJB和Spring的讨论(一)

几天前，在Don Box的博客上，我设法回答一个问题"Spring比EJB简单吗？".
现在,这个问题像是有些多余了，因为Spring和EJB的目标并不完全一致，但也许
从EJB和Spring两者所共有之处来回答，是可以的。Ted Neward在他的博客上对我
的回复进行了评论,我现在去回应一下他的观点。
    Ted评论:
        Spring是一个比EJB简单多了的框架，因为Spring更多是用基于POJO(Plain
Object Old Object)的方案，但对于"某些情况"下，它并不简单,而是更复杂。
    
    Rod:好的,在"某些情况"下,地球是扁平的?呵呵,在我的经验中，如果实现业务逻辑所
需要的java Object超过3个的时候，认为用POJO(通常有一个接口)方案更复杂的人很
少：给我印象深刻的是，否定POJO方案的那些人，真正尝试两种方案并做出对比
的人为零。可能他们有自己的观点，但我并不知道。(也许直接的事务和远程方法更
另人愉悦？)我真的非常希望看到能真正证明基于POJO的方案更复杂更难用的评论。    
    Rod:为什么Spring比EJB简单易用?我不能给你一个独立的主观臆断，我可以告诉
你的是，我是借鉴EJB，并运用我多年的经验来设计Spring的，我也很乐于去比较.从一
开始，Spring(或者其他的IOC加Services框架)框架就是和你的业务代码隔离的，没有
藕合的.这个区别是有重大意义的。任何Object都可以被事务化而不需要陷入EJB的丛林
中。这对于代码的重用也是有意义的。实际上，在你自己的业务对象中，很少有框架的
侵入，换句话说，你会有更多的自由去运用面向对象的分析设计。
   
    Ted:哦，我已经说过了，企业级系统通常不是来练习OO(面向对象)的,因为那么做有一种
让我们陷入麻烦的危险趋势----这也就是为什么人们在网络计算的趋势下，使用CORBA,DCOM
和RMI来解决问题的原因。你应该考虑一下，把collection置于服务器端，iterator放在客户
端的意义，然后你就明白.....
    Rod:Ted,我提到的"更多自由去使用OO",并不是说所有地方都用OO,当然，分布式对象是很
需要的。但重要的是，不要把"企业应用"和"分布式应用"混为一谈. 应用程序的内部结构应该
尽可能的面向对象.然后提供一个高层的接口对远程调用暴露，理想状态下，仅仅这个接口才可
以放弃面向对象.(基本上像SDO--服务数据对象Service Data Objects这样的解决方案在这部分
是很庞大的).所以在分布式对象建模中，在应用内部引入优秀的应用程序接口(虽然破坏OO)是
没有争议的。Spring和其他的IOC(inverse of control控制反转)容器，不会在OO方面设置障碍,
而EJB就没做到，它大范围内地依赖了EJB的接口和框架。
     
    在我对于Spring的XML配置要比EJB复杂的部署描述文件简单易配置的评论后----Ted写到:
    公正地说,Rod--JSR 175 在简化部署描述配置(包括你的Spring的XML配置)方面的所做的工作
是有意义的(而不是所有),在java5之前，部署描述文件是一个必须的，很恼人的事情吗？不幸的是，
事实表明，考虑到所有的可能性，这已经是最佳的解决方案了。(所有人都记得EJB1.0时，基于对象
的描述符)。
    Rod:没错,JSR-175会在DD(Data Define数据定义)方面进一步改善(已经有所改善，虽然注释被一再
过度使用,不过那是另一个话题了).不错，DDs(数据定义文件)是必要的，虽然很繁琐，这是java借用C#
中属性集/注释的想法而来的.但问题是,现在的EJB部署描述让人惊骇地冗长，差不多全在XML里.而且一
个标准的ejb-jar.xml部署描述文件并不够，通常需要两个。相反，Spring的配置文件短小精悍，而且
不需要额外的引用。当然，EJB3.0不在这里讨论，因为我想评论的是现在使用EJB的方案(直到2006或者
JSR-220完成的时候)。
    
    在Don的博客上，我对他拿Spring进行的测试表达了我的尊敬:
    
    Rod:因为你的代码不是严重依赖于容器的，所以可以方便的进行单元
测试，比如用JUnit。这样一来，和过去传统的J2EE容器内测试方案比起来，
提高了巨大的效率。你也可以在Spring容器上做集成测试，而不需要一个重
量级的J2EE应用服务器----不像其他应用服务器，Spring容器可以很快启动。

Rod和Ted,Don之间关于EJB和Spring的讨论(二)

Don:我仅仅是说尽量少的依赖于容器，EJB并不是一个完全失败的
技术，用OpenEJB容器效率并不会很低的，至少从我的测试来证明。
      
    Rod:我并不确定像OpenEJB这种轻量级的EJB容器会是一个另人满意的
解决方案.我没有遇到有人用过它，我自己也没用过。真正的EJB测试总是
繁杂的，通常需要五分钟一个编码/测试循环。
    Rod:比较一下Spring的Pet Store例子和EJB方案的，就可以发现,在
Spring的例子中，很少有冗余的代码，也就是说什么都不做的代码...
比如Service接口,JNDI服务查询操作等等.在我接触的项目中,用一个Spring
+Hibernate的混合框架，至少能拿去EJB方案的10%---20%的代码,对于项目
的提交和后期维护是有重大意义的.
    Don:我来说说我的观点,简单并不永远是好的，不幸的是，它仅仅代表简单，
没有JNDI，就等于说牺牲了管理人员在不重启服务器的情况下，对配置进行调整
的需要。这可能对于一些客户的应用来说不是太重要，但对于一个24*7的应用来
讲就是个大问题了。
    Rod:当然，我说的用Spring终结你代码中的"服务接口，JNDI查找",并不是说
真的不用JNDI,比如说，你还是希望调用EJB,Spring可以给你创建一个代理，封装
了JNDI查找啊。
  
    在Pet Store的例子中，我尽力寻求一个简单的架构--既然我们来讨论Pet Store,
关键的就是，Spring和其他轻量级的框架技术，给了你一个简易框架的选择。
如果是传统的J2EE,你想创建一个Pet Store,你最好是用Perl或者.Net,或者抛弃
J2EE的高级特性，只选择Servlet和JSP,所以有一个你自己的简易架构是必要的。
    "没有JNDI，就等于说牺牲了管理人员在不重启服务器的情况下，对配置进行调整
的需要",嗯，有多少需要用JNDI重新配置应用的需要?更好的解决方案是JMX,但应用
服务器并不了解你想做什么有意义的配置，同时Spring 1.2已经加入了对JMX的支持,
这将方便开发者去操作应用对象和配置。比如说，改变一个JNDI的环境变量是我们
很少要做的事情.开发者通常会很准确地配置这些信息，来避免修改的痛苦。(我同意，
这可能是个不好的假设，但确实通常是这样的)，你如果想通过JNDI来改变某个值，你
已经知道何时来找到它,等等。
     Don:请记住，EJB提供2PC(两段提交)事务的支持，而Spring没有，这一点让我不安，Spring
失去了它的亮点。
     Rod:Spring不会做或者很少做2PC(两段提交)事务,不知道怎么就确定Spring失去它的亮点了,
Spring的事务层抽象是在事物策略的基础上的一层，一个方案就是JTA,在这种方案下，
双机事务来自于应用服务器底层的支持，而不是Spring.实际上,JTA事物策略是我们最早
就重视并实现的功能。我明白，在一个无JTA支持的简单容器下，丢弃一个落后的local
和global事务编程模型是很有意义的.

我参加了旧金山举行的Oracle World大会.我跟随Thomas Kurian的发言基调，做了
对Java中间件为主题的发言. 但是Neelan和我不得不在周三离开，没法听一个重要发言:
Larry Ellison宣布Oracle将要对Linux提供支持.
  
     在开源事务的角度来看，这是有趣的一件事,关于此事广泛的评论是什么呢?

     Oracle将要对一个不是它构建也不是它能控制的开源项目进行支持.
   
     这可能有几个原因:

     * Linux不是一个产品,它是一种技术，一些公司和组织支持它，提供基于它的产品.
   
     * Linux的支持很广泛，Red hat只是很多提供支持的厂商之一
  
     * Linux的领导地位不确定，Linux Torvalds没有为任何公司工作，Red Hat虽然在其上
做过很多工作，但没有一个公司拥有确定的领导地位.
  
     * 做Linux的领导公司不是件很麻烦的事情，Linux不仅是一个革新，也是易用及便利性
的典范.

      然而，如何界定一个像Oracle的公司对开源项目的支持，对开源事物的支持是值得思考的。
      让我们看一下Interface21和Spring(JBoss,Hibernate,MuleSource,Mule,LogicBlaze,
ActiveMQ等等)，有什么不同吗？
      * Spring既是一个项目也是一个产品,市场不希望有另一个版本的Spring,当Spring一出现
并很好地运行时便是如此。
  
      * Spring的引导者是很强的，也被用户所尊敬。在Spring出现前，很多Spring现任主要开发
人员，都是业界的领导者，即使Spring没有诞生过，他们仍然是业界的精英和领导。
      * 引导Spring的方向是困难的。Spring并不是因为便利和易用出现的，它是一种变革.它的出现，
改变了很多人开发企业级Java应用的方式，并且仍将继续。用户们不仅仅需要懂得Spring的今天，并且
需要知道它将来的发展。
  
      所有这些都保证了Interface21在Spring上的投入是值得的。出色的领导力，和卓越的技术创新能
力，为客户带来了很多价值:帮助并支持客户推进项目，了解客户的需求并经常与核心开发者进行沟通，
专业的服务为用户解决问题，并继续在业界保持努力提高地位。总之，Spring有今天的成就，是来源于
“开源”的。
      显然，我用了很多时间来考虑Spring和商业之间的关系.但是有一个通常的观点.开源项目的拥有
者没有那么重要.重要的是它的创始人.商业上,是不会创造开源项目的--很大比例的开源项目,都给竞争
者带来潜在的伤害.换句话说,它自己的生存期可能不很长,但对于在它之前产生的项目有威胁作用.

虽然对于开源项目的创始人来说有点好处，但项目没有锁定在某一公司。让我们来设想开源项目的两种可能结果,不管这是否会发生:
   
    1.开源项目绑定于创始人，没有选择服务大众。
    
    2.项目创始人没有对业界反馈做反应，商业开源和起初的开源背道而驰，最终结果
往往是项目仅仅变成一种个人爱好。
    对于客户和技术发展来说，上面两种无疑都不是什么好结果。
    (1)客户喜欢开源项目是因为，它引入了竞争(以及客户可以选择不用购买服务，自己去大搭建)，
他们不愿意看到一种情况就是，也许他们拥有源代码，但不敢去切换服务至开源项目上，因为项目
的支持度不够。

    (2)这种情况下，不同的利益团体对项目是有毁灭性打击的，将项目扼杀于摇篮中，除非项目创始
人得到了奖励，否则他将不再发出任何声音，来取悦投资人。
    总之，在我们进行战略设想的时候,我们应该记住Oracle宣讲上的一个简单的竞争游戏，明显矛头指
向Red Hat.自从Red Hat将JBoss收于麾下，对Oracle的中间件业务产生竞争局面后，Oracle明显在寻找
强硬的反应。虽然，很明显这对于在RedWood海岸将是一个漫长的战略思考问题，这不光是关于开源软件，
还是一个关于Oracle要进军操作系统领域的感觉，了解到Larry长期的规划，不仅仅停留在世界第二大软件
公司，是做第一。
    对于我们来说有什么意义呢？意义在于Oracle将对Linux进行长期的支持，这是一个好消息.如果这只是
一个倾销策略，那么就太可怕了，时间会证明一切。

我总是经常问,Spring这个名字到底是从何而来.
      名字要从2002年十一月说起了,我发表了一本书叫<Expert One-on-One J2EE Design and Development.>
书里附带了30000行的框架的代码,全年几乎我都把时间用在了写这本书上(完全靠自己写750页的书和开发一
个框架,太难了),很多基本的Spring框架的概念:具有IOC容器的功能,BeanFactory和ApplicationContext,并具有
DI(依赖注入)的复杂实现(虽然DI这个词是2003晚些时候才出现的),早期的SpringMVC是由控制器,HandlerMapping,
和Template,Jdbc template以及数据访问异常组成的.
     我不确定我能为代码做什么,我很高兴人们认为代码对他们有益,直接的或者对他们实现有指导作用的,我也不确定
我继续向一个开源的项目投入时间(已经几乎投入了一年的薪水),不过我还是渴望看到它能有最好的实现可能,我不可
能靠一个人的力量达到,当书出版之后,读者开始在Wrox的社区讨论代码,其中的两人Juergen Hoeller和Yann Caroff,
劝说我把代码作为开源项目的基础,然后一起推进.Juergen现在已经是Spring相关讨论的中心人物了,但是Spring社
区也不应该忘记Yann在最初对Spring成为开源项目的贡献.
      接下来呢,框架需要一个名字,书中所指的是Interface21框架,因为代码中用的是com.interface21 的包名,不过
这不是一个鼓舞社区的名字.幸运的是Yann给了一个建议"Spring"，他取名是来自于自然界（我2000年跋涉去
了珠峰基地），实际上Spring代表传统J2EE冬天的过去,我们认同了这个简单并优雅的名字,并马上同意了.
    Yann最终决定停止在开源项目的投入,转而去玩音乐,去过一种普通人的生活,Juergen当然一直对Spring进行
投入和推进,直到今天.过不了几个月,Spring的开发组要聚在一起,2003年六月,Spring也要跨出一大步,1.0版.

在应用服务器对Spring进行集成支持的主题方面,又有了新的消息.Oracle已经开始了增加产品Oracle Application Server对Spring集成的工作.
    和早前我们提到的Weblogic 8.1 以及 WebLogicJtaTransactionManager
一样,OC4JJtaTransactionManager在OC4J的环境中和JtaTransactionManager在
Weblogic的功用类似,提供如下好处:

    * 直接对事务管理和相关帮助类进行访问,无须JNDI查找.
  
    * 自动探测应用服务器版本,以获得不同版本中事物管理器的不同实现
    * 独立对事务进行控制:这是一个JTA没有提供但却非常有用的功能
    对JTA比较熟悉的话,你用UserTransaction,在JavaEE里编程对事务进行
控制,有些不能逾越的的沟壑,一个老旧的假设,当大约十年前J2EE开始构思的
时候,没有人想像不用EJB进行事务控制.
    问题是一些操作比如悬挂一个事务(比如,要求得到一个新的事务),只能用
TransactionManager.这个接口是JTA标准规范,不过不像UserTransaction一样,
它没有提供一个明白的JNDI访问或者其他什么方法获得.其他的,比如独立控制,
服务器提供详细的"事务命名"(为了方便监控或其他目的)在JTA中更是不可能做到.
    因为Spring提供一个丰富的,轻巧的事务抽象层,它包含了操控JTA以及其他API
的能力,所以你的代码不需要了解任何底层的架构,这样,为一些不希望公开的API
带来了更多的控制和更多效率.Spring支持声明性和程序性事务,所以你可以把事务
管理安排在POJOs中,而不需要知道其他.或者,事务是你的商业逻辑的一部分的话,你
可以使用比JTA更精炼的API,不需要JNDI,去处了冗长的代码.
    这些代码将要写入Spring的核心,发布为Spring2.0.3版本,感谢Oracle对Spring
持续的支持.Spring也在Fusion中间件服务器中有重要的作用,以及他们的SCA(Service
Component Architecture Partners)服务组件架构联盟策略.当然,Interface21仍旧是
SCA合作伙伴,我们与Oracle,BEA,IBM和其他的SCA成员一起为Spring继续工作.就像Oracle
SCA负责人Greg Pavlik去年的blog写的一样,Spring给应用带来的好处.
    "从一个JAVA编程人员的角度来看,一些有趣的新闻:一个Spring架构的系统可以直接

与SCA为基础架构的SOA环境直接无缝连接.Spring已经成为很多组织构建J2EE应用的事实
标准,我们以开放的姿态对SCA为基础的集成贡献力量.加上现在又有JAVA开发者的反馈,SCA的
使用不需要担心学习曲线和其他新的东西.只要有Spring,仅仅是POJOs,一切就搞定了.我
有许多问题关于JAVA编码和SCA的,Spring就是一个很好的答案."
    这提醒我:一些有趣的事情正在SCA联盟中发生,Adrian(为Interface21努力工作的员工)
或者我有时间应该发一个确切的更新文章.
    Oracl对HA还有更多深远的想法,这些确实是有趣的可能,特别是关于RAC,这是很多它的企
业客户经常用的.它们对Oracle技术和Spring的集成非常有兴趣,所以请把您的相反发在这里
或者联系Oracle,Oracle也在维护一个非常好的资源页,展示和Spring的集成。

非常幸运的，21世纪，已经有些成功和出众的开源项目取得了成功，但是，有趣的是，我们可以往回追溯一下，20世纪一个成功的商业巨擎的
经历，也许是开源产业的一个有指导意义的例子。
    沃尔玛的历史已经被大家广泛了解，第一个沃尔玛超市在阿肯瑟的Rogers,
于1962年开业。五年以后，沃尔玛在阿州开了24个超市.1968年，沃尔玛在阿州
之外的第一家店开业，渐渐地，在密苏里和俄克拉荷马州开店，当然了，这些
州都是阿肯瑟的相邻州。之后，沃尔玛一直以自己的家乡为中心展开，后勤保障
和文化差异慢慢被克服，使得它一直保持高效。不管沃尔玛在本土市场的成功多
么显著和巨大，大的地域性的拓展并不是总是成功的----比如说德国。
     开源产业也并没有很大不同。最重要的一点不同是，提供了有效的，低成本解决
方案的同时，并不依赖于地域。开源项目通常有发散的开发团队，它能够吸引不同
地域的人参与进来,那些人可能在伦敦，纽约，悉尼，班加罗尔，北京或者德黑兰
(这里提到的城市来自于Spring Framework的网站统计数据)
     创建一个社区是一个很棒的想法。然而，这是一个商业挑战。这相当于，一个
非常年轻的商业团体，在世界各个不同的地域有员工和股东。是一个巨大的管理负担。
第一批客户也可能分散在世界的某一处，并拥有不同的被允许的操作权限。基于开源项目
所展开的商业操作必须懂得他们操作范围。不过，很明确的是，我很肯定，开源产业
是比零售业有趣的多了的一件事情...

Sun最近在开始开源，用户也开始严肃地对待Sun的开源政策。
    GlassFish在开源的应用服务器中是一个迟迟来到者，不过好象
正在开始吸引众多的关注。重要的是，它确实很棒。很多interface21
的同事们，包括Costin和Juergen,都在一览GlassFish后树起了大拇指
(虽然我们还没把它引入产品)。从我听到的来说，性能是非常卓越的-
可能是由于引入了基于NIO的servelt引擎，还有JPA实现-Toplink Essentials-
基于Toplink引擎，也是性能卓越的。
    还有一个重要的事，举例来说，澳大利亚的酒店预定网站Wotif.com引入
了GlassFish,以我最近去澳大利亚的所见所闻来看，Wotif是一个和ebay，
lastminute.com一样的，广为人知的平台。
    自然，Wotif.com也用了Spring.我认为，能够让Sun在企业级JAVA中举足轻重，
很大范围上来讲，是因为它把当今世界上很多优秀的研究结果插入自己的主板，并
运行。
    Sun已经在GlassFish中的很多方面对Spring进行了更好的支持，值得关注的是
Web services栈。这很有趣，把web services做为GlassFish的一部分。
    GlassFish的开发者Kohsuke Kawaguchi最近在博客中谈到了Spring对JAX-WS的
支持。它写到了用Spring2.0 namespace处理机进行工作的过程，这非常酷。值得
注意的是JAX-WS namespace与Spring beans namespace一起的用法，允许Spring的
bean定义配置与JAX一同使用:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:ws= "http://jax-ws.dev.java.net/spring/core"
       xmlns:wss="http://jax-ws.dev.java.net/spring/servlet" …>
  <wss:bindings id="jax-ws.http">
    <wss:bindings>
      <wss:binding url="/stockQuote">
        <wss:service><!– nested bean is of course fine –>
          <ws:service impl="foo.MyService">
            <ws:handlers>
              <ref bean="myHandler" />
            </ws:handlers>
          </ws:service>
        </wss:service>
      </wss:binding>
    </wss:bindings>
  </wss:bindings>
  <bean id="myHandler" class="foo.MyHandler" />
</beans>
    这给了Spring远程调用的使用另一条路，Spring直接利用远程技术进行调用，
比Spring暴露的services接口更好，不过这也是很好的继承，方便使用。推测，
应该允许引入其他Spring配置文件来激活已经存在的bean定义。
    Kohsuke加了下面的有趣想法:
    "自从Spring的支持开始，将可以允许其他的JAX-WS扩展，举例来说我们能配置
JMS传送，或者JSON编码，等等"
    现在Web service可以直接调用Spring提供的:所有配置能力，声明服务以及企业
集成。
    这里有一个JAX-WS集成Spring的文档资料 http://jax-ws-commons.dev.java.net/
spring/.
    Spring的支持好象也得到了GlassFish社区的广泛好评。这在Spring社区里应该也
是很另人兴奋的，同时，你最喜欢的GlassFish集成入的功能是什么呢？一些功能被WebLogic
采用可能是一个好的开始，比如增强的事务管理和JMX/控制台集成.
    我们当然也在Spring2.0中做了很多JPA和Toplink Essentials以及GlassFish中的
JPA RI和持久化引擎的研究工作，Mike Keith,EJB3.0 的带头人，TopLink和通用ORM的领导
开发者，给了我们很多帮助，我们也感觉到了整个TopLink团队的积极配合。