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。
阅读更多
个人分类: EJB3/J2EE1.5
上一篇EJB3,我们究竟得到了什么 (2)
下一篇EJB3,我们究竟得到了什么 (4)
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭