软讯网络 > 编程语言 > Java > Session Facade 的规则和模式(3)
【标 题】:Session Facade 的规则和模式(3)
【关键字】:
c,模式,io,Session,on,Session,Facade
【来 源】:网络
Session Facade 的规则和模式(3)
Session Facade 的规则和模式(3)
使用 EJB 对象的原因
那么为什么我们需要这第二层对象呢?难道我们从 CORBA 和 RMI 转到 Enterprise JavaBean 就使事情更简单了吗?为什么不把所有的逻辑都放到 EJB 中呢?这有几个原因。第一个也是最重要的原因是这是一个分层应用程序。在单个对象中放置太多工作从来不是一个好主意。如果您用这种方式来布置由 EJB 调用的对象,可以带来以下好处:
把工作放在一个会话层上的一套对象中,使我们可以更容易独立地测试它们,或许甚至可以在 J2EE 应用服务器环境之外对它进行测试。
不同的多个Session Facade 对象可以使用同一层上的对象,而不必担心事务语义不正确,也没有跨Session bean 调用可能带来的网络和数据组织/数据分解开销。
第二层对象允许您对那些对象实现多样化(通过使用 [Gamma] 中介绍的 Stragtegy 模式),这样便可以利用应用服务器的特有功能,同时仍然保持整个设计在应用服务器之间的可移植性。例如,[Brown 2000a] 描述了一些特别的高速缓存策略,用于提高那些能在 WebSphere Application Server(高级版)下工作、却不能在 IBM CICS EJB 支持下工作的 EJB 的性能。通过为同一个 Factory 类或 Action 类提供两个实现,您便可以保持整个设计的可移植性,同时也最大程度地利用各个服务器的特有功能。
在您不需要 JTA 事务的情况下(例如,您只对单一数据源进行操作),这个模式允许您选择部署和构建带或不带 EJB 的应用程序。例如,在一些简单查询中,为避免 EJB 调用的开销,您可以直接从 servlet 调用 Factory,这能显著提高效率。
同时,通过回顾几个工程,我们发现重用只在少数情况下会出现在会话层上。这是因为,每个会话都有针对一个特定应用程序的一个事务设置与方法的特定组合。有了第二层对象则使您可以在内层级别上进行重用,我们在很多工程中都看到过这种重用,包括在企业的一个工程内(在不同的Session bean 之间)和多个工程之间。
我们已经看到,如果采用这种策略,那么您的设计经常可以把无状态Session bean 当作 Facade 对象使用。由于对某个用户而言,每个无状态Session bean 都不是唯一的,这就使您能够得到无状态 bean 所提供的另外的可扩展性。
既然我们已经知道了 facde 背后对象的类型,我们就可以开始看看 facade 能对外提供哪些类型的方法了。我们看到 Facade 方法通常属于以下几种类型:
Collector 方法通常以“get”开头,返回一个对象或一个对象集合(在 EJB 1.0 中是 Emulation,在 EJB 1.1 和 2.0 中则是一个 Java Collection)。如 [Brown 2000] 所述,collector 方法在 Factory 对象中实现。
Updater 方法根据作为参数传入的值对象所掌握的信息来定位并更新一个Entity bean 或一个Entity bean 集。方法名称常常以“update”或“set”开头。updater 方法的实现可以像 [Brown 2000] 所说的那样放在 factory 中,或者在一个单独的类中。
Action 方法(例如 transfer(String fromAcctNum, String toAcctNum, BigDecimal amount))的实现放在 Action 对象中。
Session Facade 的创建规则
既然您看到了Session Facade 接口的样子,在Session Facade 背后的又有哪些对象,那么下一个问题就是“我该有多少Session Facade 呢?”您不应拥有太多的Session Facade,否则,就丧失了 Facade 模式带来的好处。但是,若整个应用程序对应一个Session Facade 它可能会成为一个“巨大的对象”5并导致它自身的一些问题。这里是设计Session Facade 的一些规则,使您能适当地(不过多或过少)使用它。
从您的应用程序中找出功能子系统。例如,名为定单管理、帐单管理和运输管理的子系统就是一个应用程序中可能有的三个 Facade 对象。
回到您的用例(Use-case)和相关的用例组。一组相关的用例 (例如购买股票、出售股票和获取报价)可以形成一个内聚子系统,例如“股票交易”。这个内聚子系统就可能要共享很多内层对象,并且是使用Session Facade 的最佳候选。[Sun 2001] 更深入地讨论了这个问题。
千万不要把所有的单个用例都做到Session Facade 中。这将导致系统分布截面过大。这种情况下,客户机将不得不管理非常多的 EJB 引用和 Home。
完成初步工作后,看一下您的设计中第二层对象之间的关系。如果您看到有值对象、Factory 和 Action 的不相交组,那就根据实际分组法把 Facade 分成两个或更多 facade。
另一种会话模式
既然您已深信应该使用无状态的Session Facade 来包装数据源,也应该在这些 facade 的实现中进行严格的分层,您可能会想知道特定于用户的应用程序状态(如果有的话)将被保存在什么地方。根据我所主张的把Session facade 设计成能处理多用例请求,您可能还会想知道用例在哪里实际实现。
为了理解如何应用它,我们采用出自 [Jacobson 1999] 的 Control 对象的如下定义:“Control 类代表协调、顺序事务以及对其它对象的控制,常用于封装与特定用例相关的控制。”
这个解决方案的目标是实现专门的、与一个单一的用例一一对应的“用例控制器”对象。每个用例控制器都将维护一些特定于用户的状态,这些状态与判断一个用户在此用例中位于哪里所必需的信息(例如,它们已经执行了多少)相对应,也与用户输入的、对执行用例的下一步来说必需的信息相对应。这样,我们就找到了一个能够用真正不依赖于 GUI 的方式来实现和编写用例的方案。
那么,实现这些用例控制器对象,您有哪些选择呢?因为它们天生就必须是有状态的,我们有两个 J2EE 体系结构中自己提供的选择:
一个选择是把用例控制器变为可序列化对象(JavaBeans),然后在 HttpSession 中存储和检索它们。当然,这只能用在使用 Servlet API 的应用程序中。但它可以应用于很多应用程序,甚至包括那些使用 Applet 和 Application 的客户机 GUI 的应用程序,因为即使在这些情况下,通过 HTTP(也可能使用 SOAP)来和服务器端对象进行通信也是一个常用的设计策略。用 HttpSession 作为存储机制会使程序员更轻松,因为在多数应用服务器(例如 WebSphere)中会话的持久和故障转移细节都是自动处理的。然而,在 WebSphere 中,一个 HttpSession 要得到合理的持久性,则其大小将受到一定的限制(请参阅 [Gunther]),所以这个选择只适合用例控制器对象相对较小的情况。
另一个选择是把有状态的Session bean 当作用例控制器用。有状态的Session bean 是个很好的解决方案,它使程序员不必担心如何维护会话信息。在有状态的Session bean 被自动存储在共享持久存储器的应用服务器中,这个解决方案甚至能处理故障转移。但是,在像 WebSphere 这样的应用服务器中的Session bean 并不存储在共享持久存储器中,如果碰上服务器崩溃,这个解决方案将导致用户会话失败。而且,以这种方式使用有状态的Session bean 会使我们回到增大总的分布截面的老问题上。尽管如此,由于有状态的Session bean 自己充当一个 facade,每个客户机只需知道少数的用例控制器,这样就减轻了这个问题。
绕了个圈,这种模式又把我们带回到我们最初讨论的 Facade 模式。这种模式相继分层的方式使我们可以集中精力处理手边的工作,同时还允许我们重用一些东西来构成我们的解决方案。我们不必一次性设计出整个系统,但可以反复使用这些模式,然后看着一套可重用的对象作为结果出现。
总结
我在本文中简要分析了构建Session Facade 的一些规则。您已经看到了该如何组织Session Facade 所调用的对象,如何着手设计Session Facade。您还看到了设计能与Session facade 配合得很好的用例控制器的一些方法。我希望,这些规则的应用能提高您的 EJB 设计的适应性和性能。
致谢
感谢 Martin Fowler 审读了本文的草稿并提出了深刻的意见。同时感谢 Craig Larman 的深刻见解,他使我明白事实上Session facade 有两种互补模式。
参考书目
Erich Gamma、Richard Helms、Ralph Johnson 与 John Vlissides 合著的 Design Patterns: Elements of Reusable Object-Oriented Design,Addison-Wesley,1995。[Gamma]
Martin Fowler 的 Analysis Patterns: Reusable Object Oriented Model,Addison-Wesley,1997。[Fowler]
Martin Fowler 的 Information Systems Architectur。[Fowler 2001]
Sherman Alpert、Kyle Brown 与 Bobby Woolf 合著的 The Design Patterns Smalltalk Companio,Addison-Wesley,1996。[Alpert]
William Brown、Ralph Malveau、Hays McCormick 与 Thomas Mobray 合著的 AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis,John Wiley and Sons,1998。[Brown 1998]
Kyle Brown、Philip Eskelin 与 Nat Pryce 合著的 “A small pattern language for Distributed Component Design”,是提交给 1999 年在 Illinois 的 Monticello 召开的程序模式语言(the Pattern Language of Programs,PloP)大会的论文,在 Ratio Group Web site 有它的完整镜像发布。[Brown 1999]
Kyle Brown 的 “Layered Architectures for EJB System”,VisualAge Developer Domain。[Brown 2000]
Kyle Brown 的 “Choosing the right EJB type:Some Design Criteria”,VisualAge Developer Domain。[Brown 2000a]
Kyle Brown 与 et. al. 合著的 Enterprise Java Programming for IBM WebSphere,Addison-Wesley Longman,Boston,2001 年 5 月。[Brown 2001]
“Session Facade”, Sun Java 核心 J2EE 模式,Java 开发者连接。[Sun 2001]
Harvey Gunther 的 “WebSphere Application Server Development Best Practices for Performance and Scalability”。[Gunther]
“Session Enity Facade”,Sun J2EE 规划蓝图。[Sun 2000]
Sun Microsystems,“EJB 2.0 规范”,发布草案 2。[EJB 2.0]
Richard Monson-Haefel,Enterprise JavaBeans,第二版,O´Reilly,2000。[Monson-Haefel]
Ivar Jacobson 与 et.al 合著的 “The Unified SoftWare Development Process”,Addison-Wesley,1999。[Jacobson 1999]
脚注
1 Erich Gamma、Richard Helms、Ralph Johnson 与 John Vlissides 合著的 Design Patterns: Elements of Reusable Object-Oriented Design,Addison-Wesley,1995,第 185 页。
2 Erich Gamma、Richard Helms、Ralph Johnson 与 John Vlissides 合著的 Design Patterns: Elements of Reusable Object-Oriented Design,Addison-Wesley,1995,第 186 页。
3Erich Gamma、Richard Helms、Ralph Johnson 与 John Vlissides 合著的 Design Patterns: Elements of Reusable Object-Oriented Design,Addison-Wesley,1995,第 187 页。
4Erich Gamma、Richard Helms、Ralph Johnson 与 John Vlissides 合著的 Design Patterns: Elements of Reusable Object-Oriented Design,Addison-Wesley,1995,第 193 页。
5William Brown、Ralph Malveau、Hays McCormick 与 Thomas Mobray 合著的 AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis,John Wiley and Sons,1998,第 73 页。
关于作者
Kyle Brown 是 IBM WebSphere Service 的高级 Java 顾问。Kyle 在 WebSphere Service 中的职责是就关于面向对象的主题和Java 2 企业版(J2EE)技术,向“财富 500 强”客户提供咨询服务、教育以及指导 。他是 The Design Patterns Smalltalk Companion(设计模式 Smalltalk 伴侣)的合著者,也是一位著名的撰稿人,还是关于 Enterprise Java,OO 设计和设计模式主题的讨论会的发言人。可通过 brownkyl@us.ibm.com 与 Kyle 联系。 (全文完)
|