J2EE核心模式

《J2EE核心模式》(原书第2版)：“Java领域的版图上撒满了各种类库、工具和技术规范。而缺乏的则是把这些内容融合在一起、解决真实情况下的问题的专业能力。本书中的这些模式，成为了J2EE软件建设过程中的智能水泥。, ——John Vlissides，《设计模式》的作者之一, 　　“《J2EE核心模式》的作者们提取了一组真正实用的模式。他们介绍了应该如何应用这些模式、如何重构你的系统以便从模式中获益。这就像有一个专家组坐在你旁边一样。, ——Grady Booch，Rational软件公司首席科学家, 　　“作者们介绍了大量对于应用架构极有帮助的模式，这是一项了不起的工作。单单是书中的‘重构’部英文技术论著在汉语中的旅行,永远是一段难以捉模的行程。对于本书的汉语译者技术难度”并非挑战:全书讨论的正是译者们最为熟知的一个领域,所以我们能够负责任地说,在这个中译本里,没有任何技术细节会因为译者的无知或生硫而发生变形或曲解。这次翻译的原则和前提是对原文的彻底领会。事实上,译者在翻译工作中遇到的困难主要发生在“语汇”层面。简单地说,J2EE专著的译者总要面对“翻,还是不翻”的两难处境:对象、函数的名称UML图中的各种元素,这些内容由英语表小早就是约定俗成,即使是英语程度略低的开发者大概也都能读懂,所以,在读者能够理解的部分尽可能保留原文似乎是一种合理的做法—毕竟开发工作最终是与代码有关,而代码则肯定是要用“英文”的。但在另一方面,翻译的责任就在于让不谙英文的读者也能通达作品,如果译文中大量段落(不包括示例代码)都仍保留为英文或“类英文”,那么读者也就无法直观地获得原文包含的信息。反复权衡之后,在这个译本中译者的解决方式还是折衷的。工作中我们采取了以下原则:1)术语尽可能釆用通用文献定译,不自创译法。对于各个模式的名称、模式文档模板各部分名称、重构手法名称,我们参考了李英军等译《设计模式》(机械工业出版社,2000年)、熊节等译《重构》(中国电力出版社,2003年)等译作,以及 IBM Developer Works中文网站的部分资源。2)本领域的一些常见术语,如果没有定译,本书也不自创新语,强译为中文,而是保留英文原字。这一类的术语包括: applet、 servlet、bean、 Javabean, entity bean、 session bean、EJBfinder、 Context、 cookie、 Row Set、 null, scriptlet、 Web Service。根据我们的观察,國内的开发者在日常工作中已经习惯按原文使用以上术语。在一些情况下,我们也以注释形式澄清了这些术语的用法。另外,一些非常直观的英文表达方式,比如“ versus/vs”(“ a versus B”即“A对B”、“A与B相比较对照”),我们也径用原文——改为汉语既罗嗪;也不直观。3模式中的对象名称,往往按照代码风格命名,比如“ Businessobject”、“ Customerto”等。如果对此完全不加翻译,那么很多充斥这类表达的段落就很难理解。我们的原则是,在每个自然段第一次出现某个这类表达方式时,用括号注明,比如“ Business object(业务对象)”Customerto(客户传输对象〉”等。希望这个做法能够维持易懂和简洁之间的平衡。4)书中示例代码占有相当大的比重,而代码注释则是理解这些代码的关键。我们把所有代码注释谨为中文。而对在视图中显示特定结果的代码(比如调试信息等),我们没有改为中文只是在必要时对翰出信息的含义加以注解。如果读者更信赖代码原貌,还可以从本书官方网站http://www.corej2eepatterns.com/下载原始代码。5)原书不包含注解,目前的所有注解都是译注。6)原书申义未畅处,译文中以方括号加以解释、补足,略去生涩。这与上面三条原则一样,都类似于在原作讲话时的插嘴——但翻译任务本身,似乎本就已经是一种“插嘴”了。在博学的读者看来,有时候译者或许还不如保持体面的沉默但我们只能力图做到插嘴而不多嘴7)原书引用了 Apache项目的若干代码,所以附录中包含 Apache软件授权协议一页。中译本照录了这份法律文件,末加翻译。8)几个关键术语的译名考虑application:一般译为“应用程序”或“应用”。本书中这个词单独出现时,往往指的是VI企业应用”,亦即企业信息应用系统。考虑到“应用程序”容易被理解为“桌面程序( desktop application)”,在该词含有“企业应用”意味时,我们译为“应用系统”,其他情况下则译为“应用”,以示区别。e client:译为“客户端”。但本书中所说的“客户端”常常是指特定组件的调用者,不一定是“桌面程序客户端”,反倒很可能本身也是另一种组件、甚至一个子系统。希望读者注意该词在书中的用法。POJO:软件方法论大师 Martin fowler在《 Patterns of Enterprise Application Architecture》(PEAA)中创造的说法,是 plain old Java object的缩写,指普通Jav对象(而不是EJB等组件)。中译本仍采用“POO”名称enterprise bean:直译为“企业bean”,在本书中就是“ enterprise JavaBean/EJB”的另一说法。为了直观,我们统一译为“EJB"。tier/layer:字面上都是“层”/“层次”。本书中“tier”指的往往是“架构”意义上的分层,比如“表现层”、“业务层”“集成层”等,而“ layer”既分享了前者的含义,有时也指tier内部的中间层次,比如“会话门面”就构成了客户端和业务服务之间的一个“ layer这两种意思实在很难区分,中译本只能都译为“层”、“层次”。希望读者在阅读中体察这种细微差别。delegate:是设计模式中的重要概念。一般译为“委派”。但在我们看来,这个译法还不完整,因为“委派”在汉语中只是动词,而 delegate往往还充当名词。这次中译本的做法是,动词 delegate仍译为“委派”,比如“A把功能F委派给业务层的B”,而名词 delegate则译为“代表”,比如“B是A在业务层的代表”。希望读者体察,并推荐更好的译法。原书中所有模式、重构手法、策略的名称以斜体标出,要点以黑体标出。中译本一仍其旧原书经多人、多版修订完成,难免有错漏,乱排之处。译者根据本书官方网站的最新勘误表订正,并结合照本书第1版《 Core j2 EE Patterns: Best Practices and Design Strategies》( Addison Wesley,2001),另外修正了数十处错误刘天北熊节Grady Booch序在软件世界中,每个开发机构就像是一个部落,而一个模式就是对部落的某种共同记忆的一种有形表现。模式是对共通问题的共通解决方案,因此,对于某个特定开发机构的文化氛围某种特定的问题领域来说,命名、确定一个模式,也就是把已经在先前的经验中获得证明的共通解决方案进一步整理成文,设为圭臬。如果你有一套不错的模式语言能随时派上用场,那就像是在开发过程中身旁一直坐着一个专家组:在釆用专家们提出的一个模式时,你也就实际获益于他们那些来之不易的经验知识。事实上,那些最好的模式大都不是凭空发明的,而往往是专家们从现有的成功系统中发现、提取而来的。所以,一个成熟的模式中充满了实际有效的内容,不存在空泛不实的内容,同时,它体现了设计者的智意和设计思路。那些深刻的、真正有用的模式大多都是很古老的东西,见到这么一个模式的时候,你往往会说:“嘿,我从前就这么儆过。”但是,只有当专家为这个模式命名之后,你才获得了一整套讨论这个问题的语汇;此前,由于缺乏这种语汇,你往往想不到怎样使用这个模式,因此命名有助于我们更好地应用模式。最终,这样一个模式的功效在于,它能让你的系统变得更为简单而模式还不仅有助于构建更简单而又实际有效的系统,它们还有助于构建优美的系统。在种极度峽乏时间的文化氛围中,编写优美的软件常常是不可能的,这是很可悲的事情。因为我们作为专业人士,本来都应该致力于构建高质量的产品。而通过应用一组恰当的模式,你就有可能为白己的系统注入某种程度的优雅—缺乏模式的帮助,这种优雅往往就无从谈起KJ2EE核心模式》的作者们提取了一组真正实用的模式。别误解我的意思:孔2EE当然是一种重要的软件平台,它能够让开发团队构建出特别强大的软件系统。但是,目前的现实却是,在J2BE提供的抽象层次、服务与开发团队必须构建的最终应用之间,还存在着非常巨大的语义断裂。本书描绘的这些模式,事实上正是人们一次又一次用来填补这种断裂的共同解决方案。应用这些模式,也就是采用了一条最主要的避免软件风险的措施:只要编写更少代码就能获得相同的效果。你也不必再重新自己动手寻找解决方案,这些模式已经在很多现存系统的应用中得到了验证,所以只需应用它们就是了作者们不仅完成了一组模式的命名,还利用UML确定了模式的语义,使它们更容易为人理解。并且,他们也介绍了应该如何应用这些模式、如何重构你的系统以便从模式中获益。冉说遍,拥有本书就像一个专家组坐在你旁边一样。Grady boochRational软件公司首席科学家Martin Fowler序在1998年末,我所在的 ThoughtWorks公司就开始使用J2EE了。在那个时候,我们发现了很多很酷(虽然有点儿不成熟)的技术,但是很少有人能说明怎样才能恰当地应用这些技术。也许是因为我们具备在其他OO服务器环境下编程的大量经验,所以我们自己能够应付这些问题。但是我们也见到很多客户费尽了周折——并不是因为技术本身的问题,而是因为不知道怎样才能恰当地应用这些技术。使用模式,能够固化设计经验一也就是说,模式有助于将经常重现的问题的实际解决方案进行归类、编目。多年以来,对于模式的这种用途,我一直都是个由衷的爱好者。最近的几年里,业界的很多先驱者都在使用J2E,都在寻找构成一个有效的j2EE解决方案的核心模式。本书对这些模式进行了出色的汇集,其中揭示的很多技术都是我们自己通过多次尝试、多次错误才获得的。这也就是本书的重要之处。对AP倒背如流是一回事;知道如何设计优秀的软件则是另一回事。本书确实致力于固化这一类设计知识,这也是我见到的第一本这么做的书,看到作者们做得这么漂亮,我由衷感到欣慰。如果你在』2EE平台下工作,你也就需要了解这些模式。另外,本书也提出了这样一种观点:当编码开始后,设计并非就结東了。人们在设计时做出的一些决定常常不符合实情。在这种情况下,在构建过程中还需要修正原本的设计,而这种修正必须以一种规范的形式进行。越来越多的人选用“重构”的方法来对现有系统做出更动本书的作者把我在重构方面的研究应用在一个新领域一一也就是J2EE设计的世界之中,这样做还尚属首次。我不仅因为有人在我的研究基础上进行工作而心怀感激,而且,读到他们依据自己的经验,实际描述了如何进行系统重构的转换,我也感到非常喜悦。说到底,这种经验正是最宝贵的东西。把设计经验固化在书本中,这是最难做的一件事,但是要想让我们的行业进一步发展,这件事又非做不可。本书固化了EE开发中的重要经验。没有这本书,就别开发EJBMartin FowlerThought Works首席科学家前言自从本书第1版出版以来,关于最初那15个模式,我们收到了大量反馈意见。最近几年来,J2EE模式社区目录服务器( JPCLS)上的活动一直都非常活跃、非常成功,每天都有很多精彩的意见交流。在这段时间里,我们也和客户一起进行了不少重要的大型J2EE架构设计、开发项目。把这段时期的经验和反馈植入到原有模式的更新工作和新模式的归档工作中,也确实是个费力而艰苦的过程。我们特别关注了反馈中提及最多的内容:对J2EE技术规范和 Web service最新版本的支持。我们完全修订、更新了最初的15个模式,使得本书覆盖了J2EE技术14版的规范。我们在这些最初的模式中加入了很多新的策略。另外,我们还记录了6种新模式,以便改进模式语言,为构建、理解、使用J2EE框架提供更好的概念抽象。虽然这些模式中的每一个本身都极为实用,但我们还进一步相信,当开发者将其组合起来解决大型问题时,它们更能显出威力。因此在本书的新版中,引入了一个我们正在探究的、与此相关的全新领域,我们称此为“微架构”。所谓“微架构”,就是搭建应用程序和系统的积木块。与列入目录的那些单独模式相比,这个概念是一种更高层面的抽象,它常常表现为一组相互关联的模式组合,用于解决在应用架构中经常重现的一些共通问题我们乐于把“微架构”当作一种由相互关联的模式组成的网络,由此形成一种现成的解决方案,用J解决一个粒度更大的问题,比如子系统的设计。本版中包括了一个叫 Web worker的微架构。它所解决的问题是:一个]2EE应用怎样与一个工作流系统集成。它恃别讨论了使用系统集成模式让工作流系统中的用户与J2EE应用进行交互的问题本书讲述的是JaVa2企业版平台(JEE)的模式。本书新版中记录的J2EE模式,能够用于解决在2EE平台下进行软件应用开发的设计者常常遇到的那些问题。在这个模式目录中记录的模式都是在设计实战中发现的,正是因为使用了它们,我们才能为自己的客户创建出了成功的J2EE应用。本书描述了很多在]2EE平台下证明可行的解决方案,重点强调了以下核心J2EE技术JavaServer Pages(JsP)、 servlet、 Enterprise JavaBeans(EJB)组件、 Java Message Service(MS,Java消息服务)、JDBC以及 Java Naming and Directory Interface(JNDI,Java命名与目录接口)。对于那些在EE平台下经常重现的问题,我们通过J2EE模式目录和EE重构给出了解决方案在开发新系统或是改进现有系统的设计时,你可以应用这些想法。本书记录的这些模式能够有助于你迅速熟练地掌握J2EE技术,从而构建出健壮、高效的企业应用今天,正如以往一样,我们中间有很多人天真地以为,学会了一种技术,也就等于是学会了用这种技术进行设计。诚然,对于利用某一技术进行设计来说,懂得这种技术是成功的重要元素之一。但现在有很多Java图书,对技术细节(比如API的一些专门用法等等)做出了出色的讲解,但对如何应用这种技术却未作深入考察。要想学会设计,就需要实际设计经验,需要和共他开发者一起分享关于最佳实践和不佳实践的知识。本书中传达的经验来自我们的工作实战。我们属于Su公司的 Sun java中心(SJC)咨询机构。在工作当中,我们经常遇到一些情况,因为技术发展过于迅速,设计者和开发者都仍然在奋力理解技术本身,而无暇理解如何使用该项技术进行设计因此,简单地告诉设计者和开发者怎样写出优秀代码,或是建议他们使用 servlet和SP开发表现层,用EJB组件开发业务层,这都是不够的。那么,在这样的情况下,一个热心的EE架构师又怎样才能不单单是学到“做什么”、还能学到“不做什么”呢?哪些实践构成了最佳实践?哪些是不佳实践?怎样完成从问题到设计,再到实现的整个过程?Sun java中心与J2EE模式目录从初创时期以来, Sun java中心的架构师们就在与来自全球的客户一起合作,致力于成功地设计、规划、构建、部署各种不同类型的基于Java和J2E的系统。 Sun java中心是…个快速成长的咨询机构,一直在招募新员工,加入它经验丰富的架构师队伍。月前已经有大量已验证有效的设计和构架,将这些设计经验固化下来并和其他人一起分享是我们行业的一项重要需要。我们很早就认识到了这种需要,从1999年就开始以模式的形式记录我们在J2EE平台下的工作经验。虽然我们翻阅了各种现有文献,却没能发现有哪个模式目录是专门记载EE平台下的模式的。有很多书论及J2EE技术中的一种或多种,出色地介绍了技术,剖析了技术规范中的微妙细节。我们发现其中有些书还提供了一些设计上的考虑思路,因此也特别有益。在2000年6月的 lavant大会上,我们第一次公开发表了我们关于2EE模式的想法。从那以来,我们收到了来自架构师和开发者的大量热忱反馈。其中一些人表示特别乐意进一步学习模式,还有一些人则说,他们使用过这些模式,只不过没有加以命名、也没有记录下来罢了。人们体现出来的对2E模式的兴趣鼓励我们进行进一步的工作。因此,我们整理出了J2EE模式目录,在2001年3月,这个目录的bet版通过Java开发者联盟(JDC)首次公布给了J2EE社区。基于整个社区的大量反馈,那一份beta版的文稿最终发展成了你现在见到的这本书。我们希望这些在J2EE平台下的模式、最佳实践、策略、不佳实践和重构能让大家从中受益本书的讨论范围本书讨论的内容包括在J2EE平台下使用模式。基于我们在J2EE平台的经验,我们编纂了本书中的模式目录。这一份J2EE模式目录描述了在J2EE平台下架构和设计应用的最佳实践。本书着重考察了以下2EE技术: servlet、JSPEJB组件和JMS。X通过最佳实践来设计应用了 servlet、JSP、EJB组件和MS技术的应用系统。仅仅学会了技术本身和AP还不足够,同样重要的是要学会怎样使用技术进行设计。我们记录了在我们的经验中应用这些技术的最佳实践。防止在EE平台的设计和架构中“重新发明轮子”。模式鼓励设计的重用。重用现成的解决方案,能够缩短设计开发应用程序的周期—这也当然包括J2EE应用·鉴别出现存系统中的不佳实践,并利用J2EE模式重构这些设计,以形成更好的解决方紫。知道哪些做法有效,这是一件好事。但知道哪些做法无效也同样重要。我们在本书中记录了自己在设计J2EE应用时遇到的一些不佳实践。本书不讨论的内容本书没有讨论以下内容如何使用av或JEE技术编程本书讨论的不是编程。虽然很多内容都基于E技术,但我们没有描述AP细节。如果你希望学习Java編程,或是学习使用J2EE中的任何一种技术,现有很多种出色的著作,还有不少在线资源,都可以作为教程。如果你想要学马某一门特定的技术,我们强烈推荐Java官方主页hp:/ va sun. com上的各种在线教程。J2E技术的官方技术规范也可通过Java主页获得。采用哪种开发过程和方法论我们并不特别推荐任何一种开发过程或方法论,因为本书讨论的内容与这两方面都关系不大。所以,本书不会教授任何可以用于开发项目的过程或方法论。如果你想要学习过程和方法论的话,现已有很多论若讨论各种面向对象的方法论,对于那些轻量级的过程,比如极限编程,也有不少新书论及。怎样使用统一建模语言(UML本书不会教你如何使用UML。我们大量地使用了UML(特别是类图和序列图)来记录模式,描述静态和动态交互关系。如果要学习UML,请参考 Grady booch、 Ivar Jacobson和 JamesRumbaugh的著作《UML用户指南》[ Booch以及《UML叁考手册》[ Rumbaugh]谁应该读这本书本书写给所有热心关注J2EE的人,程序员,架构师,开发者以及技术经理。简单地说,就是任何对在J2EE平台下设计、架构、开发应用程序有点儿兴趣的人。我们力图让这本书成为一部写给2EE架构师和设计者的培训指南。我们认为良好的设计架构得当的项目具有很高的重要性,所以我们需要优秀的架构师达到这个水准。对于那些开发者水准参差不齐的开发团队,如果我们把模式、最佳实践和不佳实践都做出详尽的归档,以此在团队中实现知识与经验的共享和传播,这可能会起到难以估价的帮助作用;我们也希望本书能部分地满足类似需求。本书的组织本书的组织分为两部分。第一部分第一部分“模式和J2EE”是一个关于J2EE和模式的导论。它考察了开发JSP、 servlet和EJB时的设计考虑。这…部分也包括了J2EE平台下的不佳实践和重构。第1章“导论”简要地讨论了多个问题,包括模式、J2EE平台、模式的定义以及模式的归类。最后引人了J2EE模式目录。第2章“表现层设计考虑和不佳实践”、第3章“业务层设计考虑和不佳实践”分别讨论了表现层以及业务/集成层的设计考虑和不佳实践。这里所说的设计考虑,是指在2EE平台下工作时,个J2EE开发者/设计者架构师需要考虑的问题。在阅读这两章中的论题时,可以参照其他的多种资源(比如官方技术规范以及一些出色的相关论著)来获得相关问题的一些细节信息第4章“J2EE重构”考寮了一些重构,我们在自己的实际工作中遇到了这些重构,它们也确实帮助我们把原本不够理想的设计提升为更好的方案。这些重构也提供了看待本书其他内容的另一种思路,我们认为这对于模式目录是一种有价值的补充材料。本章体现出 Martin Fowler和他的著作《重构》[ Fowler]对我们的影响。对于熟悉《重构》一书的读者,本章的形式也应该相当眼熟。但是,这一章的内容完全基于J2E技术,而 Martin fowler在他的论著中则是在另一个层面考察重构的第二部分第二部分“J2EE模式目录”列出了JEE模式目录。目录中包含的模式构成了本书的核心内容第5章“J2EE模式概览”,是J2EE模式目录的一个综述。这一章一开始对模式的理念进行了高层次的讨论,并且解释了我们按照系统的分层对模式进行归类的原因。该章也介绍了我们用来记录本书所有模式的“J2EE模式模板”。该章考察了所有的J2E模式,并且用一张图描述了模式之间的相互关系。另外该章还包括了一种我们称为“模式目录路线图”的东西。这张路线图列举了一些与JEE设计和架构相关的常见问题,并且把这些问题与特定的模式或重构关联起来,通过这些模式、重构给出了问题的解决方案。理解模式之间的关系以及这张路线图,对于实际应用这些模式至关重要。第6章“表现层模式”描述了8种模式,它们处理的是在J2EE平台的Web应用设计中,怎样使用 servlet、JsP、 Javabeans和定制标记的问题。在这些模式中描述了多种实现策略,并且也提出了一些常见问题,比如请求处理、应用分隔、生成复合视图等。第7章“业务层模式”,描述了9种模式,它们处理的是怎样应用EB在J2EE平台下设计业务组件的问题。该章介绍的模式提供了应用EB和MS技术的最佳实践。另外,这些模式的相关部分还涉及了其他技术—比如NDI、JDBC等—的讨论。第8章“集成层模式”描述了4种模式,它们处理的是怎样把J2EE应用与资源层和各种外部系统集成起来的问题。这些模式使用了JDBC和JMS技术在业务层和资源层之间实现集成。“尾声”讨论的是一个高层次的主题:怎样利用多个模式一起解决一个大型问题。该章详尽