Rod Johnson：Spring供职信息已超过EJB,JavaEE 继续 without EJB

?

?

?

通过EJB走势来看，假设EJB职位大多数都是为了解决遗留EJB的话，那么几乎没有新项目用EJB了。?再来看一幅关于比较两者的各自增长的图表显得更有意义，两者形成鲜明的对比：?

?

?

?

?

这并不是一个随随便便的比较，考虑Spring或EJB其中任何一个作为企业级Java应用程序开发的核心组件是合理的。此时此刻，谁更处于上风也是显而易见的。

在某种程度上，必须承认这满足了我个人的虚荣心，因为早在2003年我就预言EJB将死，并且大声嚷到EJB正在被过度的滥用。在《J2EE without EJB》一书中，我就分析了EJB模型的不足，以及它是如何达不到开发人员和客户的预期目标或需求。那个时候，我的这些言论颇据争议。EJB3.0稍微有点改观，但也改变的太少并且太晚了。注入依赖功能与实现需求相比还是太弱了；Interception API被认为有必要解决横切问题(AOP)，可EJB却弄了个功能最少，最笨重还容易发现错误的解决方案；还要考虑与毫不相关的先前EJB版本兼容问题；完整的EJB合同还是有好几百页，复杂的运行以及高昂的花销，与其所谓的“简单编程模型”形成强烈对比；尽管有新的语法糖，但还有很多地方设计不足，比如：actions的启动,singletons与陈旧的线程模型(threading model)；最后，还是与某一特定的应用服务器绑定在一起，“一次编写，到处调试”。?

我本可以继续抨击这些缺点，但这些职位数替我表明了许许多多公司真正所要想的技术经验以及会招收什么样人的结论。?

现在我想稍微谈谈session和message bean。JPA从EJB中分离了出来的规范，采用了现今主流技术，证明了它存在的价值。?

对于个别的开发人员来说，EJB的过气意味着什么？

实际上大量优秀的技术都是导致EJB过气的原因。到今天已经很难强加人们去用一个未被证明可以解决实际问题方案来开发J2EE了，这确实是一件好事。也不要盲目的拒绝所有的标准。正如我一直强调:JavaEE包括EJB，任何关于于该平台的人都应该从总体上中肯的看待它。有了更好的技术，业务对象成为了POJO，依赖于特定规范的组件模型将会减少并且也越来越不重要。放弃EJB，架构将更加灵活，当需求改变时通过当今崛起的SOA或其它热门技术来解决。而且现在乐意采用轻量级布署平台的公司也越来越多。尽管如此，支持EJB3.0的成熟应用服务器还是很多的（包括Spring2.5在内，内置了EJB3.0注入依赖模型。还和BEA共同开发了Pitchfork，专门为WebLogic10’s EJB3.0所实现的）。?

坦率的说，EJB是失败的。EJB在过去的10年无法解决问题；现在它，乃至将来仍然有很多不合理的地方。很多当时EJB的种种美好假设到如今都是不可信的。EJB的规范坚持主张向后兼容是没有道理的，它的衰亡是完全符合因果关系的，当我们正朝向一个崭新，更加灵活的世界，OSGi以及所谓“初级的”Servlet API提供的却是更加有益的。当然，使用EJB的绝对总数还是很多，因此EJB并不会很快完全的消亡。但走势图已经摆明了它注定要成为历史。

Spring职位信息超过EJB发生在我们宣布SpringSource的Spring认证之前。如今，Spring已经作为求职技能中炙手可热的重要技能，因此对于雇主与开发人员来说，权威的衡量开发人员的Spring水平是十分重要的。?

为了更进一步证明Spring势不可挡，我们统计了一些2007年主要的Java站点数据。其中，在ServerSide里，前5名中有2个是关于Spring的，并且排在No.1的是“Introduction to the Spring Framework”。（注：还有一篇是Introduction to the Spring Framework 2.5 ）。在InfoQ上，前10名的有3篇是关于Spring的，排名第一的是“更新到Spring2.0”。