J2EE体系架构设计介绍(3) 值对象、传输对象、截取过滤器
7、值对象或传输对象
值对象(value object)模式通过减少分布式通信的消息而促进数据的交换，通常这里所指的通信是在Web层和EJB层之间。在一个远程调用中，一个单一值对象可以被用来取出一系列相关数据并提供给客户。
这种设计模式的出现是基于客户需要与ejb大量地交换数据的情况。具体来说，在J2EE平台中，应用系统通常将服务器端的程序组件实现为会话bean和实体bean，而这些组件的部分方法则需要将数据返回给客户；这种情况下，通常一个用户会重复调用相关方法多次，直到它得到相关信息，应该注意的是，多数情况这些方法调用的目的都是为了取得单一的信息，例如用户名或者用户地址等。
显而易见，在J2EE平台上，这种调用基本上都是来自远程的。也就是说，用户多次调用相应的方法会给Web带来极大的负担，即使用户和EJB容器加载相同的JVM、OS和计算机上运行EJB程序，由于方法调用被缺省地认为是远程任务，所以这种问题依然存在。
由于以上所提到的问题，在远程方法的调用次数增加的时候，相关的应用程序性能将会有很大的下降，因此利用多次方法调用而取得单一的信息是非常低效的；在这种情况，J2EE的研究人员建议使用传输对象来包含所有的程序数据，即每次方法调用可以发送和接收这个传输对象；当用户向EJB发出对于程序数据的请求时，EJB会创建这个传输对象，将它的各个域赋以相关的数值，并将整个对象传送给用户。
当EJB使用传输对象的时候，用户可以通过仅仅一次方法调用来取得整个对象，而不是使用多次方法调用以得到对象中每个域的数值；由于传输对象是通过值传递而交送给用户的，所以所有对于该传输对象的调用或取值都是本地调用，而不是远程方法调用。不过需要注意的是，这个传输对象必须具有对应于每个属性的访问方法，或者将所有属性都设为公共的。
类图13表示了传输对象模式的体系结构。
图13 传输对象类图
在图13中，传输对象首先在EJB中创建，然后返回给远程客户；当然，传输对象也可以根据需要融合其他的设计模式。
图14显示了传输对象模式中的参与模块和它们之间的交互。
图14 传输对象序列图
下面我们说明一下传输对象模式的各个参与模块：
(1)客户(Client)。客户代表了EJB所提供服务的使用者，通常是运行于用户终端的应用程序。
(2)业务对象。业务对象表示在一个模式中由会话bean、实体bean或数据访问对象(Data Access Object)实现的角色。业务对象通常负责创建传输对象，并根据请求将其传送到相关的用户；业务对象也可以从用户中取得一个传输对象格式的数据，并应用这些数据来执行一些更新。
(3)传输对象。传输对象是一个可序列化的Java对象。在这个对象的类中，通常会有一个包含所有域的构造函数，用来创建这个传输对象。
这个传输对象中的成员变量基本都被定义为公共，从而无需为它们提供相关的访问方法。当然如果存在一定安全的需要，相关的成员变量也可以设为保护或私有，并且给定各自的访问方法。由此可见，传输对象的设计是随着应用系统的需要不同而改变的，是否将对象中的成员变量设为公共，或提供一定的访问方法，将是一个很重要的设计问题。
通常在实现这个模式时，最多采取的是可更新的传输对象策略和多传输对象策略。 在可更新的传输对象策略中，传输对象不仅可以从服务于用户的业务对象中取得相关信息和数据，还可以从业务对象中得到用户对于数据所需要进行的改变。 图15以类图表的形式表明了业务对象和传输对象之间的关系。
图15 可更新传输对象类图
业务对象创建了传输对象。而用户通过访问业务对象，既得到了所需的信息，也对相关数据做出了一定的修改；为了能够使得用户可以修改业务对象各个域的取值，这个对象必须提供一定的变值方法，而出于对Web负担的考虑，业务对象所提供的方法最好以传输对象为参数。相应地，这些方法可以去调用传输对象所提供的方法，来设置传输对象的各个成员变量的取值；同时在传输对象的方法中，我们也可以植入数据验证和完整性检查的逻辑，这样在用户从业务对象的方法得到传输对象时，可以直接调用传输对象的成员方法进行本地数据访问，当然这种本地数据访问不会影响到业务对象。
当用户调用业务对象的变值方法时，该方法会将用户端的传输对象序列化，再将它发送给业务对象；业务对象接收到更新的传输对象，便将这些更新写回到自己的对象拷贝中去； 这里需要说明的是，上面提到的写回只是涉及到被更新的变量，而不是全部变量的写回，因此我们需要在传输对象中另设置一个变量，来指定哪些成员变量被用户更新过，这也就使得这种模式的设计相对复杂，开发人员需要考虑同步化和版本控制的问题。
图16显示了这个更新过程的序列图。
图16 可更新传输对象序列图
多传输对象的方法是指一个单一的业务对象可以根据用户请求制造多个不同的传输对象。也就是说，业务对象和它所创建的传输对象保持一对多的关系。类图17表示了这种实现方法的各个参与模块以及它们之间的调用关系。
图17 多传输对象类图
当一个用户需要A类型的传输对象时，他会激活相关EJB的getDataA()方法来取得传输对象A；当他需要B类型的传输对象时，他会激活getDataB()方法来获取传输对象B；依此类推。序列图18表示了这一过程。
图18 多传输对象序列图
使用这种设计模式，应用系统的实体bean及其远程接口会变得十分简单。实体bean中无需再为每一个成员变量都实现一个set()和get()方法，并在远程接口中实现相应的定义。用户无需再进行多次的方法调用来取得信息和数据，所需要的只是一次方法调用以获得整个传输对象。当然这里需要考虑Web负担和大量数据一次传输的权衡。开发人员可以根据不同的需要来选择不同的实现方法。
如上所述，用户和实体bean之间可以通过在一次方法调用中使用传输对象而交换所有的数据，也就是说传输对象作为数据载体工作，并减少了远程的方法调用，从而大大减轻了Web负担。通过使用传输对象的方法，我们也将有可能减少实体bean和其传输对象间的代码重复。不过在使用可更新的传输对象方法时，用户可以修改其本地的传输对象，之后再将其传送回业务对象中，后者将所需的更新整合到自己一端；但是这样一来，就会存在一个版本控制的问题，不同的客户可能在同时修改相同类型的传输对象，而如果相关的业务对象没有发现这一点的话，可能就会造成一些用户的数据没有得到及时更新，而另外一些用户的数据又被覆盖的情况；在系统设计中必须考虑这个问题。
8、截取过滤器
截取过滤器(intercepting filter)主要用于对于用户请求的之前处理和之后处理，也就是说它对于客户的请求使用了额外的操作。比如说，servlet可以处理一个网站的所有客户请求并提供一个核心的认证机制。
这种模式主要工作于表示层，负责处理不同类型的请求，同时也需要进行多种不同的处理。在这些请求中，有一些请求会直接传送给后端模块处理，而另外一些请求则先会在过滤器里解释或补充内容，之后才能传送给后端模块。这种模式的提出主要是由于一个客户的Web访问和系统响应都需要一定的预处理和后处理，例如用户身份、用户环境信息、用户请求的合法性等。通常这些处理的结果都会决定用户的请求是否能够进行，或是系统的响应应该用什么格式来表示。
对于这种预处理和后处理问题，传统上，开发人员会设计一系列额外的检测程序模块，也就是一整套if/else语句，并且指定如果其中任何一个检测失败，所有的处理工作都会退出。显然，这种方法是存在很大弊端的，即代码的可读性、可维护性都会被大大降低，同时将检测工作融于一般的程序模块，使得整个程序的模块性难以保证。
解决这种问题的关键在于，设计一种简单的技术，以能够添加或移除额外处理的模块，而这些模块通常都能够完成一定的检测和过滤功能。根据以上的讨论，J2EE研究人员提出了设计模式----截取过滤器作为解决方案，这种模式可以在不影响核心处理模块的情况下，实现可插入的过滤器来执行一般的处理功能。
从理论上来说，这种过滤器可以截取客户请求和系统响应，并进行相应的预处理和后处理；同时开发人员也可以随时根据需要移除这些过滤器，并不用担心会改变任何其他模块。
我们这里所说的预处理和后处理功能，通常是指一些基本的系统服务，如安全、登录，系统调试等。执行这些功能的过滤器通常是需要与核心模块分开的，并且由于系统职能或规则的变化，这些模块随时可能被添加或删除。
下面提供一些关于截取过滤器的图示，以帮助大家更好地理解这种设计模式，并合理地加以运用。图19表示了截取过滤器模式的整体结构，图19显示了截取过滤器中的参与模块和相互之间的联系。
图19 截取过滤器模式
图20 截取过滤器序列图
下面我们分别来说明图20中的各个模块：
(1)过滤管理器(Filter Manager)。过滤管理器负责过滤器的主要处理工作，即创建过滤器链对象以及相应的过滤器组建，并初始化整个处理过程。
(2)过滤器链(Filter Chain)。过滤器链是一组互不依赖的过滤器有序集合。
(3)过滤器1，过滤器2，过滤器3(FilterOne，FilterTwo，FilterThree)。这些都是提供不同服务的过滤器，而过滤器链则负责它们的协调工作。
通过采用这种设计模式，应用系统可以取得更方便的中心控制，这是由于过滤器可以提供处理多种请求的中心模块，并能根据后端的处理模块而解释和润色用户的请求，使得该请求能更好地与处理模块所提供的功能匹配。另外，过滤器通常可以将不同种类的服务聚集在一起，并提供相当灵活的服务组合，应用系统可以通过使用截取过滤器提高其重用性，过滤器可以随时根据需要从其他程序模块中插入或移除，并且由于它们通常具有标准的接口，开发人员可以使用一组类似的过滤器，并在不同的情况下进行全组的重用。
采用这种设计模式也会带来一定的问题，即在过滤器之间共享信息将变得非常困难，这是由于根据其定义和需求，每个过滤器的设计和开发都大相径庭。因而如果在不同的过滤器之间需要共享信息的话，其代价将是非常昂贵的。
- J2EE体系架构设计介绍(2)
- J2EE体系架构设计介绍(1)
- 基于开源搜索引擎的架构设计和J2EE实现(二)
- 基于开源搜索引擎的架构设计和J2EE实现(一)
- J2EE架构的6个最佳实践
为帮助企业应对各种性能困扰，提升IT架构性能，Riverbed提供了最全面的平台，确保理想的应用性能，持续的数据可用性，并主动监测和解决性能问题。Riverbed助力混合型企业将应用性能转化为竞争优势，最大化员工生产率，借助IT创造新型运维灵活性。