J2EE会话外观模式与值对象

在J2EE项目设计与应用
代码耦合减少，网络流量减
有人说会话外观模式是一个
式应用中不使用会话外观模

中，会话外观是一种普遍使用的
少。总体上他给了客户端粗粒度
成功系统必备的设计方案，这是
式简直有点不可想象。

模式。它可以使得应用更分布式，
的访问，保护了服务器端的代码。
一点也不夸张。在一个成功的分布

　　会话外观不同于前端控
端联系时，尤其是与EJB交
器端耦合的作用，当然降低
合，与xml配合使用甚至可

制器，他有自己的应用领域，解
互时，会话外观起重要作用，会
的程度取决于会话外观的实现形
以解除耦合。

决不同的问题。在客户端与服务器
话外观可以起到降低客户端与服务
式。与值对象配合使用可以降低偶

　　下面我们举一简单的例
中，顾客转帐的例子。设想
储蓄帐号转到经常使用帐号
的钱，再次在经常使用增加
对存储帐户操作(SavingAcc
遵守的操作流程可以用如下

子来看看会话外观模式是怎样体
这样的情景：顾客在ATM对自己
。应用中，系统首先要核实客户
这部分钱。我们用三个EJB来表
ount EJB)和对经常帐户(Checki
的顺序图表示：

现这些优点的。考虑一个银行系统
的帐户做远程操作，把自己的钱从
的身份，然后从储蓄帐户消掉要转
示这核对帐户（Customer EJB）,
ngAccount EJB)操作，客户端应该

　　要理解上面的操作流程，需要首先
以理解工作原理，就是要理解这个框架的
务器端使用。比如对客户提供验证的操作
方方法实现类三个部分。推荐的命名方案
Customer,服务器方方法实现类则命名为C
为，要检验的是用户名、密码、开户帐号
他只需要是一个Stateless EJB，与具体
对象，实现并行对各种不同用户的核对，
EJB)和经常帐户EJB(CheckingAccount EJ
Bean,理由也类似。

理解EJB的工作原理。本质上EJB是一个框架结构，所
运行机理。在EJB中有三个部分，分别供客户端与服
的Customer EJB,他有本地接口，远程接口与服务器
是本地接口命名为CustomerHome,远程接口命名为
ustomerBean.在实现中，因为检验本身是一种抽象行
等系列信息，动作本身是与具体的客户无关的。所以
用户无关。这样，他完全可以在容器池中有多个实例
提高了访问速度。存储帐户EJB (SavingAccount
B)的没，命名规则类似，他们也是无状态的会话

　　客户端首先获得用户验证、然后可以
常帐目了。三个动作我们都用EJB实现。
CheckingAccound EJB做研究对象，看看
的响应，我们可以看到EJB的原理。客户
用，Home接口会有一个或多个Creat()方
实现中有个ejbCreateA()方法。这种互动
程接口，此例中就是CheckingAccount了
中会有一些方法的引用。客户通过这些方
在CheckingAccountBean中实现。上面的
不得不与远程交互两次。在核对阶段同样
如此。明白了操作过程与EJB原理后，我
陷：

在储蓄帐目下消去要求转帐额，再次就可以转储到经
客户端依次与三个EJB交互。我们选取
客户端是怎样与这个Bean交互的，从EJB对客户端做
端调用本地方法CheckingAccountHome获得对EJB的引
法。这个接口是与CheckingAccountBean互动的，在
由是通过容器实现的。Creat()方法返回的是一个远
，客户端就得到了对远程接口的引用了，在远程接口
法，对远程操作实现业务逻辑。这些方法的实现必须
过程我们已经看到，在获得对实现方法调用前客户端
要两次才能取得正确的认证，储蓄帐目的操作也同样
们分析上述客户端调用业务逻辑的方法至少有三点缺

　　首先，一点没有伸缩性。

　　其次，这种方法没有一直性的保证。

　　再次，业务逻辑直接暴露，安全让人担忧。

　　没有伸缩性是说客户不
逻辑就要求客户端直接与服
端又得重新增加多重调用。
的伸缩性能从这里体现。

得不对每个远程的EJB做调用。
务器端交互六次。要是有其他的
如果是不同的客户端有不同的方

上面我们看到一个简单的转帐业务
逻辑或者增加一个业务方法，客户
法，方法调用更是忙上加乱。不良

　　在整个转帐过程中，实际上只是一个
保证saving account和CheckingAccount
种保证是要求在客户端进行的。为了保证
包装在一个事务处理中。由于网络的不可
时间就自然拉长了，错误的可能性就自然

事务处理过程，要么转成功，要么不成功。所以必须
在一个事务处理中。但是在上述处理中，我们看到这
两个帐户的一致性，客户端必须把对两个EJB的调用
靠性，延迟和错误在这时很可能会发生，事务处理的
增加，死锁可能造成，一致性也就难以保证。

　　在注意到客户端对远程
端任意调用的方式直接导致
在检查EJB方法调用权限的
题推到部署阶段的方法是规
要寻求更安全的措施来解决

方法的调用，发现都是直接调用
服务器端毫无隐私，显然是方法
时候,EJB规范也定义了相应的角
范允许的。但是这不同于WEB应
问题。

。显然，这种方法直接暴露给客户
调用的安全处理所不允许的。当然
色和安全控制，虽然这种把安全问
用，对于商业性非常强的应用更是

　　为了克服这些缺陷，我
户端与业务方法之间加上一
可以获得所有防火墙的好处

们可以引入防火墙的概念——用
层Session bean，这样客户端与
，顺序图就如下所示了：

Session Façade模式在客
远程交互就多了一层“防火墙”，

　　在目前网络状况下，网
Session Façade模
问变成为本地访问。在计算
是同一的一次性调用，伸缩
包装了业务逻辑的所有方法
和安全性都有了保障——事
强了。在这个银行系统应用
是通过Session Faç
扩展的例子中会论述到。

络相对与计算机来说还是一个瓶
式后我们把六次或更多的网络连
机与容器的条件下，处理速度自
性可扩展性由此显现。更重要的
，并集中控制事务；业务方法也
务处理的严格要求转由服务器端
中我们使用方法transfer()来在
ade来传了，具体怎么传，在下

颈（bottleneck），在使用了
接减少到了一个。对业务方法的访
然比网络访问要快。不同的客户都
是，Session Façade Bean
不在直接暴露在客户端下，一致性
的容器来保证，无疑可靠性大大增
客户端与EJB之间传递数据，当然
面对Session Façade模式

　　总之，我们不用在每次传一个细粒度
复杂的业务逻辑方法也从暴露给客户端处
Façade Bean中，但是逻辑更独立

的方法调用了，可以一次传递所有参数给服务器端，
理成隐藏对客户不可见。复杂性虽然推到了Session
，耦合性更小了。

　　在实际的应用中，我们常常使用值对
EJB层之间传递、交换数据。一个值对象
是此银行系统中代替transfer()方法的值

象模式来代替transfer()方法。值对象在客户端与
实际上是一个包装了业务数据的序列化了的类，下面
对象：AccountTransferValueObject。

　　public class Account

TransferValueObject implemen

ts java.io.Serializable {

　　 private String customerPK;

　　 private String fromAccountPK;

　　 private String toAccountPK;

　　 private float amount;

　　 ...

　　 public String getCustomerPK(){

　　 return customerPK;

　　 }

　　 public String getFromAccountPK(){

　　 return fromAccountPK;

　　 }

　　 public String getToAccountPK(){

　　 return toAccountPK;

　　 }

　　 public float getTransferAmount(){

　　 return amount;

　　 }

　　 public void setCu

stomerPK(String customerPK){

　　 this.customerPK = customerPK;

　　 }

　　 public void setFromAccountPK(

String fromAccountPK){

　　 this.fromAccou

ntPK = fromAccountPK;

　　 }

　　 public void setTo

AccountPK(String toAccountPK

){

　　 this.toAccountPK = toAccountPK;

　　 }

　　 public void setTransferAmoun

t(float amount){

　　 this.amount = amount;

　　 }

　　有了值对象，客户端在
络发送到EJB层，经过Sessi
时，EJB层就会创建一个值
Façade Bean传递给

需要传递数据时候，就把所有的
on Facade Bean交给业务逻辑处
对象来包装业务方法需要传递的
客户端。

数据打包在值对象中，然后通过网
理。同样当业务逻辑与客户端交互
数据，通过Session