【翻译】深入浅出 EJB3.1（上）
终于有空将EJB3.1的最新文章与大家分享，原文请看：
http://www.theserverside.com/tt/articles/article.tss?l=EJB3-1Maturity
?
已经更新：【翻译】深入浅出 EJB3.1（下）
?
?
?
引言
?
?
Enterprise Java Beans(简称EJB)是Java Enterprise Edition(简称Java EE)平台上的服务端组件架构模型，目标极力于快速并简化分布式，事务处理，安全以及便携式的应用程序。
?
EJB在其2.*时代也叱诧风云过，由于能够解决许多企业应用程序的需求而被广泛采纳。但这只是EJB成功的表象，越来越多的质疑声开始抨击EJB的复杂。“缺乏好的持久层策略，又臭又长的布署描述符，能力有限的单元测试”等等这些常用却又不好用的技术导致了大量开发人员开始寻找新的“轮子”。
?
Sun的反应的确有些迟钝，但还是它花费大量精力来修订规范，使得EJB得到很大的改观。EJB3摈弃了许多现有的缺点，呈现给开发人员的解决方案在社区中大受好评。EJB又一次变成了切实可行的解决方案，并且现在已经有许多放弃它的团队，再次接收EJB。
?
虽然它成功了，但EJB3还没有当初预计的那么理想。反观EJB2.1，新规范要面对两个主要的挑战：
?
?
对于EJB，优先考虑的就是全部重建。“我们只有先清空杯子里的水，才能接纳新的东西”。现在杯子已经清空了，这对我们来说是非常有利的，而且还可以没有包袱的大胆前进。
?
EJB3.1 又一次引入了一系列新的特性，倾向于挖掘技术的潜力。依我来看，EJB3.1绝对是一个重要的发布版本，它将那些长期让人渴望的特性带到开发者面前，更加能够满足最新的企业应用程序开发，同时对EJB再次被人们采纳将做出巨大的贡献。
?
近期，EJB 3.1提议最终草案已经发布了，现在我们已经非常接近最终发行版了。本文会贯穿大多数新的特性，对每一个新特性都有会有一定程度的介绍。
?
?
?
No-Interface View(非接口视图)?
EJB3.1引入了no-interface view的概念——将一个bean的所有的public method通过一个Local View暴露出来。(具体访问可见参见本文后面的Global JNDI names)Session Beans并不强迫你再去实现任何接口。EJB容器提供一个指向no-interface view的引用实现，允许客户端调用该bean的任何public method，并且no-interface view也可以确保事务，安全以及拦截的行为与原先的用法一致。
?
通过non-interface view，所有bean的public method(当然也包括定义在其父类上的public method)都是可用的。一个客户端可以通过依赖注入或JNDI lookup得到该view的引用，用起来感觉就好像它是local或remote的view一样。
?
但与local和remote的view不同的是，local和remote的view必须与其所实现的的业务接口同时存在，而no-interface view的引用则只是bean这个类本身。注意，no-interface view不再依赖于接口。
?
下面的代码样例说明了一个servlet使用no-interface view是一件多么容易事啊。这个被引用的no-interface view叫作ByeEJB，其实就是一个普普通通的JavaBean。该EJB并未实现任何接口，也没有提供什么多余的布署描述符。
?
?
?
实际上如果引用类型为java类而不是接口的话，还是有些硬性的限制条件：
?
?
?
?
?
如果bean没有暴露任何local或remote view，则容器必须默认提供一个可用的no-interface view。如果bean提供了至少一个local或remote view，则窗口不会提供no-interface view(除非使用@LocalBean显式要求提供).
?
?
Bean和其父类的所有public method都会通过no-interface view被暴露出来。这也意味着任何public callback method也会暴露出来，因此在使用的时候要注意这一点。
?
本特性避免了接口的编写，简化了程序的开发（实际上并不是所有的类都需要接口）。也许在不久的将来还会加入remote no-interface view。
?
?
?
Singleton
?
?
大多数的应用程序都有过至少需要一个singleton bean(对每个应用程序来说，它意味着只需要初始化一次)的经历。许多供应商已经满足了这方面的需求，通过使用描述布署符来限定一个bean所允许的最大实例数量。供应商这种“各自为政”的方式破坏了JAVA到处宣扬的“一次编写，到处布署”的口号，因此迫切的再推出一套类似特性的规范来很有必要。EJB 3.1最终还是引入了singleton session beans。
?
现在主流的session beans有三类——stateless，stateful 和 singleton。Singleton session beans可通过使用Singleton Annotation来标注，然后每个应用程序会确保只实例化一次。Singleton session beans支持与客户端共享，当然也支持并发访问(后面有会具体谈到)。
?
singleton bean的生命周期始于容器下列任意初始化阶段：
?
?
缺省情况下，容器有义务决定singleton bean何时被创建(比如在spring中，默认是将所有的singleton在启动时就初始化)，但是也允许开发人员使用Startup annotation在应用程序启动时，要求容器去对singleton进行初始化。此外，Startup annotation还允许你去定义singleton beans之间的依赖关系。当容器开始处理任何客户端发过来的请示时，所有标注有startup的singletons都必须初始化完成。
?
下面的代码样例大致演示了依赖是如何实现的。singleton A的没有使用@Startup也没有别的singleton依赖于它，于是A的实例化由容器来决定(说白了，此时A的实例化由具体EJB实现来决定，规范没有硬性规定)。singleton B在应用程序启动过程中被实例化，但必须早于singleton D和singleton E(很明显，没有B的实例，C和D可能都无法正常初始化)。即使这个时候的B没有使用@Startup，但由于有其它的singletons依赖于它，它还是要先实例化的。singleton C由于使用了@Startup，它会在应用程序启动过程中被实例化，但必须比singleton E先完成。同理D也必须在E之前完成实例化。因此，E是应用程序中会最后一个被初始化。(注意，再重申一下A是否会初始化与供应商的实现有关，也许供应商的实现是预先加载，也许是延迟加载，但当你真正使用A的时候，肯定会保证被初始化了。)
?
?
??
?
有一点需要注意的是，如果一个bean依赖于多个bean的注入，那么这些被依赖的beans之间的初始化时机是不确定的。E依赖于C和D，并没有说C一定要在D之前被实例化，除非D本身也是依赖于C的。
?
singleton可以@Startup定义依赖于现存其它模块中的singletons。
?
当应用程序关闭时，容器有义务执行singletons的PreDestory回调，将所有的singletons全部销毁。这个时候，启动时候的依赖关系在销毁时变得有意义了，比如说A依赖于B，当A被销毁时，B还是存活的，刚好与初始化相反。
?
Singleton bean会维护服务端与客户端调用而产生的状态，但当应用程序关闭或容器挂掉时，该状态并不会保存下来。(大家一定想到这种情况如果使用序列化机制将状态保存下来，然后当程序再次启动时，再反序列化还原状态也是一种选择。不过，至于你singleton中装的是什么内容，是否需要被序列化，是否可以被序列化对容器来说还是未知数，所以干脆挂就挂吧。) 为了处理服务端与客户端的并发调用问题，开发人员必须定义一个并发策略。规范中定义了两种方式：
?
?
?
(呵呵，这不正是声明式与编程式的又一次实践吗?)
?
大多数情况下，CMC肯定是首选。容器的管理并发问题时，还是使用“Lock (锁)”。每个方法都关联上一个read lock和write lock。Read lock表示应该方法可以尽可能的被多个线程并发调用，而write lock表示该方法在每次只能每一个线程访问。
?
缺省情况下，lock的属性值是write。当然你可以通过使用@Lock来修改默认属性值。@Lock可以用于类，接口和方法。如其它Annotation类似，@Lock也有继承性。在类级别使用@Lock，它的所有相关方法也会被应用上，除非你单独限制某一个具体的方法。
?
当某个方法持有 write lock时，容器只允许其中一个并发线程去调用该方法。其它线程并必须等待，直到该方法再次变得可用。客户端的等待也许是无限期的，这个时候可以使用@ AccessTimeout来指定一个最大等待时间。如果超时了，会抛出ConcurrentAccessTimeoutException异常。
?
下面的代码示例中演示了如果使用CMC。Singleton A明确指定为CMC(尽管这么没有必要，因为默认就是CMC，主要还是为了演示)。Singleton B并未定义任何并发策略，但按照规范，它还是属性CMC范畴，它的所有方法显示指定CMC使用 write lock方式。Singleton C与Singleton B几乎一模一样，只是使用的是read lock方式。Singleton D和Singleton C一样，但是D中的sayBye方法重新定义为 write lock。Singleton E总要是演示@AccessTimeout的使用，当有因等待E中某方法而被阻塞的客户端超过10秒时，就会招出ConcurrentAccessTimeoutException异常。
?
?
?
如果是在集群环境下，当应用程序布署在不同的JVM上，则每个JVM都有该singleton的一个实例。?
直到EJB 3，任何由EJB抛出系统异常都会导致实例被废弃和销毁。但这个原则并不适用于singleton beans——它们必须一直存活下来，至少应用程关闭时才销毁。因此任何在业务对像方法或回调抛出系统异常时，业务对象并不会被销毁。
?
与 stateless beans一样，singletons也可以暴露成web services。
?
?
?
Asynchronous Invocations(异步调用)
?
?
?
