供职信息的确是一个反映技术流行的风向标。它们反映公司是否会花钱来从各种大肆宣传的技术中找到想要的实质，它们反映了开发人员收入的增益以及对相关技术的掌握程度(对技术来说永远是一个重要元素)，并且也为公司采纳某种市面上流行的技术栓上了保险。

Indeed.com是全球供职信息中的一个大站点，因此它的职位流利趋势图成为了一个非常重要的信息资源。它可以将过去发布过的职位数汇总，方便进行比较。

 有时候，技术的流行趋势往往充满戏剧性。在下图中，我们看到了到2007年11月之止，在Java职位列表中，Spring作为求职要求技能已经超过了EJB，到我昨天统计分别是：Spring 5710个职位，EJB 5030个职位。 通过工作总数的比较，我们可以看见两者走势的交叉点： 

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

很明了，市场EJB的需求在停滞或减少，而Spring在不断的增长。当然Spring和EJB并不是互斥的。使用Spring后并不会阻止你再去使用EJB，反之亦然。在你的Spring项目中，然后有许多EJB的服务是非常有用的。但光使用EJB而不使用Spring的话，就意味着放弃了众多有价值东西。的确，已经有EJB专家宣称两种技术本身就是直接的竞争关系。 Spring与EJB的融合是有意义而且也确实在增长，但相对于单单Spring本身，增长还是缓慢： 

这并不是一个随随便便的比较，考虑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水平是十分重要的。