这个源码级元数据的用法很简捷。因为与EJB规范中的假设正相反，事务性行为通常是业务模型最基本的部分。“应用程序装配者”角色与“bean开发者”角色之间的划分仅仅存在于EJB规范委员会的头脑中，我从未在真实的项目中看到过这样的角色划分。甚至可以说，这种划分是非常危险的，因为改变事务语义就从根本上改变了行为，而这是任何单元测试都无法测出的。另外，代码重构也不会破坏源码级元数据，这正是外部XML部署描述文件的一个重大缺陷。
所有这些都值得认真对待。可悲的是，J2EE社区没有对.NET投入应有的关注。证据？如果有人傻到在TheServerside.com或是其它 J2EE门户网站中发表与J2EE相关的.NET新闻，立即就会骂声四起——而且全都是毫无价值的老调重弹。幸运的是，J2EE社区中一些重要的推动者们显示了出一种开明的态度，他们愿意采用一些.NET所开创的、有价值的特性，例如：
Ø Java 1.5将为Java添加源码级元数据，以及C#风格的“自动装箱”（autoboxing，简单数据类型和对象之间的转换）功能。
Ø JBoss 4采用了.NET风格的元数据来驱动企业服务。
Ø Spring和其它AOP框架（除了JBoss AOP之外）也使用了源码级元数据。
Ø 甚至EJB 3.0也有可能采用源码级元数据来描述目前保存在XML EJB部署描述文件中的信息。
Web Service
在EJB 1.0和EJB 1.1的年代，除了Java自己的RMI/RMP（那还是一种相当底层的技术）之外，重要的分布式对象技术就只有CORBA和COM/DCOM了——这两种技术都很复杂，都没有被业界大量采用。相比之下，EJB更加简单、概念更加一致，因此它成功地在很多系统中引入了分布式对象——甚至是那些根本不需要对象分布的地方。
如今，情况已经大不相同了。基于XML的web service提供了比过去大得多的开放性。这是真正的互操作，不仅仅是在微软技术和基于Java的解决方案之间，还可以在Perl、Tuxedo、以及其他很多语言和系统之间实现互操作。
同时，越来越多的人认识到：分布式对象的使用仅仅在少数应用中才是适合的。因此，快速增长的领域是在异构平台之间的互操作性，而不是J2EE应用服务器之间的远程调用。
EJB的另一个大问题在于：它总是试图把组件模型和远程支持放到同一个标准中，这样做有两个大问题：同时处理组件模型和远端支持增加了复杂性；而且远程协议还在不断发展。EJB规范最早3个版本希望将Java RMI（或者说，至少是RMI over IIOP）作为一个标准的远程协议，这种想法现在看起来非常可疑。随着更多远程协议的发展，EJB容器不可能支持所有的协议，而EJB又没有提供“可插入”的远程机制。
我喜欢的是一个更加模块化的方法：将“远程调用”看作一种服务，可以在对象模型之上通过façade将其暴露出来，就好像web界面就是业务对象之上的一个façade。
敏捷方法学的兴起
最后，自从EJB在1998年诞生之后，开发过程和最佳实践的思想发生了重大变化。可能最重要的事件就是“敏捷”方法学的兴起，例如极限编程（eXtreme Programming，XP）。
尤其值得一提的是，测试先行的开发（test first development），或者至少是严格的单元测试，其价值在在很多项目中得到了证实。而EJB使得有效的单元测试非常困难，因为EJB严重依赖容器的服务。因此这就意味着EJB使得敏捷开发过程难以被应用。
从未出现的组件市场
我们对EJB的失望还在于它没能成功地创造一个第三方组件市场，而这是其承诺的主要愿景之一——还记得EJB规范所设想的、将多个厂商提供的EJB“组装”起来构成应用程序的情况吗？
这个组件市场并没有出现，它是否真的会出现也很值得怀疑。之所以这样，一部分是因为EJB的模型（它的可移植性有缺陷，部署也过于复杂），然而更重要的是：企业组件太过复杂，有太多的依赖关系需要包装。在实际工作中，那种所谓“可复用”的第三方EJB组件其实很少，而且我看到的几个例子也具有非常大的依赖性——例如，依赖一个精心设计的数据库schema和专有的数据库特性，或是依赖某种特定J2EE应用服务器的专有特性。这种依赖性使构想中的 “J2EE组件市场”很成问题。过去也曾经有过成功的组件市场，例如ActiveX控件和（在一个较小范围内）JavaBean组件。然而这些组件所面对的问题要比企业级应用简单得多。
