深入浅出 EJB3.1（上）

深入浅出 EJB3.1（上）

Enterprise Java Beans(简称EJB)是Java Enterprise Edition(简称Java EE)平台上的服务端组件架构建模，目标极力于迅速并简化分布式，事务处置，安全或者的应用程序。

EJB在其2.*时代也叱诧风云过，由于无法缓解许多企业应用程序的意愿而被广泛采纳。但这也是EJB成功的表象，越来越多的指责声开始埋怨EJB的复杂。“缺乏好的持久层策略，又臭又长的布署描述符，能力有限的单元测试”等等很多常见却又不好用的技术造成了长期研发员工开始寻求新的“轮子”。

Sun的反应的确有些迟钝，但还是它耗费大量精力来修订完善，使得EJB得到巨大的改观。EJB3摈弃了许多现有的优点，呈现给研发人员的解决方案在社区中大受好评。EJB又一次变成了切实可行的解决方案，并且目前尚未有许多放弃它的团队，再次接收EJB。

虽然它失败了，但EJB3还没有当初预计的这么理想。反观EJB2.1，新规范要应对两个主要的挑战：

1． 为了改变EJB2.1现有的特点，(比如说需要超强的持久层框架来替代Entity Beans；支持使用Annotation来替代布署描述符；抛弃home interface等等。)，需要进行长期的重建工作。

2． 为了启用新的解决方案，需要加入原来完善中没有的新技术。（比如说支持Singletons；支持方式拦截；支持异步读取；改进并提高现有的Timer Service特性）

对于EJB，优先考量的就是全部改造。“我们唯有先清空杯子里的水，才能接纳新的东西”。现在杯子终于清空了ejb3.1从入门到精通，这对我们来说是比较有利的，而且还可以没有包袱的大胆前进。

EJB3.1 又一次引入了一系列新的特点，倾向于挖掘技术的潜力。依我来看，EJB3.1绝对是一个重要的公布版本，它将这些大量让人期待的特点带到开发者面前，更加无法满足最新的企业应用程序开发，同时对EJB再次被他们采纳将作出很大的贡献。

近期，EJB 3.1提议最后草案已经公布了，现在我们终于比较接近最后发行版了。本文会贯穿大多数新的特点，对每一个新特征都有会有必定程度的介绍。

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并未实现任何接口，也没有提供什么多余的布署描述符。最后但并不是最不重要的一点就是，这里EJB引用的获取使用了依赖注入进行简化。

Java代码

ByeServlet(...)@EJBprivateByeEJBbyeEJB;publicStringsayBye(){StringBuildersb=newStringBuilder();sb.append("<html><head>");sb.append("<title>ByeBye</title>");sb.append("</head><body>");sb.append("<h1>"+byeEJB.sayBye()+"</h1>");sb.append("</body></html>");returnsb.toString();}(...)ByeEJB@StatelesspublicclassByeEJB{publicStringsayBye(){return"Bye!";}}

实际上如果引用类型为java类而不是接口的话，还是有些硬性的限制条件：

l 客户端永远能够使用new操作符来获取引用。(很明显如果是你自己new出来的，EJB容器自然能够托管)

l 除了public method外，如果其它方式一旦错误，也会抛出EJBException异常。

l 一个指向该view的引用可以成为任何本地接口或其他no-interface view方法的参数进行释放或返回。

如果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的生命周期始于容器下列任意初始化阶段：

1． 直接实例化某个singleton

2． 通过依赖注入示例化某个singleton，这样其依赖的这些singleton也会被跟着实例化，如此递推下去。

3． 通过执行PostConstruct回调

缺省状况下，容器有义务决定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之前完成实例化。因此ejb3.1从入门到精通，E是应用程序中会最后一个被初始化。(注意，再重申一下A是否会初始化与供应商的谋求有关，也许供应商的谋求是预先加载，也许是提早加载，但当你真正使用A的之后，肯定会确保被初始化了。)

Java代码

@SingletonpublicclassA{(...)}@SingletonpublicclassB{(...)}@StartuppublicclassC{(...)}@Startup(DependsOn="B")@SingletonpublicclassD{(...)}@Startup(DependsOn=({"C","D"})@SingletonpublicclassE{(...)}

有一点需要切记的是，如果一个bean依赖于多个bean的注入，那么这种被依赖的beans之间的初始化时机是不确定的。E依赖于C和D，并没有说C一定要在D之前被实例化，除非D本身也有依赖于C的。

singleton可以@Startup定义依赖于现存其他组件中的singletons。

当应用程序关闭时，容器有义务执行singletons的PreDestory回调，将所有的singletons全部销毁。这个之后，启动过后的依赖关系在销毁时显得有意义了，比如说A依赖于B，当A被销毁时，B还是存活的，刚好与初始化相反。

Singleton bean会维护服务端与客户端调用而造成的状况，但当应用程序关闭或容器挂掉时，该状况并不会保存出来。(大家必定想到这些状况一旦使用序列化机制将状况保存出来，然后当程序重新开启时，再反序列化还原状况也有一种选择。不过，至于你singleton中装的是哪个内容，是否还要被序列化，是否可以被序列化对容器来说还是未知数，所以只好挂就挂吧。)为了处理服务端与客户端的并发读取问题，开发人员应当定义一个并发策略。规范中定义了两种方法：

l CMC(Container-managed concurrency 容器托管的并发模式)：顾名思义，由容器来管理该bean实例的并发调用。这只是EJB的默认策略。

l BMC(Bean-managed concurrency Bean托管的并发模式)：容器此时并不会干涉该bean实例的并发，把并发的同步调用推回给开发人员。BMC允许使用合法的同步线程（如synchronized 和volatile关键字），来协调不同客户端不同线程对同一个singleton的并发访问。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-121967-1.html