J2EE核心模式（原书第2版）[图书]

    书籍
    计算机书籍
"Java世界中各种类库、工具和技术规范俯拾皆是。而把这些内容融合在一起、解决真实问题的专业知识却一直竟告阙如。本书中的这些模式正是J2EE软件构建过程中的智力水泥。"


--John Vlissides，《设计模式》的作者之一


"《J2EE核心模式》的作者们提取了一组真正实用的模式。他们介绍了应该如何应用这些模式、如何重构系统以便从模式中获益。拥有这本书就像有一个专家组坐在你旁边一样。"


--Grady Booch，Rational软件公司首席科学家


"作者们介绍了大量对于应用程序架构极有帮助的模式，这是一项了不起的工作。单单是书中的'重构'部分就值整本书的价钱!"


--Craig McClanahan，Struts首席架构师，JavaServer Faces技术规范组负责人


开发者们常常把"学会一种技术"和"学会使用这种技术进行设计"混为一谈。在本书中，Sun Java中心的资深架构师们分享了他们多年积累的使用J2EE技术进行设计的经验。

Deepak Alur是Sun Java中心的企业Java架构师，具有14年以上的开发经验。他的主要研究兴趣在于利用面向对象技术、模式、Java和J2EE技术完成大型企业应用的架构、设计和实现。
John Crupi是Sun Java中心的杰出工程师和首席Java架构师。他有17年以上的分布式对象开发经验，他的主要研究兴趣在于创建可重用的，可扩展的J2EE架构，以及进一步提升J2EE模式的水准。
Dan Malks是Sun Java中心的主任工程师。他有16年以上的开发经验，他的主要研究兴趣在于面向对象技术以及这种技术在企业级的，基于Web Service的项目中的应用。他发表过很多作品，其中既有在行业杂志上发表的论文，也有讨论Java、J2EE技术以及模式的专著。

前言
第一部分 模式和J2EE
第1章 导论
什么是J2EE
什么是模式
历史回顾
模式的定义
模式的分类
J2EE模式目录
演化过程
怎样使用J2EE模式目录
使用模式的益处
模式、框架和重用
小结
第2章 表现层设计考虑和不佳实践
表现层设计考虑
会话管理
控制客户端访问
验证
助手类属性--完整性和一致性

　　 为一部由Grady Booch和Martin Fowler作序的作品写序言，这个念头本身就足够荒谬和僭越，不啻于在莎翁之后再写一个关于丹麦王子复仇的剧本。大师们的判断是中肯而毫不含糊的："没有这本书，就别开发EJB。"他们的担保足以确认本书在其论域中舍我其谁的地位。是的，这就是"那本"J2EE书。
　　 当然，对于广大中国开发者而言，我们早就已经在"没有这本书"的条件下开发了大量J2EE乃至EJB应用系统。那些波折的、不乏磨难的开发历程似乎使不少人具备了一种不无理由的自信，在掌握了若干API细节、若干应用服务器配置诀窍、若干框架类库用法之后，他们或是公开、或是暗自地把自己当成了当之无愧的Java企业开发专家。--不，这些话没有任何揶揄的意思：我们想说的其实是，本书恰恰是为以上这一类开发者写的。对于他们想成为"Java企业开发专家"的隐秘欲望，本书就是最大限度的补救和成全。如果说，此前的各种教程都是在介绍J2EE开发中的"内容"要素--也就是，教给我们"做什么"的话，本书关注的则是这里的"形式"要素，即"怎样做"才能开发出高效的、优雅的J2EE系统。读者从中学到的，将不仅仅是"J2EE技术"，而是"如何使用J2EE技术进行设计"。
　　 换句话说，如果你以前没有进行过J2EE实践，但明早将应聘一个需要"1年J2EE开发经验"的职位，本书中不包含你今晚要彻夜吞咽的那一类知识；相反，如果你，这位未来的"Java企业开发专家"，追求的职位是"资深Java应用系统架构师"，如果你预料到未来的上司明天将问起"怎样实现访问控制"、"何时采用细粒度的接口设计"等"高阶"问题，那么恭喜你，今晚--乃至今后--阅读本书，你选对了补课的读物。
　　 作为本书第1版的忠实读者，我们(半是欣喜、半是惊讶地)发现，眼前的这部第2版构成了全新的阅读体验。作者们按照最新版J2EE技术规范(尤其是EJB 2．1)全面修订了技术细节；根据模式社区的研究交流，作者们补入了若干模式；即使是一些不涉及技术更新的部分，论述方式、示例也完全不同于第1版；原有的PSA项目(第1版"尾声"一章)融入了其余各章的"示例代码"部分；而新增的讨论"微架构"的尾声、对Web Service等技术的关注、对各种的持久化方案(定制持久化、EJB、JDO等)的深入讨论，都体现出作者们对本书新版的大量投入。
　　 受益于本书有年，在此，我们想冒昧地为本书的中国读者们建议一条高效的阅读路径：与第1章相比，第5章"J2EE模式概览"是读者更合理的起步点。请特别关注其中对"分层"、"术语"和模式／策略区别的讨论，这些都是贯穿全书的重要概念!其次，应该通读第2章"表现层设计考虑和不佳实践"和第3章"业务层设计考虑和不佳实践"：即使你不打算使用任何模式，甚至，即使你根本不关心J2EE开发，只要你的工作与分布式企业应用系统有关，这两章涉及的问题都是你迟早会遇到的。至于每个具体模式本身，我们则推荐读者留意其中详尽的"策略"部分和那些散布其中的"设计手记"。前者讨论了对同一个模式的多种实现方案，后者则突出介绍了特定开发领域的一些核心概念和考虑。
　　 一部英文技术论著在汉语中的旅行，永远是一段难以捉摸的行程。对于本书的汉语译者，"技术难度"并非挑战：全书讨论的正是译者们最为熟知的一个领域，所以我们能够负责任地说，在这个中译本里，没有任何技术细节会因为译者的无知或生疏而发生变形或曲解。这次翻译的原则和前提是对原文的彻底领会。事实上，译者在翻译工作中遇到的困难主要发生在"语汇"层面。简单地说，J2EE专著的译者总要面对"翻，还是不翻"的两难处境：对象、函数的名称，UML图中的各种元素，这些内容由英语表示早就是约定俗成，即使是英语程度略低的开发者大概也都能读懂，所以，在读者能够理解的部分尽可能保留原文似乎是一种合理的做法--毕竟开发工作最终是与代码有关，而代码则肯定是要用"英文"的。但在另一方面，翻译的责任就在于让不谙英文的读者也能通达作品，如果译文中大量段落(不包括示例代码)都仍保留为英文或"类英文"，那么读者也就无法直观地获得原文包含的信息。反复权衡之后，在这个译本中译者的解决方式还是折衷的。工作中我们采取了以下原则：
　　 1)术语尽可能采用通用文献定译，不自创译法。对于各个模式的名称、模式文档模板各部分名称、重构手法名称，我们参考了李英军等译《设计模式》(机械工业出版社，2000年)、熊节等译《重构》(中国电力出版社，2003年)等译作，以及IBM Developer Works中文网站的部分资源。
　　 2)本领域的一些常见术语，如果没有定译，本书也不自创新语，强译为中文，而是保留英文原字。这一类的术语包括：applet、servlet、bean、JavaBean、entity bean、session bean、EJB、finder、Context、cookie、RowSet、null、scriptlet、Web Service。根据我们的观察，国内的开发者在日常工作中已经习惯按原文使用以上术语。在一些情况下，我们也以注释形式澄清了这些术语的用法。另外，一些非常直观的英文表达方式，比如"versus／vs"("A versus B"即"A对B"、"A与B相比较／对照")，我们也径用原文--改为汉语既罗嗦，也不直观。
　　 3)模式中的对象名称，往往按照代码风格命名，比如"Business Object"、"CustomerTO"等。如果对此完全不加翻译，那么很多充斥这类表达的段落就很难理解。我们的原则是，在每个自然段第一次出现某个这类表达方式时，用括号注明，比如"BusinessObject(业务对象)"、"CustomerTO(客户传输对象)"等。希望这个做法能够维持易懂和简洁之间的平衡。
　　 4)书中示例代码占有相当大的比重，而代码注释则是理解这些代码的关键。我们把所有代码注释译为中文。而对在视图中显示特定结果的代码(比如调试信息等)，我们没有改为中文，只是在必要时对输出信息的含义加以注解。如果读者更信赖代码原貌，还可以从本书官方网站http：//www．corej2eepatterns．com／下载原始代码。
　　 5)原书不包含注解，目前的所有注解都是译注。
　　 6)原书申义未畅处，译文中以方括号[]加以解释、补足，略去生涩。这与上面三条原则一样，都类似于在原作讲话时的插嘴--但翻译任务本身，似乎本就已经是一种"插嘴"了。在博学的读者看来，有时候译者或许还不如保持体面的沉默--但我们只能力图做到插嘴而不多嘴。
　　 7)原书引用了Apache项目的若干代码，所以附录中包含Apache软件授权协议一页。中译本照录了这份法律文件，未加翻译。
　　 8)几个关键术语的译名考虑：
　　 ·application：一般译为"应用程序"或"应用"。本书中这个词单独出现时，往往指的是"企业应用"，亦即企业信息应用系统。考虑到"应用程序"容易被理解为"桌面程序(desktop application)"，在该词含有"企业应用"意味时，我们译为"应用系统"，其他情况下则译为"应用"，以示区别。
　　 ·client：译为"客户端"。但本书中所说的"客户端"常常是指特定组件的调用者，不一定是"桌面程序客户端"，反倒很可能本身也是另一种组件、甚至一个子系统。希望读者注意该词在书中的用法。
　　 ·POJO：软件方法论大师Martin Fowler在《Patterns of Enterprise Application Architecture》(PEAA)中创造的说法，是plain old Java object的缩写，指普通Java对象(而不是EJB等组件)。中译本仍采用"POJO"名称。
　　 ·enterprise bean：直译为"企业bean"，在本书中就是"enterprise JavaBean／EJB"的另一说法。为了直观，我们统一译为"EJB"。
　　 ·tier／layer：字面上都是"层"／"层次"。本书中"tier"指的往往是"架构"意义上的分层，比如"表现层"，"业务层"、"集成层"等，而"layer"既分享了前者的含义，有时也指tier内部的中间层次，比如"会话门面"就构成了客户端和业务服务之间的一个"layer"。这两种意思实在很难区分，中译本只能都译为"层"、"层次"。希望读者在阅读中体察这种细微差别。
　　 ·delegate：是设计模式中的重要概念。一般译为"委派"。但在我们看来，这个译法还不完整，因为"委派"在汉语中只是动词，而delegate往往还充当名词。这次中译本的做法是，动词delegate仍译为"委派"，比如"A把功能F委派给业务层的B"，而名词delegate则译为"代表"，比如"B是A在业务层的代表"。希望读者体察，并推荐更好的译法。

　　 自从本书第1版出版以来，关于最初那15个模式，我们收到了大量反馈意见。最近几年来，J2EE模式社区目录服务器(JPCLS)上的活动一直都非常活跃、非常成功，每天都有很多精彩的意见交流。在这段时间里，我们也和客户一起进行了不少重要的大型J2EE架构设计、开发项目。把这段时期的经验和反馈植入到原有模式的更新工作和新模式的归档工作中，也确实是一个费力而艰苦的过程。我们特别关注了反馈中提及最多的内容：对J2EE技术规范和Web Service最新版本的支持。
　　 我们完全修订、更新了最初的15个模式，使得本书覆盖了J2EE技术1．4版的规范。我们在这些最初的模式中加入了很多新的策略。另外，我们还记录了6种新模式，以便改进模式语言，为构建、理解、使用J2EE框架提供更好的概念抽象。虽然这些模式中的每一个本身都极为实用，但我们还进一步相信，当开发者将其组合起来解决大型问题时，它们更能显出威力。因此在本书的新版中，引入了一个我们正在探究的、与此相关的全新领域，我们称此为"微架构"。
　　 所谓"微架构"，就是搭建应用程序和系统的积木块。与列入目录的那些单独模式相比，这个概念是一种更高层面的抽象，它常常表现为一组相互关联的模式组合，用于解决在应用架构中经常重现的一些共通问题。
　　 我们乐于把"微架构"当作一种由相互关联的模式组成的网络，由此形成一种现成的解决方案，用于解决一个粒度更大的问题，比如子系统的设计。
　　 本版中包括了一个叫Web Worker的微架构。它所解决的问题是：一个J2EE应用怎样与一个工作流系统集成。它特别讨论了使用系统集成模式让工作流系统中的用户与J2EE应用进行交互的问题。
　　 本书讲述的是Java 2企业版平台(J2EE)的模式。本书新版中记录的J2EE模式，能够用于解决在J2EE平台下进行软件应用开发的设计者常常遇到的那些问题。在这个模式目录中记录的模式都是在设计实战中发现的，正是因为使用了它们，我们才能为自己的客户创建出了成功的J2EE应用。
　　 本书描述了很多在J2EE平台下证明可行的解决方案，重点强调了以下核心J2EE技术：JavaServer Pages(JSP)、servlet、Enterprise JavaBeans(EJB)组件、Java Message Service(JMS，Java消息服务)、JDBC以及Java Naming and Directory Interface(JNDI，Java命名与目录接口)。对于那些在J2EE平台下经常重现的问题，我们通过J2EE模式目录和J2EE重构给出了解决方案。在开发新系统或是改进现有系统的设计时，你可以应用这些想法。本书记录的这些模式能够有助于你迅速熟练地掌握J2EE技术，从而构建出健壮、高效的企业应用。
　　 今天，正如以往一样，我们中间有很多人天真地以为，学会了一种技术，也就等于是学会了用这种技术进行设计。诚然，对于利用某一技术进行设计来说，懂得这种技术是成功的重要元素之一。但现在有很多Java图书，对技术细节(比如API的一些专门用法等等)做出了出色的讲解，但对如何应用这种技术却未作深入考察。要想学会设计，就需要实际设计经验，需要和其他开发者一起分享关于最佳实践和不佳实践的知识。
　　 本书中传达的经验来自我们的工作实战。我们属于Sun公司的Sun Java中心(SJC)咨询机构。在工作当中，我们经常遇到一些情况，因为技术发展过于迅速，设计者和开发者都仍然在奋力理解技术本身，而无暇理解如何使用该项技术进行设计。
　　 因此，简单地告诉设计者和开发者怎样写出优秀代码，或是建议他们使用servlet和JSP开发表现层，用EJB组件开发业务层，这都是不够的。
　　 那么，在这样的情况下，一个热心的J2EE架构师又怎样才能不单单是学到"做什么"、还能学到"不做什么"呢?哪些实践构成了最佳实践?哪些是不佳实践?怎样完成从问题到设计，再到实现的整个过程?
　　Sun Java中心与J2EE模式目录
　　 从初创时期以来，Sun Java中心的架构师们就在与来自全球的客户一起合作，致力于成功地设计、规划、构建、部署各种不同类型的基于Java和J2EE的系统。Sun Java中心是一个快速成长的咨询机构，一直在招募新员工，加入它经验丰富的架构师队伍。
　　 目前已经有大量已验证有效的设计和构架，将这些设计经验固化下来并和其他人一起分享，是我们行业的一项重要需要。我们很早就认识到了这种需要，从1999年就开始以模式的形式记录我们在J2EE平台下的工作经验。虽然我们翻阅了各种现有文献，却没能发现有哪个模式目录是专门记载J2EE平台下的模式的。有很多书论及J2EE技术中的一种或多种，出色地介绍了技术，剖析了技术规范中的微妙细节。我们发现其中有些书还提供了一些设计上的考虑思路，因此也特别有益。
　　 在2000年6月的JavaOne大会上，我们第一次公开发表了我们关于J2EE模式的想法。从那以来，我们收到了来自架构师和开发者的大量热忱反馈。其中一些人表示特别乐意进一步学习模式，还有一些人则说，他们使用过这些模式，只不过没有加以命名、也没有记录下来罢了。人们体现出来的对J2EE模式的兴趣鼓励我们进行进一步的工作。
　　 因此，我们整理出了J2EE模式目录，在2001年3月，这个目录的beta版通过Java开发者联盟(JDC)首次公布给了J2EE社区。基于整个社区的大量反馈，那一份beta版的文稿最终发展成了你现在见到的这本书。
　　 我们希望这些在J2EE平台下的模式、最佳实践、策略、不佳实践和重构能让大家从中受益。
　　本书的讨论范围
　　 本书讨论的内容包括：
　　 ·在J2EE平台下使用模式。

　　“Java领域的版图上撒满了各种类库、工具和技术规范。而缺乏的则是把这些内容融合在一起、解决真实情况下的问题的专业能力。本书中的这些模式，成为了J2EE软件建设过程中的智能水泥。 ——John Vlissides，《设计模