[摘要]EJB技术正在像其他辉煌过的技术一样走到了一个关口。2000年以前这项技术充满了传奇色彩，被大批企业不假思索地接受。然而理想毕竟是理想，经过了几年的发展，今天这项技术却正在被怀疑或者至少说让技术人员犹豫不决，现实的是J2EE的对手出来了，.NET似乎又有着后发的技术优势。大部分的探讨和争论已经开始...
EJB技术正在像其他辉煌过的技术一样走到了一个关口。2000年以前这项技术充满了传奇色彩，被大批企业不假思索地接受。然而理想毕竟是理想，经过了几年的发展，今天这项技术却正在被怀疑或者至少说让技术人员犹豫不决，现实的是J2EE的对手出来了，.NET似乎又有着后发的技术优势。大部分的探讨和争论已经开始转向这两个体系结构的对比。Java阵营内部同样发出了怀疑的声音，最直接的就是对EJB的攻击，因为人们发现原来这项技术所做的承诺似乎都走向了相反的方向
1．大量的案例由于采用了这种技术反而使得系统开发日趋复杂，而不是想像的简化开发周期加长成了家常便饭，实现一个进销存就把很多人难倒。
2． EJB成了昂贵的代名词，而不是期望的成本降低
3． 废了半天劲还不如用消息传递进行系统互操作
4． 最终发现彻底地摆脱平台是不可能的
但是Java总归还是不错的，于是有了Spring等等N种体系。EJB开始让人们困惑。任何技术和人生一样有它的困惑期，但是EJB给人们的困惑尤为经典，更具意义。J2EE和其他体系的对比已经泛滥于网上，实际应用的经验也随处可见，以至于不需要这里介绍，但是EJB现在并未被单独地被重视这是应该值得注意的，这与J2EE发展史却是背道而驰的。必须承认这么一个事实，EJB是被单独提出和定义的，最早是完全单独的一种规范，这与所谓体系结构并没有直接的关系，或者说EJB的意义和目标绝不只是在J2EE内封装商业逻辑，所以过于在框架内讨论EJB，或者说认为J2EE的弱点一定要蔓延到EJB上是否合适是值得探讨的。
EJB诞生的初期人们的兴奋关键在于这种模型吸收了以往组件技术的精华，并有很大发展，使人们看到了强健的商业组件制造成本降低的期望，特别是跨越平台的可装配性和移植性，这是软件工程界一直的梦想，因为这意味着企业端计算程序设计工业化和细致分工也许要成为可能。这种思想目前也影响了界面一级的应用，例如所谓的Portlet技术，IBM公司的WebSphere平台的技术也许不是可怕的，但是有几十个合作伙伴事实上给它提供了类似的合作，这才真正是让对手感到害怕的。因此我们谈论EJB的时候，谈论它的价值和作用，脱离了它的设计目标也就失去了更大的意义，以下的商业环境和软件技术瓶颈应该重新被审视：
1． 软件工程就重用领域来讲是否超越了组件时代，或者说已经不需要组件了？
2． 软件的重用是否只需要互调用而不需要重复装配，乃至装配到不同的部位？
3． 商业逻辑是否仍然需要封装，并保持强健的特性，不间断地服务
4． 组件和强健和可用性是互联特性能取代的吗？
5． 是否有更廉价的组件形式超越EJB并同样获得众多的支持？
6． .NET的组件标准和EJB是否有可比性，或者说什么组件形式和EJB才有可比性？
当冷静地思考的时候就知道，技术不应该被当作明星吹捧，但同样也没有容易倒下的软件技术。EJB不成熟，但不等于可以轻易被否定。是EJB使得很多普通的程序员能够介入原来贵族似的组件开发，甚至是简单的Windows上面开发UNIX上的组件，EJB的历史问题大多数在于将这种技术错误地滥用：一个浏览人数少的可怜广告浏览程序也要用组件，对于一个只想简单算出库存的客户设计了所谓N年后才需要的扩展性。同样现实中在这一技术擅长的领域，至少目前还无法找到更强大的竞争者。技术选择是应用型的技术人员永恒的主题，类似的困惑会不断的出现，最重要的是认同它们的理想和目标，保持对它们客观清醒的认识。放到擅长的领域的技术才是最优美的，这和人生没有什么两样。
……