. 第17章 JSP和Java Servlet的关系与部署
第18章 基于容器的安全和Tomcat领域（Realm）
第19章 使用JSP操作文件系统
第20章 使用JSP结合XML开发
第21章 使用JSP发送和接收电子邮件
第22章 JSP事务、JTA和关键应用程序开发
第5篇 JSP标签、动作和实用功能应用篇
第23章 在JSP网页中使用JavaBeans
第24章 使用统一表达式语言（Unified EL）
第25章 使用JSP标准标签库（JSTL）
第26章 JSP的XML语法格式和标准动作标签
第27章 创建JSP自定义标签
第28章 深入JSP网络应用程序基础架构和MVC架构
第29章 JSF入门——使用基于MVC架构的实现
附录A JSP内建对象速查卡
附录B 常用字符集速查表
附录C 测试题答案
附录D 参考文献及资料来源

.数据服务层不仅仅是数据库，而且还包含了其他可以用做数据的资源，例如XML。XML已经成为因特网间标准的数据交换格式，它也正在成为数据存储的标准格式。
展示层、业务逻辑层、数据服务层构成了当前万维网应用程序的基础架构，它们也被统称为“三层架构”。
实际上你不得不了解它，它是进行万维网应用程序开发的认识论基石，也是实践的指南针。设想存在一个不遵守该指南的万维网应用程序是不可能的，同样，设想任何不了解该指南而进行的万维网应用程序开发也是近似荒谬的。
在“开发王”系列图书中，我们针对不同的万维网技术，对三层架构做了精确的、同一的阐述，这是你在全球其他任何地方都无法完整系统地获得的。不管你愿不愿意承认，你永远都无法摆脱它。
在万维网软件开发日益区分为泾渭分明的三层架构后，市场和技术并未停止它们前进的步伐，它们依旧在不断地向前延伸。在技术厂商的推动下，在万维网的技术社区的遥相呼应下，三层架构中的每个层次都为了某些特殊的应用不断向其邻近的层次延伸，首当其冲的便是展示层向逻辑层的渗透。
展示层利用客户端脚本和浏览器插件技术开始分担业务逻辑层的部分运算，而且，它们还有一个响亮的名字，被称为“富客户端”。
JavaScript、Flash和Java Applet目前是实现展示层分担业务逻辑层运算的主要软件技术。JavaScript因为AJAX解决方案和DHTML解决方案的结合而“重获”新生，而Flash凭借其分布广泛的Flash Player插件及高效的开发环境而正日益成为下一代万维网客户端运算的核心。与此形成鲜明对比的是Java Applet技术，因为其开发的难度极高，以及其客户端运行环境自身的原因，从其诞生那天起就从未引人注目过，今天，它依然被搁置在某个角落。
正如你在“开发王”系列图书中所看到的那样，我们已经将JavaScript、Flash技术完全融入到整个万维网开发体系中，现在你理应将它们视为一个整体，而不是再孤立地去看待它们中的任何一个。
完整系统的万维网知识体系能为你带来什么
是的，这个问题是每一个开发者、雇主、任课教师和学员所关心的，而且，很显然，每个用户理应关心。实际上，每一个人都应该问自己这样一个问题。
用户还会问：你为何为该套书起名为“开发王”？它(的内容)真的如描述的那么好吗？
这真的很直截了当，而且我本人也喜欢直截了当。当然，每一个开发者也都有权利这样提问，而我也正想在这里为大家分享这个问题的答案。
这本书为何被冠以“王”
每本图书都可能会被冠以“王”这样的词汇，以表明这本书是多么伟大，但是并非所有图书都能名副其实。
作为这套书的作者，我的眼中只有“王”—这就是我的回答，并且，毫不犹豫。
当然，智者从不相信信口而来，每一个读者理应都是智者，而唯一值得相信的理应是事实。
这套书从最初的准备，到今天的出版，前后经过长达6年的时间，前后经过了数以千计次大小修改。你现在看到的这个序言我也写了二三年时间，序言的目标就是做到“增一字嫌冗余，减一字则无从下手”。
写作的过程是漫长而痛苦的(偶尔也会有快乐)，出版的历程也是如此。如果作者想出版一本书，就必须首先给出版机构一个策划书—也就是这本书的基本情况和设想。
每一个作者都会想该如何打动出版机构出版它，这是毫无疑问的。
你得苦思冥想……
但实际上，这很简单，你必须告诉他们这本书是最棒的，我想，除此之外别无他法。
如果没有证据，我想你也根本不会相信，更何况那些“眼疾手快”的编辑呢？
当然，那是因为我给他们提供了充足可信的证据。如果你有某个事实作为证据，我想你也可以这样做，让我们来看一个简单的事实吧：
根据JavaBeans规范的要求，一个JavaBeans必须支持序列化或者外部化，这在JavaBeans规范5.5节的第一行就明确地定义了这个要求。
如果我没有记错，那上面白纸黑字写着下面的一行英文：
All beans must support either Serialization or Externalization.
这意味着只有实现序列化或者外部化，或者继承于某个实现了序列化或者外部化的基类，才能将一个Java类视做JavaBeans。但是遗憾的是，当你在查阅有关Java网络开发(包括JSP开发、JSF、Servlet、Structs等)的图书和资料时，又有多少图书和资料教你遵守规范的要求呢？绝大多数的Java网络开发图书和资料在没有实现序列化或者外部化时就告诉我们年轻的开发者：这是一个JavaBeans。很明显，这是跟我们年轻的开发者开了一个天大的玩笑！
当然，仅仅是玩笑尚不足对我们年轻的开发者构成致命的打击，关键是按照这样的阐述开发出的应用程序将会给雇主造成致命的、无法挽回的损失。
由此我也想到，曾经有开发人员在读完一些计算机图书，再经历自己多年的开发实践后有以下感慨：国内很多技术图书领域都是这样，好多计算机图书只要最初的那一本错了，后面的就全是Copy，甚至都不去关心事物的本源是什么。
但，这仅仅不过是悲剧的开端……
如果究其产生的根源，那么基础认知上存在根源性错误是导致这种情况发生的直接原因。
下面要介绍的这个认识和实践的错误显得更加复杂，可能对于一个初入门的作者和译者而言显得有些难了，因为要想理解JavaBeans的真正作用对他们来说还是有些难度的。
归于JSP规范并未规定[jsp:useBean]动作标签必须使用JavaBeans，所以大多数的Java应用程序服务器(JSP实现)在转化阶段并未对其进行鉴别(实际上，就我所知的Java应用程序服务器中，没有一款对其进行鉴别)，这导致不计其数的开发者在使用[jsp:useBean]动作标签时将一个简单的Java Class当做JavaBeans来使用，而不是有甄别地去应用这个动作标签。
仅仅是[jsp:useBean]动作标签中有useBean这个英文单词，于是就造成了这样巨大的错误。
你可以看到，在《JSP开发王》这本书中，我甚至不建议用户使用[jsp:useBean]动作标签。当然，如果非要使用它，那么就必须遵守《JSP开发王》提出的几点约束。
严格遵守规范和标准，警惕低级错误可能造成的悲剧
JavaBeans问题的发生是整个Java网络开发领域内的悲剧，实际上也是整个网络开发领域内的悲剧。连这样基础的东西都漠视，视标准和规范的要求于不顾，更不要说了解使用JavaBeans的主要目的是什么了，那么我们可爱的、年轻的开发者如何才能得到正确的网络开发知识呢？
或者，每一个开发者都应自问：我如何才能为雇主开发出负责任的应用程序来呢？
开发者一定要破除“雇主付钱请我来编写程序”的错误观念，这实际上是忽略了后面的这句：“目的是我的程序能使雇主有更大的回报”。
你可以将一个范例代码写错，就像写一个错别字，可能在所难免，但你绝不能犯如此的低级错误，这是影响你整个开发体系的大事。
每一个人都知道，悲剧显然不是由某个特定的错误引起的，而是由某个根深蒂固的错误思想导致的，如果这种思想不除去，挡在开发者和雇主之间的魔障亦不会消除。它也会逐渐抽干雇主多年努力所换来的投入……当雇主独处一室苦苦思索时，你是不会体会到的。
错误还在蔓延？
如果仅仅是这样一个小事例，尚不足使这套书被称为“王”，更多的基础性错误还继续在用户的软件开发知识体系中间蔓延，它们正伺机阻碍你企业的发展。
如果说JavaBeans仅仅是个偶然性的错误的话，那么在基本验证和网络应用程序安全这样最基础的问题上，你同样几乎找不到一本像样的教材和资料能够完整系统地正确阐述它，更不要说其他的安全措施了。
这个错误在ASP、ASP.NET、JSP、PHP开发领域内存在的时间之长，几乎可以与这些语言被发明那天起同步。导致这个错误发生的根源与导致JavaBeans错误发生的根源惊人地相同，都是根本不顾规范的要求—只要最开始的一本书错了，那么后面的全是Copy。
错误也是积累的，在三层架构万维网应用程序的展示层，如何正确认识HTML、CSS、JavaScript和Flash已经成了当务之急，富客户端应用程序已经成为当前因特网应用程序开发中极受重视的领域，因为它能给消费者带来最佳的客户体验，而这也正是雇主所需要的。
HTML这个最基础并且最简单的语言可能用户从未认真审视过—可能只是因为它简单了，一个承担了内容结构和内容呈现责任的语言如何在新的体系面前被正确理解呢？CSS究竟使HTML发生了何种变化呢？大多数的教材都是教授开发者和设计者怎样使用CSS去呈现网页，却忘记了这样做的根本是什么，好像这根本就不应被考虑。好在，现在该是结束的时候了……
AJAX解决方案的出现仿佛使JavaScript“重新”回到人们关注的视线中，但如果没有DHTML解决方案作为铺垫，AJAX又能做什么呢？答案很简单：它什么也做不了。..
AJAX和Flash现在是富客户端的主流，但是，如果你不能完整系统地正确认识三层架构的基本体系，如果不了解C/S和B/S的区别，那么设想能真正理解AJAX和Flash用于开发富客户端应用程序只能是空想。
虽然Flash已是一个成熟的体系，但是，目前Flash开发对很多开发人员来说还是一个较新的领域。两年前，很多开发者还在喋喋不休地争论AS2和AS1的优、缺点，争论往往意味着还不能正确地认识它们的真正实质。所以，两年前，在拙著中就完整系统地介绍了这方面的知识，帮助用户完成了这一基本认知。现在，它已经被完全融入到这个万维网知识体系中，过去的大批量错误认知已经被更正，我们还建立了完整的基于时间轴的Flash应用程序开发的理论体系，所以现在看起来，这个领域内的灾难并没有AJAX领域那么深重。
这些错误的发生不但使得开发者深受其害，重要的是，它有可能使得雇主的网络应用程序因此而遭受重大挫折，并失去客户的信任。
在这里，我提到了很多不应该发生却又事实上发生了的，也是现在正在发生的悲剧，而更为重要的是，对规范、标准、实现、实践的完备性认识还有很多、很长的路要走。如果没有完整系统的知识体系，开发者还不知道要在“黑夜”里摸索多久。
想一想，除了这里提到的错误，还有哪些错误被隐藏起来了，你还未发现呢？这也是为何我在书中对易出错的部分做了突出显示的原因。
也许不远处真的就有冰山出没……
当我看到有无数的教材和资料在长篇累牍、多达数十页的论述抽象类和接口的区别时，我真的感到悲哀，是在为整个使用面向对象进行软件开发的开发者们悲哀。当我两年前用一句话来区分抽象类和接口时，可能并没有人真正地去注意过它，虽然，在拙著中还用了文字加粗……
就像6年前，当在拙著中第一次提出Flash Player虚拟机的概念时，我想也并没有多少人真正注意过这个问题；但是在2年前，我在拙著中第一次明确阐述了在ActionScript 2.0和ActionScript 1.0中存在的基本错误认知，现在，两年过去了，我想再也没有人会去犯同样愚蠢的错误了。
想来应该有不少任课教师应该可以给他们的学员讲授正确的Flash开发了。
但是，如果我说很多开发者连Flash基本的变量作用范围都不能搞清楚，你是不是很诧异呢？
是啊，两年前我也经常听一些人说他们会Flash开发，可是我却发现他们连最基本的变量的作用范围都一知半解，如果连这个都不能系统掌握，能开发出一个完美的程序来吗？又如何为雇主创造价值呢？
想来，我的前一本Flash作品已经有不少人看过了，但是，同样，大多数Flash开发人员可能并没有得到这个知识。
是啊，因为并没有特别声张这件事，就是想看一看用户究竟有没有真正去学习Flash开发，去认真获取那些最真实的东西。
但是，这终究还是造成了遗憾——当拙著第一次为整个ActionScript语言带来了完整系统的变量作用范围的介绍时，可能很少人去注意它。
现在，新版的《Flash开发王》我想不会再有人错过了。
有时候，夜真的很黑、很深沉，它会淹没你，并让你忘记你自己……
开发王系列图书有两个最基本的基石
当然，即使有点点滴滴的、零星的低级错误，也不能说本书不能称为“王”。开发王必须有两个最基本的基石，除此之外别无其他，这两个基石是：
帮助用户建立正确的认知
帮助用户建立完整系统的知识体系
正确的认知就是一切的根本
正确的认知就是一切的根本，这无须进行任何说明，而关键是什么是正确的认知。
认知有两个层面的意思，一个是认字，一个是知道。
每个人都是从认字开始的，这毫无疑问，认字就是了解事实是什么，知道就是怎样做才能正确地认识到这个事实。
我们经常听到一个成语“授之以鱼，不如授之以渔”。是的，不单单是应该告诉用户一个事实，还要告诉他们怎样去正确地认识到这个事实。
事实往往是某种规定，就像你学习汉语拼音那样，a这个英文字母就是发音为“啊”。当然，对于应用程序开发来说，这个规定性或由某个标准定义，或由某个规范定义，或由某个程序的业务逻辑所要求，而你的“认字”也就是了解这种规定性究竟规定了什么。这个“认字”很枯燥，你只有死记硬背，完全遵照，就像完全遵照JavaBeans规范那样。
现在关键点是：这个死记硬背的事实用户如何才能认识到它呢？这真的很难办。为此我们提出了3个最简单、最基本的问题可以帮助你一举解决这个难题：
这是什么？
为什么是这样？
该怎样做？
你在“开发王”每一本书中，甚至每一章中都可以看到或体会到这样的3个最简单、最基本的问题。
完整系统的知识体系就是顺理成章的一切
正确的认知往往是一点一滴汇聚起来的，如果这些点点滴滴的认知被相互肢解开来，那么最终形成的则是一片混乱。这就需要有一个知识体系将这些点点滴滴的认知相互关联起来形成完整系统的知识体系，这也是日渐庞大的万维网的必然要求。
正如你看到的那样，我们将万维网应用程序的知识体系建立在三层架构的基础之上，在这个最基本的认知和知识体系下不断将知识延伸。
我不想在这里对什么是“完整系统的知识体系”进行过多的介绍，因为每个人都理解它的字面意思，也理解它对每个开发者都是梦寐以求的，而关键是“完整系统的知识体系”的内容是什么。除了应该牢记这篇序言前面所介绍的万维网的技术史和万维网的基本知识结构，我也不想在前言中再多费笔墨，因为知识体系往往融入在各个知识点的相互结合中，不是一两页纸所能阐述清楚的。
如果能用几页纸阐述清楚那就好了，不过话又说过来，一个用几页纸就能阐述清楚的“完整系统的知识体系”能可信吗？
“完整系统的知识体系”包含了某个领域内的完整内容，不可能使用几页纸就能阐述清楚，而且领域越广，所需要的笔墨就越多。例如，针对JSP，你可能需要用一本书来介绍，但对整个万维网应用程序来说，你可能需要10本书甚至更多，我想每一个用户都不难理解。
谁将从这套书中受益开发者、雇主、主讲教师、学员都将从“开发王”系列图书中受益
开发者是理所应当的最大受益者
毫无疑问，“开发王”这套书是最终面向开发者的，不但初学者，而且资深的开发者也应视它为必读之作。在正确的认知和完整、系统的知识体系面前，初学者和资深的开发者处于同一起跑线上。
“初学者”能够在开发伊始就将技术建立在正确的认知的基础上，并且循序渐进，获得完整系统的知识体系，这不但可以加速学习进程，而且也是正确开发的保证。
“资深的开发者”虽然在实践过程中获得了很多好的实战经验，但未必能够运用自如，这就是过去混乱不堪的知识体系和错误的认知共同作用的结果。如果不砍掉错误和混乱，必然使自己的开发认识踌躇不前，最终走火入魔也未必不可能。
当然，如果你有错误的认知，并且编出了错误的应用程序，那么就要小心了，应该尽快通读本书，趁雇主还未发现之前将漏洞补上。
雇主是最终的受益人
雇主首先要关心的是如何在有效的投入情况下获得较高的产出，也就是如何实现经济产出。
正确的软件开发来源于正确的认知和完整系统的知识体系，这是毫无疑问的。
正如你前面看到的，正确的认知是编写正确程序的关键，试想一个没有实现序列化的JavaBeans将会带来什么样的危害？假设是一个银行结算程序，资金(一个JavaBeans)汇出去了，但是却因为中间运算出了故障而死机，这个时候自动保护装置本应该能够恢复JavaBeans的状态(也就是你的资金)，但却因为拙劣的错误认知进而编写出拙劣的程序，这一程序从而又导致这一恢复过程无法完成。对一个企业而言，这是致命的一击—连自己的基础设施都无法保证，企业信誉便荡然无存。
实现经济产出的另一个要关心的事情是如何实现团队协作，这个时候正确的认知和完整系统的知识体系显得尤为重要。
现在，抛开那些点点滴滴的零星错误(虽然它们也很重要)，让我们眼光看得更长更远，即使是组织行为学的经典理论也认为仅仅是团队精神和团队意识并不足以成功实现团队协作，共同的技术知识和技术能力才是团队合作得以有效进行的基础。
共同的技术知识和技术能力不但能够很容易使成员清楚要达到的目标，而且相互间也清楚自己应承担的责任和应该实现的功能。因此，一个完整、系统的知识体系对于团队合作而言便显得极为重要。仅仅靠热情，员工们能够合作得像一个团队吗？恐怕员工们自己也说服不了自己，更何况位于组织核心的人力资源主管和信息技术主管呢？
人力资源主管和信息技术主管作为雇主的代表应该将此书作为实现团队合作的技术知识和技术能力评估的“客观指标”。
人力资源主管和信息技术主管作为雇主的代表，同时也是这一知识体系的受益者。这一知识体系首先使你可以认识到一个合格的开发者所应具备的基本知识技能。
除此之外，这套图书包含了大量的测试题，可以帮助你从客观的技术层面上选择那些适用于本企业的开发人员，以及用于员工考评和员工的再培训。并且这些测试题可以提高你的工作效率，从而为你和你的雇主节省成本。
学员应该拥有这套书
虽然学员大多数选择教材都还是为了应付考试，但是不管是用于考试还是用于以后从业于因特网，“开发王”系列图书是建立在正确的认知和完整系统的知识体系之上的，这符合最一般的逻辑要求，有利于记忆和总结，它会加快你的学习进程，提高效率，节省时间。
虽然教材并非由学员自己来选择，但任课老师一般都会非常尊重学员的建议，你应告诉他你看到的真实的东西，以及你想到的东西，如果你这样做了，就理应得到赞许。
如果你发现了教材中的一些错误，就应该及时提醒任课教师，并且也应该和同学切磋这个认识是否正确，这个过程也是培养团队协作精神的过程。
“开发王”系列图书不但适合作为教材，也适合作为自学用书，在3个最基本问题的指引下，学员也可以迅速有效地掌握万维网应用程序开发的知识。并且，书中大量的范例可以用于实际应用程序开发和设计中，每章后面的习题可以用于巩固所学的知识。
任课教师应该使用这套书作为
教材以赢得学员的信任
主讲网络开发的任课教师应该成为正确认知和完整系统的万维网知识体系的传播者，正确的认知和完整系统的万维网知识体系是相对于错误认知和混乱的知识而言的，在教学上，混乱的知识往往与肢解式的授课方式紧密连在一起。
肢解式教学往往是要么盲目地对某个语法进行割裂式的使用方法讲解，要么沉迷于对某个具体范例的长篇累牍的分析之中。这种教学虽然容易让学员沉醉于暂时的范例成果而“沾沾自喜”，但也往往让他们迷失在这种“沾沾自喜”当中，从而忘记软件开发的基本事实。
这样做的教学目标看似明确，其实贻害无穷。
“庖丁解牛，不见全牛”是流传几千年的老故事，讲述了庖丁最初解牛时“所见无非全牛者”，而其“所好者道也，进乎技矣”，这个“道”就是指要完整系统地把握一件事物，然后再勤加练习，到“三年之后，未尝见全牛也”。
任课教师应该将学员从这种“沾沾自喜”的悬崖边缘拉回来，授以庖丁之“道”，勉励其自学以成庖丁之“技”，并最终集万维网应用程序开发之大成。
任课教师要做到这一点，一个重要的方式就是将过去肢解式的授课永远忘掉，那些肢解式的教材也理应被扔到垃圾堆中。
“开发王”这套书能够帮助你完成你的教学目标，这套书的一个编写特点就是其完整系统的知识体系，它能够帮助学员掌握“道”之本质。
为了使教学能够更顺利地展开，并便于学生课后自学，我们在每章的前面对本章内容做了总结，而且，每章的后面提供了习题和小结。
以坚实恒定的基石应对变化
对开发者、雇主、主讲教师、学员来说，市场的不断发展变化是不可避免的，市场的变化进而催生技术的不断发展变化，这些变化对每一个卷入IT产业的组织和人员都提出了挑战。
企业如何才能迅速响应市场变化带来的挑战呢？开发者如何才能迅速应对企业的新需求呢？在面对新技术时，如何将教学工作与新技术迅速衔接起来呢？
为了保持竞争优势并更迅速地响应市场变化，人员的技术知识和企业的业务必须保持流程的一致性，以实现更大的柔性和扩展性，而这一切必须建立在一个“坚实恒定”的基石之上才能说有可靠的技术保证。
在“开发王”这套技术丛书中，每一个参与者都将看到这块“坚实恒定”的基石，这个基石被称为“完整系统的万维网知识体系”，在这个基石之上实现的柔性和扩展性必然是可持久、可度量的，且可以应对迅速的变化。
完整系统的万维网知识体系针对变化提供了更多机会，无论变化多么复杂、多么迅速，“开发王”都能够帮助简化它们，从而轻松获取竞争优势。
从此，变化不再令人苦恼，相反它为你带来一系列机遇：灵活性、业务一致性，当然，还有竞争优势，不管是对个人，还是对组织……
作者的话
从开始准备写作到本套书的出版，前后经历了近6年的时间，也经历了多个软件版本变迁，以及万维网的沉沉浮浮，在这紧张的几十个月后，本套书终于得以问世。我希望能通过本书给万维网应用程序开发者和设计者带来无限广阔的、基本的、正确认知和完整系统的网络开发知识。
本书在写作过程中参考了“大量”的参考资料，包括数十份标准和规范，也包括作者多年创作和开发体验的结晶，所有范例也都经过了严格的测试，从而确保了内容准确翔实。
文章中提出的任何观点和主张都必须经得起事实的考验。
虽然如此，错误和不足也在所难免，恳请读者不吝赐教和指正，我们一定会全力改进，在以后的工作中加强和提高。
本书在创作和出版的过程中得到了电子工业出版社易飞思公司的大力支持，感谢他们在图书的设计及内容审定方面所给予的指导，同时也感谢为本书的出版而努力工作的出版社其他工作人员。
怎样阅读这套书
这套书的知识结构(包括范例)，前后衔接的逻辑非常紧密，所以，这里特别提示用户不要试图跳跃章节阅读，这将恐怕使你欲速而不达。
保持与作者沟通
有时与作者沟通是十分必要的，用户可以从作者处获取知识的更新，或者勘误(如果书中有的话)，同时也可以让作者了解到你的想法。作者目前有以下联系方式：
E-mail(首选的推荐方式)
zhang-yafei@hotmail.com
BLOG留言(简体版和繁体版)
http://cn.zhang-yafei.com
http://tw.zhang-yafei.com
发送邮件的注意事项
如果你发送邮件，请在标题处以以下格式书写，以利于作者分类处理。
假定你对本书第2章中的内容有疑问，只需在标题处如下书写(请不要在标题处添加其他内容)：
JSP2008_2_Chapter_02
假定你对本书第12章中内容有疑问：
JSP2008_2_Chapter_12
假定你对本书附录B中的内容有疑问：
JSP2008_2_Chapter_B
我们喜欢听到你的声音！...
编著者