EJB3，我们究竟得到了什么 （3）

<三>各类声明

       EJB3可以在容器外运行，这不是谣言，但也绝对不是真理。当我们只用Entity Bean我们可以不用容器，就象开发Hibernate的应用一样，我们可以使用Entity Manager（类似hibernate的Session)来开启关闭一个交易。这是所谓的容器外交易，或者称作为应用管理交易。EJB的容器管理交易中，不管是BMT还是CMT，事实上用到的是那个笨重的JTA。通常情况下，我们宣称JTA是杀鸡用的牛刀，因为没有分布，没有多数据库。但，我们遭遇有分布有多数据库的情形时，牛刀不可少也。EJB3的CMT支持，除了给我们用annotation来声明交易类型之外，没有什么太大的变动，对于BMT，我们可以注射Context object来使用UserTransaction等，但是一个结构师可能会跳出来阻止你用BMT因为Context这个玩意儿使得EJB紧耦合了它的容器。我说，当我们需要手动处理交易rollback时候，最好不要理会一些不拉图式的概念。在JAVA世界里，我们的大脑被太多的概念玩弄着，一些概念确有建设意义，但是大部分的概念目前为止只能作为精神领域的娱乐。譬如耦合，我们所追求的松耦合的极致是Seperate concern,我们要求接口组件的粒度尽可能的粗，使得层与层之间结合点尽可能的小，但是不管怎么样，层次之间还是耦合的事实不能被否认，就象SB,MDB会耦合容器一样，我们只能在松紧的程度上来获益相应的维护性，移植性。与那些抽象的概念相比，从实践来的经验和规则更能使我们得意，Ted Neward 75条j2ee开发准则是公认的从good开发者到great开发者的分水岭。

       这里只讲EJB3提供的在EJB Tier上的声明性安全机制，除了声明的方式变成Annotation外没有什么变化。例如声明一个函数权限，只需要在函数上加上 @RollesAllowed("rollname")或者@PermitAll,非常的简单直观。例如，可以在Bean的头上放 @DeclareRolls来代替DD中的security-role-ref项，等等。在安全身份传递方面，仍然是通过 getCallerPrincipal和isCallerInRole来获取Caller的安全上下文的信息，这里注射SessionContext不可避免。

      到这里，我们看到EJB有出色的声明性交易管理，声明性安全管理。但是，仍然遗漏了在Web应用中最让人头大，但又不可避免的非持久状态管理。对远程服务来讲，fat客户端保存相关不持久信息不成问题，而对thin客户端，通常会把这些信息塞在Http Session里，或者用SFSB。这里有两个极端的做法，首先是什么都SFSB来，似乎SB让人觉得更安全，其实它的代价是额外SFSB pool管理的消耗，而状态的生命周期不见得和Http Session保存的有什么两样，可能Http session更快一点。至此又出了另一个极端做法，把什么都放http session中，这样做完全是在虐待内存，并严重降低应用扩展性。我们有个文雅的称呼来数落它:Overstuffed Session Antipattern。管理好状态无非是，把短期状态放Http Session，长期状态交SFSB，并且时刻记着用好了的状态要清除。JBoss Seam提供一个J2EE不曾有的声明性状态管理，它在Servlet提供的上下文基础上又提供了几个上下文，比较醒目的是用在长交易下的对话上下文，并用Annotation @In @Out 和Session交互。我一开始被他别出心裁的名词 "Biinjection"唬住了，一个既能从上下文注射，又能注射回上下文的新概念！其实后来，我发现把它翻译成大白话就是，Session的get和 set。