“通过这本书，TedNeward将帮助你实现从一个优秀的Java企业应用开发者向一个伟大的开发者的飞跃！”
——John Croupi, Sun著名工程师，《Core J2EEPatterns》作者之一
如果你想构建更好的Java企业应用，并使之运行起来更加高效，本书就是最佳选择。本书通俗易懂地解释了J2EE开发的微妙之处。你将学会：
■使用进程内或本地存储以避开网络，请参阅第44项
■考虑使用较低的隔离级别以获得更大的事务吞吐量，请参阅第35项
■为了开放集成而考虑使用Web服务，请参阅第22项
■仔细考虑你的查找，请参阅第16项
■预生成内容以最小化处理过程，请参阅第55项
■使用基于角色的授权，请参阅第63项
■面对故障时要健壮，请参阅第7项
■为版本并存使用独立的JRE，请参阅第69项
TedNeward向读者提供了75项易于理解的技巧，它们可以帮助你在系统和架构层次上驾驭J2EE开发。他对J2EE开发的优势、弊端的全景式看法将解决你最迫切关心的问题，使你学会：如何设计企业系统使其适应未来的需求；在无损于代码正确性的前提下提高代码的效率；如何实现语言或平台无法直接支持的复杂功能。在阅读本书之后，你将了解如何设计和实现更好的、更具可扩展性的、企业级Java软件系统。
无
忘记过去的人，必将重蹈覆辙。
—George Santayana
对Java程序员来说，现在是大好时机。尽管Java作为可用的商业产品还不到10年，但在几乎所有主流计算平台上，它已经成为企业级系统的构建语言之一。那些要解决挑战性问题的公司和个人，越来越拥护Java语言及其平台。对于那些不使用Java的人来说，现在面临的问题不在于是否采用Java技术，而是准备何时开始采用。超越并包含了Java语言本身的Java 2企业级平台（J2EE）规范，涵盖了大量规范和程序库。这使得在不牺牲性能，或者不用从头实现常用算法及数据结构的情况下，也可以编写出丰富、复杂的系统。Java语言和虚拟机还在变得更加强大。针对Java开发者的工具和环境也在变得更加丰富和可靠。在许多应用领域，已经出现了大量商业程序库，这就降低了需要编写的代码数量。
大约10年以前，Scott Meyers在他的《More Effective C++》[Meyers97]一书中写下了类似的开场白。稍加改动，那一段文字就非常适合作为本书的开场白。其实，我故意模仿那一段写下了以上文字。从许多方面来看，我们会发现自己正处于Java的黄金时代，它所覆盖的领域是如此宽广，以至于Java似乎显得无所不能。正如C++在1996年居主导地位一样，Java在2004年占据了统治地位。
进行这种对比的主要目的是帮助我们认清形势。就在Scott写下那段话之后不到两年，C++就被异军突起的Java赶下了宝座。就像C++开发者开始变得“无所不能”一样，Java这门新语言及环境一出现就备受欢迎，并且几乎是一夜之间就取而代之。不过，Java现在面临着微软公司.NET平台的激烈竞争。人们自然是希望历史不要重演。要做到这一点，Java开发者就务必要使自己开发出来的系统能够达到、甚至超过原来的期望。而要达到这个目的，他们就需要知道如何才能充分利用自己所使用的语言和平台。
许多人在很多场合都曾经说过，要“领悟”一项技术，找到它的最佳使用方式，大约需要5年时间。C++正是如此：1990年的时候，我们只不过把C++看成一门新的面向对象语言，因而对它的使用也就沿袭了从Smalltalk得来的一些比较好的实践经验；到了1995年，我们就已经超越了这个程度，开始探究C++提供的独特功能（比如模板和STL）。当然，HTTP也是如此：1995年浏览器初次亮相的时候，我们把HTTP当做HTML的传输方式；如今，我们则把HTTP看成一种通用传输机制，用它来传输各种数据。
所以，从时机来说，Java是幸运的。它于1995年正式推出；但实际情况是，Java真正为普通开发者所重视是在1997年，或者说，直到那时Java才好到足以让那些批评者和怀疑者信服。近10年以来，我们已经在大多数情况下采用Java编写应用程序，我们已经开始认识到许多实践经验和模式，并利用它们来帮助（不过还不能确保）我们进行成功的开发。作为一个群体，我们才刚刚步入正轨。
很多情形与C++时代很相似，我们又面临着10年前在C++身上出现的类似问题（Scott已经做出了回答），只不过现在换成了Java。随着语言和环境的成熟，以及我们使用Java经验的增加，我们所需要的信息也在不断变化。1996年，人们想知道什么是Java。“不管它是什么，总之和因特网有关”是一种常见的解释。刚开始，开发者着眼于使用applet，编写丰富的浏览器客户端程序，以及利用Java的跨平台移植能力。到了1998年，他们则希望知道如何使之工作：“我如何才能访问关系数据库？如何进行国际化？如何才能跨越物理机器的边界？”如今，Java程序员又提出了更高层次的问题：“应该怎样设计企业级系统，使之能适应未来的需求？如何才能提高代码的效率，而不用牺牲代码的正确性或者易用性？如何才能实现那些不被语言或平台直接支持的高级功能？”
就好像这些还不够似的，在整个企业级系统领域中，又诞生了一个新势力，它就是Web服务。尽管Java开发者还在挑战那些更高层次的Java难题，他们又面临Web服务的学习周期：什么是Web服务？它如何工作？还有（也许是最重要的），它和Java有什么关系？
在本书中，我将回答这类问题。
关于本书中的“项”
在进行深入讨论之前，我觉得有必要指出（读者也许已经注意到了）：本书与其他书籍相比，比如《Effective Java》[Bloch]和《Effective C++》[Meyers95]，书中的“项”（或者称“条”）有很大不同。特别是本书中“项”的范围要比其他同类书中的要大得多—在这里我们没有把太多的注意力放在语言或API上，而是集中于设计层的元素和使用模式上。
这其实是有意为之，我认为，对应于范围更大的企业级应用系统，这种编排方式能够在总体上与之相一致。当然，毫无疑问，所有《Effective Java》中的“项”同样可以应用于企业级应用的构建，但仅仅停留在这个层次上还不能把握住重点，企业系统有更多的内容需要考虑，而这些内容很多都超出了语言或API范围。
例如，不成功的EJB应用通常并不是源于对某个方法或接口的误用，而是由于客户直接调用的实体bean设计不佳。设计上的问题远比实现上的问题严重，要解决它，则需要在更“高层”的角度来考量实体bean大体上要提供何种功能（关于实体bean及其细节部分的讨论请参阅第40项）。
为此，本书中的“项”试图帮助开发者在系统和架构的层次，而不是在语言的层次上认识效率。许多项对某些人来说比较熟悉，还有一些只是对读者早已熟知的内容加以提炼。这样很好：对于某些读者来说是习以为常的内容，对于其他读者来说可能是全新的，反之亦然。
另外，我尽量避免讨论常见问题。已经有很多讨论最佳实践和高效使用虚拟机和语言的书了（请查看参考书目列表）。因此，本书中不会重复那些其他书中已经讨论过的内容，除非它们在企业领域中特别适用或有某种特殊应用。
出于这个目的，我将频繁引用那些在有关企业级Java的书籍中已经建立的模式；特别是，与其他书（见参考书目）相比，我更加倾向于Fowler的《Patterns of Enterprise Application Architecture》(Addison-Wesley，2002)，Hohpe和Woolf的《Enterprise Application Integration 》(Addison-Wesley，2004)，以及Alur、Crupi和Malks的《Core J2EE Patterns, 2nd Edition》 (Addison-Wesley, 2003)。
在那些用名字来引用模式的地方，我使用标准的Gang-of-Four 模式引用格式，将页号放在引用名后面；但是，因为这些模式的来源不同，所以我也把作者的名字（比如在《Design Patterns》中用GOF来表示Gang-of-Four）作为引用的一部分。所以对Fowler的《Patterns of Enterprise Application Architecture》中的“数据传输对象”（Data Transfer Object）模式的引用就写成“Data Transfer Object（[Fowler，401]）”。
致谢
作者都愿意花很多时间来致谢；这是事出有因的。
首先，我想感谢业界的同仁，我在DevelopMentor的许多同事。Kevin Jones、Brian Maso、Stu Halloway、Simon Horrell、Dan Weston和Bob Beauchemin，他们在我编写本书的30个月中为本书的主题提供了多方面的宝贵意见。Tim Ewald、Don Box、Fritz Onion、Keith Brown、Mike Woodring、Ingo Rammer和Peter Drayton，他们通过纠正我所做的与Java无关的偏见和假设，使我深入到Java平台中。除在DevelopMentor的同事之外，我在NoFluffJustStuff研讨会上的同事，演讲人Dion Alamer、Bruce Tate、Mike Clark、Erik Hatcher、Glenn Vandenburg、Dave Thomas、Jason Hunter、James Duncan Davidson和 Ron Bodkin以及其他人，他们质疑我的结论，迫使我去证明我的断言，他们还提供了使本书更出色的建议和技巧。感谢Jay Zimmerman首先邀请我参与NoFluffJustStuff。会上很多演讲者（太多了，在此不能一一列举）或多或少都扮演了类似的角色，让我时刻自省。
第二，我要向Addison-Wesley的工作人员致敬，本书所花的时间是预计的两倍，如果没有启动这个项目的编辑Mike Hendrickson，和接手这个项目的编辑Ann Sellers，这本书永远不会完成，他们总是非常礼貌地询问本书的进展，他们的耐心远胜于我，令人印象深刻。复审人员，无论是对我放在blog上的内容，还是在后来的手稿的审查中，都做了非常出色的工作，阅读所有材料并提供了很多修正、建议。感谢Matt Anderson、Kevin Bentley、Dave Cooke、Mary Dageforde、Kevin Davis、Matthew P. Johnson和Bruce Scharlau的帮助。
写作本书既是一次热情的释放，也是一次可怕的恐怖经历。我总是在寻找这样的一个项目来表达我对企业级Java开发的想法，很少有书像以前的Effective系列一样树立榜样。《Effective C++》中，Scott Meyers为我（和其他上百万新生的C++程序员）提供了开始使用C++所需的帮助，而不仅仅是旁敲侧击。然后Joshua Bloch 写了《Effective Java》，把漂亮的“项”格式引入了Java平台。Elliote Rusty Harold进一步在《Effective XML》中沿袭了这种风格。如果有作者正在寻找一些可追随的榜样，以上三位就是最好的人选。很幸运，我从Scott Meyers处得到了帮助，他花了几乎和我写书一样的时间来复审本书并提出建议（以积极的口吻）。他的评论和见解帮助我把一些很好的思路融入到现在你面前的这本书中。Scott，我欠你一个很大的人情，既是为了过去一年中你对我的帮助，也因为10年前当我挣扎于理解C++时你给我的指导。能和你一起工作是一种特权，同时也是我的荣幸，谢谢你。
最后，当然，我必须感谢我的家人和朋友，那些时常出现的干扰和把我拖出去玩的可爱的人们，他们的追打和尖叫时常“打扰”我，把我带回到他们称之为现实世界的地方：聚会，度假，甚至连续一两个晚上玩Nintendo64或Xbox。尽管我不会大声承认，但在过去的两年中，他们让我能以健康的心态面对写作本书的压力。
报告bug，提出建议，以及得到本书的最新资料
我已经试图让本书尽可能地准确、易读、易用，不过我知道依然有提高的空间（提高的空间总是存在的）。如果你找到了任何一个错误：技术上的、语法上的、排版上的、精神上的，不管是什么，请告诉我。我会尽力保证在后续版本中纠正这些错误。如果是你首先报告了某个错误，我会很高兴把你的名字加到本书的致谢中。同样，如果你对提高本书的后续版本质量有任何建议或想法，我也洗耳恭听。
我将继续收集那些高效的Java企业编程指南。如果你对新的指南有什么想法，并愿意与我分享，我将感到非常荣幸。你可以通过一些公开的Java 编程邮件列表找到我，最好是DISCUSS.DEVELOP.COM上的ADVANCED-JAVA列表，或者你可以通过下面的地址与我联系：
Ted Neward
c/o Addison-Wesley Professional/Prentice Hall PTR
Pearson Technology Group
75 Arlington St., Suite 300
Boston, MA 02116
你也可以给我的邮箱ted@neward.net发邮件。
从第一次印刷起，我就在本书的blog上（http://www.neward.net/ted/EEJ/index.jsp）维护着本书的修改列表（包括修订、澄清、注释和技术上的更新）。要是你愿意与其他读者分享，请把意见和勘误表贴上去。
差不多了，好戏上演了！
大规模企业级系统的设计与实现难度很大，要构建高效的Java企业级系统就更加困难了。这些难题对我来说已经司空见惯。在为企业级项目做咨询的时候，我常常会遇到开发者面临的这类现实问题。在TheServerSide.com（企业级Java社区网站）上，我也经常看到针对此类问题的探讨、它们引起的困扰以及相应的解决方案。当开发者面临着J2EE这个新领域时，许多问题随之而来，TheServerSide.com正是针对开发者的需求而发展壮大起来的。它是我们的交流场所—在这里我们能够就使用的解决方案进行探讨，它也同时见证了企业级Java设计模式的发展历程。
与构建小型和单独使用的应用程序相比，企业级系统的开发是非常不同的。我们不得不去考虑那些以前确实可以忽略的问题。一旦我们要在多个用户中共享数据，就迈向了企业级系统之路。但问题也随之而来：对这些数据进行并发访问的最佳策略是什么？要在多大程度上保证数据的一致性与正确性？我们能够从2个客户扩展到50个，甚至1000个客户吗？这些都是典型问题，我觉得普通开发者在解决这些问题的时候，并不能得到足够的帮助。当然，也许我们并不应该仅仅关注于问题的答案。我们还需要学习与问题相关的各种因素，以及遇到不同问题时能够提供帮助的各种技术。有了Ted Neward的这本书，我们就拥有了这些知识，当遇到特定的问题，我们就能在解决方案中做出正确的权衡与取舍。
还没有哪本书能像这本书这样专门针对这类问题的。本书最重要的部分是，它将真正教会你两件事情。
你将理解企业级计算技术中的常规问题。
这些企业级问题并不新鲜，Ted一直专注于这个领域，并且他理解问题的核心所在。因此，即使是非Java开发者也能从本书中获益。只要你还在开发企业级系统，那么在这里学到的知识就会一直陪伴着你。语言和API也许会发生变化，但是你将会理解：构建良好架构所要考虑的问题；有哪些通信方式可供选择；如何选择状态存储的位置；各式各样的安全问题等等。
你将能够使用企业级Java平台技术来处理这些问题。
本书不仅为常规的企业级问题提供了真知灼见，而且还可以教会你采用当今的企业级Java技术来解决问题。当你把各种企业级Java技术组合在一起来考虑时，你的理解将更进一步。何时使用Web服务？消息通信能起什么作用？EJB适合做什么？本书对这些问题进行了解答。
对这些常见问题能有现成的解答，那真是太棒了。本书采用一系列高效“项”的风格来编排正好符合这一点。让我们全神贯注，体会阅读本书的乐趣吧！
Dion Almaer
TheServerSide.com主编
Ted Neward：Ted Neward: TedNeward是一名软件架构师、顾问、作家和演讲家，他为诸如Intuit and Pacific Bell和UC Davis这样的公司做咨询工作。他还著有《Server-Based Java Programming》(Manning, 2000)，同时也是《C# in a Nutshell》(O'Reilly,2002)和《SSCLI Essentials》(O'Reilly,2003)的作者之一。Ted曾经是JSR175专家组的成员。他近来经常在世界各地巡回演讲，并继续致力于Java以及.NET技术的开发和教授相关课程。
陈昊鹏 薛翔 郭嘉 方小丽：暂无简介
第1章 简介 1
J2EE的目标 2
中间件和J2EE 3
J2EE实现 7
企业计算的十大谬误 9
第2章 架构 13
第1项：优先采用构件作为开发、部署和重用的核心元素 13
第2项：跨越构件边界优先采用松耦合 17
第3项：区分逻辑层和物理层 20
第4项：数据和处理程序要尽可能靠近 23
第5项：牢记标识引起的竞争 26
第6项：使用“挂钩点”来注入优化、定制或新功能 30
第7项：面对故障时要健壮 35
第8项：定义性能和可扩展性目标 38
第9项：只在事务性处理中使用EJB 41
第10项：先测量性能，再进行优化 43
第11项：认清“提供商中立”的成本 47
第12项：内置监控功能 50
第13项：内置管理支持 55
第14项：部署要尽可能简单 60
第3章 通信 63
第15项：理解你所做的通信选择 63
第16项：仔细考虑你的查找 67
第17项：识别网络访问的代价 71
第18项：优选上下文完整的通信风格 76
第19项：优选数据驱动的通信而不是行为驱动的通信 82
第20项：避免为远程服务请求去等待响应 87
第21项：考虑构件的划分以避免任何一台机器负载过重 90
第22项：为了开放集成而考虑使用Web服务 94
第23项：大批量地传送数据 96
第24项：考虑定制你自己的通信代理 100
第4章 处理 103
第25项：保持简洁 104
第26项：优先采用规则引擎去处理复杂状态的评估和执行 106
第27项：优先为隐含的非原子性错误场景采用事务性处理 110
第28项：区分用户事务和系统事务 114
第29项：最小化锁窗口 117
第30项：当持有锁时不要让步给在构件之外的控制 123
第31项：理解EJB的事务关联 128
第32项：优先使用本地事务而不是分布式事务 130
第33项：为了更好的可扩展性而考虑使用乐观的并发机制 132
第34项：为了显式的并发控制而考虑使用悲观的并发机制 137
第35项：考虑使用较低的隔离级别以获得更大的事务吞吐量 140
第36项：面临回滚时使用保存点来保留部分工作 143
第37项：当有可能避免锁定区域时就复制数据源 145
第38项：偏爱不可变的，因为它不需要任何锁 147
第5章 状态管理 151
第39项：节省地使用 HttpSession 152
第40项：使用对象优先的持久化来保存你的领域模型 155
第41项：使用关系优先的持久化来显示关系模型的威力 158
第42项：使用过程优先的持久化来创建一个封装层 165
第43项：识别对象-层次结构阻抗失配 167
第44项：使用进程内或本地存储以避开网络 174
第45项：不要假设拥有数据或数据库 177
第46项：惰性加载不频繁使用的数据 179
第47项：积极加载频繁使用的数据 182
第48项：批处理SQL的工作以避免往返访问 183
第49项：了解你的JDBC供应商 186
第50项：调整你的SQL语句 189
第6章 表示 193
第51项：考虑富客户端UI技术 194
第52项：使HTML短小精悍 200
第53项：表示与处理相分离 202
第54项：内容与样式相分离 207
第55项：预生成内容以最小化处理过程 209
第56项：尽早验证，尽量验证 211
第7章 安全 219
第57项：安全是一个过程，而不是产品 221
第58项：记住安全不仅仅是预防 224
第59项：建立威胁模型 225
第60项：做不安全假设 227
第61项：总是验证用户的输入 231
第62项：打开平台安全机制 238
第63项：使用基于角色的授权 240
第64项：使用SignedObject以保证序列化对象的完整性 247
第65项：使用SealedObject以保证可序列化对象的机密性 250
第66项：使用GuardedObject以保证对象的存取控制 252
第8章 系统 257
第67项：主动释放资源 257
第68项：调整JVM 262
第69项：为版本并存使用独立的JRE 268
第70项：识别类加载器的边界 272
第71项：理解Java的对象序列化 278
第72项：不要对抗垃圾收集器 283
第73项：优选容器管理的资源管理 290
第74项：使用Reference对象来扩展垃圾收集行为 293
第75项：不要担心在服务器上的JNI代码 304
参考资料 307
