EJB 设计模式概述.docxVIP

一． 设计模式重要性采用ＥＪＢ技术的Ｊ２ＥＥ项目中，ＥＪＢ架构的设计好坏将直接影响系统的性能、可扩展性、可维护性、组件可重用性及开发效率。项目越复杂，项目队伍越庞大则越能体现良好设计的重要性。?　二． 常见EJB设计模式Session Facade Pattern?　通常项目中，客户端往往需要频繁的对服务器端数据进行操作。当采用实体ＥＪＢ作为数据的抽象层时，如果直接让客户端程序与实体ＥＪＢ交互，会产生实现一个业务需求便需要大量的ＥＪＢ属性操作（如下图１）。这直接导致如下问题：网络负载大（远程客户端时）、并发性能低、客户端与服务器端关联度大、可重用性和可维护性差、性能因此有必要在客户端与实体ＥＪＢ层间加入Session　ＥＪＢ层，在Sessino EJB中实现商业逻辑并封装对实体ＥＪＢ的操作。（如下图２）　图１：客户端直接与实体ＥＪＢ交互　?　图２：通过SessionEJB层实现　Session Fa?ade模式的好处是：降低了网络负载，SessionEjb可以调用实体ＥＪＢ的本地接口；将商业逻辑与商业数据隔离；维护与开发方便；显著提高性能。　Session Fa?ade模式因其简单使用，是目前使用很广的模式。但具体应用过程中应注意：避免将所有的操作封装到一个很大的SessionEJB内；服务器端数据结构应由实体EJB实现,除非特例否则避免直接的数据库操作；SessionEjb内某些系统通用操作的代码容易重复（比如权限检查等，解决办法是将系统通用服务封装在Java?Class内）。Message Facade Pattern　很多时候，一次Request需要操作多个ＥＪＢ又不需要得到即时返回。对这种异步调用，通常应用Message Fa?ade Pattern.这种时候，如采用Session Fa?ade Pattern存在如下问题：　1. 客户端等待返回的时间过长。一个SessionEjb的实例在完成客户请求过程中中涉及到的每一次对其他实体Ejb的调用过程中都会被锁定直到得到实体EJB返回信息后才能进行下一步操作。这样造成客户不必要的等待，并很容易因时间导致整个事务失败。 2. 系统可靠性和容错性低。如果需要调用不同系统或服务器上或多个异构数据源的多个ＥＪＢ时，任何一个环节出错，均导致客户请求失败。?　以Message-Driven Bean为基础的Message Facade Pattern则可以解决上述异步请求需求。具体架构见下图３　图３：使用Message Facade PatternMessage Facade Pattern的不足之处在于：　１． Message-Driven Bean没有返回值。这样通知客户执行结果只能依赖于Ｅｍａｉｌ或人工等其他手段。　２． Message-Driven Bean执行过程中无法将捕获的异常直接返回给客户端，即无法使客户端直接直到错误信息。　３． Message-Driven Bean通过接收Message响应客户请求，对Message内容的合法性（比如对象的类型等）依赖与客户端.容易产生运行时错误。　Message Facade Pattern经常与Session Facade Pattern在同一个项目里共同使用。EJB Command PatternSession Facade Pattern中将商业逻辑实现封装在Session EJB中，这种做法带来诸多益处之外也带来如下问题：　１． 由于业务经常的变化，导致经常需要更新Session EJB代码。　２． 客户端代码不得不包含大量EJB相关的ＡＰＩ，不利于后期项目维护。　３． 项目开发测试需要经常的EJB重部署过程。　引起上述问题的重要根结就是Session EJB本身重量级组件，其开发测试部署工作量较大，开发周期较长。以上不足可以通过EJB Command Pattern克服。 EJB Command Pattern中将商业逻辑实现封装在普通的Java Class（称之为Command Bean）中。该模式的具体实现有很多种，通常的框架都包括三部分：?　１． Command Bean.由应用开发者写的具体实现某商业操作的Java Class.主要包含getXXX(),setXXX(),execute()方法。　２． Client-Side Routing Logic.由多个Class组成，用于将请求转发至Command Sever，这个过程对客户是透明的。这部分代码可以跨项目使用。路由规则中可以考虑用ＸＭＬ技术。　３． Remote Command Server.实际执行商业操作请求。通常可以用Session EJB层实现。　整个框架见下图４：图４：Command的基本框架　EJB Command Pattern具有如下好处