首先感谢Hibernate 31网友的回复，我喜欢这样的交流，为什么呢？因为我发觉你是在仔细阅读本书的部分章节后再发表自己的看法，这种
交流显得格外的有的放矢，有根有据。其实在真正开始这本书的创作之前，我有着一段较长时间的犹豫的徘徊，因为我深知Spring技术涵盖面
而相当宽广，它几乎涵盖了Java企业应用开发的各个方面，虽然我前后从事近10年的Java开发工作，但是在面对这样一个宽广的命题面前还是
不免显得慌张。这本书是从2006年5月开始筹划的，结笔于2007年6月，从筹划到全书成稿历时一年多的时间。我的上一本拙作《精通JBuilder
2005》是在业余时间完成的（BTW：拙作被《程序员》曾评为JBuilder 2005的百科全书，作者获电子工业出版社2005年度优秀作者），但我深
知这本书在知识点数目，技术涵盖面上远非JBulder可以相提并论，因此我从2006年11月为了能够全力投入本书的工作中，专门辞职出来，全职
投入本书的创作中。
拙书共23章，800余页，涉及的内容比较多，前后经过了4次调整，本书编辑江立先生也对本书进行了2次省校。考虑到技术书籍适时性需求
比较高，我们没有进行进一步的省校处理。虽然我们尽了最大的努力以保证将错漏降到最少，但是书中一定还会有一些不足和偏差之处，敬请
读者朋友谅解并代为匡正，作为一个弥补的办法，我们也会进行后续的错误跟踪，通过在线更正表的方式为书中存在的偏差和错误进行修正（
在线勘误表将在后续提供）。
对于Hibernate 31网友的两点问题，我有一些自己的看法，和网友们一起斟酌：
1.对于书中的“开发人员可以使用简单Java对象轻松拥有EJB一样强大的功能”这句表述我认为基本上是正确的，关于Sprnig和EJB和争论可
谓由来已久，各大技术论坛，博客都曾经为此陷入两派分争的混战中。Spring的诞生应该说和EJB有着很大的关系，EJB功能强大但框架本身过
于笨重，它力图用一把厚重的牛刀处理鸡狗牛羊所有的屠宰工作，Rod Johnson看到并身切体会了当年许多程序员面对EJB的困苦，并在对EJB逐
一进行辩证批判后才创造了Spring。EJB的核心大概包括以下几点：
1)声明式事务；
2)全局 事 务；
3)透明持久化；
4)分布式对象。
Spring通过AOP实现了声明式事务的支持；通过集成JOTM(Java Open Transaction Manager)，Sprnig可以拥有全局事务的能力，透明持久化
Spring通过集成Hibernate，JPA（包含在EJB技术规范中）等框架提供了实现。Spring唯一不能做的是分布式对象的支持，分布式对象基本上可
以说是一个叫好不叫座的东西，很少有项目需要使用分布式对象。Rod一再提醒开发人员在使用分布式对象之前一定要想想是否有其它更好的办
法，因为分布式对象会使系统框架的复杂度曲线徒然递增。所以我们说Spring使用简单对象拥有EJB功能的说法是站得住脚的。关于EJB和
Spring之间的关系，在Rod的经典著作《J2EE Without EJB》进行了深入的逐一分析，有兴趣的作者可以进一步的参阅。
另外的一个方面是Spring非常强调整合，而非自己去发明一个相同的轮子，因此在使用Spring时确实要了解相关的技术，因此本书使用了很
大的篇幅用于讲解Spring如何集成第三方技术的内容。对于Hibernate 31网友所说的“离开JavaEE容器服务和被集成的其它服务，你能指望
Spring完成什么事情？”我觉得有一定的道理，但我并不完全认同，Spring虽然强调整合，但它自己也有Web层（Spring MVC），服务层（IoC
，AOP声明事务等）、持久层（Spring JDBC）分别提供了实现的方案，另外Spring不一定要部署在Java EE容器中，只要使用类似于Tomcat的
Servlet容器中就可以了。还有，本书绝对没有妄言Spring是万能的，就连Rod Johnson也说Spring不是为要替换EJB，而是为Java企业应用开发
中提供另外一种轻便的选择。
2.从严格意义上来说，什么东西构建在什么东西基础上确实是很难定论的，因为任何一个技术都是在众多支撑技术的基础上发展而来的，所
以“因为HTTP、JMS、STMP等协议都构建在TCP/IP基础上”的表述多严格意义上来说确实是不正确的。但是理解任何一句话的意思都需要上下文
环境，否则就容易断章取义，甚至原义和主旨荡然无存。
这句话出现在本书第16章：在Spring中使用Web Service，P519上的实战经验小文中，这段小文是向读者介绍一个抓取TCP/IP报文的小工具
（TcpTrace），因此本段的主旨是要说对于基于类似HTTP JMS SMTP等协议或规范的应用来说，如果你要查看底层报文的细节，以便调试、排错
，那么你可以使用TcpTrace来达到目的。按照OSI（Open System Interconnect）分层体系来说，应用层建立在网络层和传输层的基础上，而一
般情况下TCP/IP（传输层和网络层）是网络传输的代表，所以从这个角度上来说，JMS构建在TCP/IP上的说法不会有大的问题。事实上作者当然
知道JMS是一套API规范，在本书第15章 开篇的第一段，就有一段这样的定义：“JMS（Java Message
|
