先谈谈《精通EJB》这本书，Ed Roman是著名网站TheServerSide.com的CEO,自己也拥有一家专门从事中间件开发的公司MiddleWare, 另外两个合著者Tyler Jewell是BEA的J2EE专家，Scott W. Ambler也是面向对象设计和敏捷建模的大师，由这样的专家写出来的书籍，的确堪称经典，让人看得放心，读得顺心。
整个J2EE架构是个非常复杂的架构，而《精通EJB》用461页（中文版）就把EJB从底层原理到实际应用部署都讲的清清楚楚，实在难能可贵。作者采用循序渐进的方式讲述EJB, 构造了一个非常好的学习EJB的思路，作者很细心的考虑了读者看书时感受，告诉了读者什么时候该关注什么内容，什么内容可以暂时放在一边。在内容讲述上，作者基本采用提出问题，回答问题的方式，语言简明扼要，却又一语中的，让你心领神会。读完此书，的确能让你掌握EJB了(本书原名Mastering Enterprise JavaBeans，所谓精通其实就是掌握的意思，要精通一门技术，哪是读完一本书就能做到的呀)。
本人从事Java的设计和开发也有三年了，但一直只做前端网站服务器和Java应用程序，对EJB一直只有耳闻，并不十分了解，随着业界对J2EE平台的不断投入，大量优秀的设计思想都在EJB平台上得到了应用，所以我也非常想在以后的业务系统开发中采用EJB技术，但一项新技术的采用，绝不是因为它很时髦就采用的， 应用一项新技术以前，你一定要先了解它的基本原理，它能够达到的功能和性能，有什么优点和缺点，你的开发人员能不能掌握它，你能否把自己独特的技术优势应用到这个平台中去等等。《精通EJB》这本书可以达到这个目的，象我这样希望考察EJB的人都可以看看这本书，从没有接触过EJB，希望将来成为EJB开发人员的程序员也应该看看这本书。
但在买这本书之前，你应该注意以下几点：
1、你应该有Java的基础知识，至少开发过一些Java应用程序，最好开发过Java的企业信息系统，对网站技术、数据库技术、通讯等都有个基本了解，如果你只是个刚毕业的菜鸟，现在还不是看这本书的时候
2、这本书是对EJB技术的全局介绍，它是让你了解EJB的书，看完这本书，并不能让你真正进行EJB开发，你至少还应该读一些关于EJB设计模式的书，比如《J2EE核心模式》等，避免对EJB技术的盲目应用，EJB是一项复杂的技术，运用得不好会适得其反，给你的项目带来灾难性的后果。
3、EJB只是一种规范，看完这本书你就知道，企业应用的很多因素，比如负载均衡、容错、事务管理策略、系统监控等，EJB本身并没有做具体的实现规定，很多方面必须依靠J2EE平台生产厂家来实现,而不同的J2EE平台厂家，在实现上有很大的差异，要真正提供一个好的企业应用系统，选好你的J2EE平台产品是非常重要的事情。《精通EJB》这本书专注于EJB技术本身，对实际的J2EE产品基本没有涉及，要真正应用EJB技术，你应该还要去考察具体的J2EE平台产品，看厂家是如何解决上面提到的那些具体问题的，厂家的产品仅仅通过J2EE认证，并不能保证能够用它就能构造出性能卓越，运行稳定的系统。
EJB却不是个好技术
遗憾的是，看完这本书，却让我做出了放弃EJB的决定,J2EE是一个非常好的企业应用设计规范，它采用了大量优秀的设计思想，但非常遗憾，作为J2EE的核心，EJB的设计方案让人失望，J2EE设计的目标，就是让企业应用开发人员能够在一个规范的平台之上，不用考虑具体的技术问题，专注于业务逻辑实现，就可以开发出性能、稳定性、可管理性各个方面的都达到较高水平的系统。但我很难想象，在EJB技术平台能够实现这个目标,实际上，它存在根本的缺陷:
1、EJB技术的一项最根本的技术缺陷来自于对象序列化技术，对象序列化技术是EJB跨平台通讯的基础，所有的EJB之间通讯都依赖了对象序列化技术的应用。从设计架构上看，这是个简单清晰的的设计，通过对象的序列化实现了对象在多个进程之间的复制传递。但非常遗憾的是，设计者对于Java平台对于对象序列化的实现的考虑却做的很草率，对象序列化的性能很差，我想很多人可能没有注意到这一点，我也是在做到底层的开发时才发现这个问题，我们开发的一个企业应用系统必须要实现跨Java平台和C++平台之间的访问，为了实现跨平台通讯，我们设计一项通用的数据表达格式，采用了XML格式实现了多种平台之间的数据传输，大家知道把数据打包成XML格式，再从XML格式解包系统开销是比较大的，会导致通讯性能下降，因此我们对此进行了优化，刚开始的想法是在相同的平台之间通讯时，将数据打包成二进制格式传输，只有在不同平台之间传输时才采用XML格式。我们发现Java提供了对象序列化的机制，可以把一个对象直接序列化成为二进制数据传递，所以我们在Java平台和Java平台之间传输数据时，采用序列化的方式进行数据的打包和解包，但让人惊讶的是，经过我们的性能测试，采用了对象序列化技术之后，我们发现通讯的性能反而比原来采用XML格式打包方式更慢了，后来经过测试也的确验证了，将一个对象序列化成二进制数据的速度的确慢过你把它用XML格式打包成字符串，再转换成二进制数据的速度。具体的原因我不详细说了，你写个简单的测试程序试一下就知道了。可想而知，基础支撑的性能如此之差，在此之上构造的EJB平台，它的性能能好吗？
当然，这个问题也不是不可避免的，你只要重载对象的序列化方法，实现你自己的序列化方式就可以达到高性能的序列化。但是你想象一下，为每个对象写序列化函数，这是个多大的工作量，为什么SUN的JDK本身至今也没有实现高性能的序列化？仅仅考虑设计架构上的简单性，而把大量的性能优化工作推给业务开发人员，是不负责任的做法。
2、另一项EJB技术更为严重的缺陷来自于RMI（远程方法调用），EJB更限定必须遵守COBRA规范的RMI-IIOP技术，实际上我质疑所有采用分布式对象调用的技术，包括COBRA、COM+、RMI等，这种技术的根本原理上都是一样的，通过本地的一个远程对象代理，通过网络上的多次通讯实现对远程对象的方法调用,这种设计架构的初衷是隐藏对象的具体位置，可以让对象使用者不用关心对象的实际位置，但是这种方法的实现性能极差，象COBRA这种系统的设计者当初就没有把性能问题作为一个重要问题去考虑，但正是性能问题，导致隐藏对象位置这个目的实际上也并没有达到，因为通过通讯访问远程对象的性能太差，因此使用者处于系统性能的考虑不得不考虑远程对象和本地对象的区别。更可悲的是，EJB的上层设计上也没有能够把远程对象和本地对象的差别消除，从EJB设计人员自己的说法，远程对象调用和本地对象调用在语义上就无法统一起来。既然上层就必须区分远程对象和本地对象，那底层技术上就完全没有必要采用这种性能很差的设计了。从COBRA开始，这种分布式对象访问的技术就是不成熟的，EJB墨守了分布式对象技术的陈规，导致自己背上了沉重的包袱，使用者必须很小心地使用EJB技术，稍有不慎就会导致系统性能大幅度下降。我们从大量的J2EE设计模式中看到，很多设计模式都是为了补救EJB的性能缺陷而设计的，与其在一个有根本缺陷的平台上施展你的才能弥补、避开系统的种种缺陷，不如放弃这种平台，消除问题的根源所在，把你的精力放在能为客户创造价值的地方去。
我认为，在分布式系统中，对象与对象之间的通讯应该采用轻量级的消息传递，我们不能为了实现面向对象的设计就一定要在每个地方强制使用面向对象调用的方式，面向对象技术本身也是需要不断改进的，我们在自主开发的中间件平台中，采用轻量消息传递的方式实现多个服务对象之间的数据交换，同样实现了服务对象具体位置的隐藏，而且实现了很高的性能。当然还可能存在其他很多高性能的解决方案，但我坚信EJB所基于的这种分布式对象调用技术迟早会被抛弃。
3、与前面提到的两个根本缺陷相比，EJB技术的其他方面的问题就显得微不足道了，比如EJB本身定义的复杂性，实体Bean的性能问题等等，我相信这些问题一定可以解决，或者很容易被新的设计替换掉，比如复杂性问题可以通过工具解决，实体Bean可以用轻量级的对象持久化层代替等等。
我想说的是，EJB的很多设计方面是非常优秀的，有许多设计思想值得我们借鉴采纳，但由于它本身存在根本的缺陷，导致了它无法成为一个可以长期持续发展的平台，它需要彻底的改变，EJB就像一个成长中的少女，在她真正向成熟转变以前，你可以欣赏她，但不值得爱上她，更不要着急把她娶回家。
