ejb是什么
很长时间以来，我们一直被误导了，以为只有采用了ejb技术的系统才算真正玩了ejb。后来才明白J2EE的内涵要比ejb广的多，是一套使用Java进行企业级开发的技术规范，包含了大部分核心服务如JTA事务管理, 资源池，线程管理，还有jdbc,jsp,servlet等应用技术。而EJB仅仅是一个使用了JTA事务管理、线程管理等J2EE基础服务的分布式的组件标准。
为什么需要ejb
按照官方的说法：
Enterprise JavaBeans will make it easy to write applications. Application developers will not have to understand low-level transaction and state management details; multithreading;resource pooling; and other complex low-level APIs.
Declarative transaction management
Remoting
Clustering
Thread management
Instance pooling
Resource management
Security
Management of business objects
记得一个人写文章说：“EJB最大的诱人之处是她把应用程序和服务器分开了,我们再也不用和那些服务器上的复杂的资源打交道了,什么数据库,什么进程,线程,什么安全权限,什么套接字,都见鬼去吧,我们只需要专著于我们的商业逻辑的实现了。”
ejb的许诺兑现了吗
ejb已经出现5、6年时间了，很多J2EE项目才也采用了ejb，sun所描述的美好前景也并没有实现。
1．Ejb规范本身是很复杂的，以至于没有多少开发人员去阅读他。Ejb总是与复杂联系在一起的,并没有减轻开发人员的负担。Ejb container像一个黑盒子，ejb在里面如何运行的，机制如何，很多人都说不出ejb container是如何处理异常的，跟事务有什么联系。
Ejb的运行效率如何，瓶颈在什么地方，没有人知道。（在Oracle中的调优我们可以很精确的找出是程序甚至说哪条SQL语句的原因，Oracle配置的原因，操作系统和硬件的原因）。
2．Ejb的复杂意味着程序的开发效率是低的，以致于Jbuilder提供了图形化的设计工具(一个包中的ejb只能由一个人来开发,否则合并比较麻烦) ,Xdoclet是另外一种辅助开发的方式。另外，拿entity bean来讲，每次想按照不同的参数进行查询，都要去为entity bean重新定义的一个select方法，然后编译发布，然后在业务逻辑中调用。
3．Ejb是在容器中执行的，意味着我们不能像一般的javabean那样来对待他，与javabean像比，他是一个需要其他环境的重量级实现，单元测试是很困难的。
4．关于entity bean,Marc fluery的文章中说Cache is the king，可是数据库中已经有cache了，为什么还要去cache entity bean（相对于enity bean的复杂性，数据的传输开销还是很小的）,仅仅是因为采用了entity bean而看起来更面向对象吗。
Core j2ee patterns和一些所谓最佳实现的书都有相当一部分内容来正确和简化使用ejb的。
相信Ejb 3.0在简化方面会做了不少工作。
为entity bean寻找理由, 构件与对象
一开始接触entity bean，感到的就是复杂，开发效率低，难以维护。
一般来讲，使用entity bean都是完成数据持久的功能。
后来看了hibernate,很简单,开始困惑，总以为entity bean之所以存在，还是有他存在的理由，于是列举了具备的安全,事务,分布式计算等方面的优点。
后来还是开始怀疑entity bean存在的必要,因为那些功能与优点都可以通过session bean封装其他jdbc操作或者hibernate来实现,想来想去entity bean唯一的不同就是构件了,更像客观存在的domain model,而不是从数据库里面取出来的数据，entity bean使对象看起来更像真实的世界。
构件之所以存在，是与分布式计算分不开的。在一个系统中，你可以通过另外一个系统来调用业务逻辑和数据访问，不同的系统通过构件来完美结合。
（其实torque也不错，就是不能操作多个数据源，另外就是自己生成了相关java文件来实现or mapping的功能，而不是像hibernate那样通过xml文件来配置实现。）
我们需要分布式吗，Distribution and Scalability
分布式意味着在网络之间进行协调调用，意味着复杂，除非必要，就不要采用分布式技术。
以前以为采用ejb，程序就是分布式的，就具备了可伸缩性。
抛开可以按功能来划分访问的系统，其实可伸缩性就表明了是需要Cluster的（Cluster并不完全意味着分布式，只是很多分布式体系提供了Cluster功能），而Cluster中的难点就是如何同步复制不同App Server之间的数据，而App Server是与很多资源相连的，程序执行状态，Session变量、数据库连接状态，我们如何复制呢。（好不容易理解了Oracle RAC,而我觉得Oracle的同步的资源都是内部的）。
重量级与轻量级（ejb container vs spring）
在公司论坛上看到一个讨论heavyweight与lightweight的区别，如果说把一项技术的规范和文档拿出来秤，操过500克就是heavyweight，否则就是lightweight。
似乎heavyweight总是与复杂性联系起来的。
就如同ejb container与spring。
我们所开发的系统并不是都是分布式的，也并不都是那么复杂的，才会有spring的出现。
客观的说，ejb container能够提供的功能，spring基本上都能够以javabean的方式实现。
区别还是前面说的ejb container是一个构件的容器，而spring是一个对象的容器，一个转移对象间的耦合，把业务逻辑与安全、事务等相分离的轻量级解决方案。
Spring 最核心的部件就是它的Bean Container,在整个框架中扮演了一个软总线，它使框架内部的组件按照一定的耦合度组装起来，对外提供一个服务的接口
。
如果开发一个需要跟多个系统交互运行的分布式系统还是使用ejb吧， spring取代不了ejb。
对于大多数web应用，应该是一个不需要访问其他系统的多层系统（即使可能访问多个数据库），采用spring把。Spring+hibernate应该是一个比较好的组合，但和ejb container相比，spring的缺点就是没有规范。
这么多年来，java总是在不停的修修补补中前进，
一切都是对象吗， OO的困惑
j2ee系统的开发应该都是采用面向对象技术，关键是怎么用的问题。
很久以前，在重粒子空间的一篇文章里，把一切都描述为对象，整个世界是那样的优美。我也深信不疑。
由于在我们的程序中，主要是针对数据处理和流程处理的，才知道用对象来表达不是那么自然。就查到了transaction script和domain model的概念。
transaction script就是对表示层用户输入的处理程序。包括验证和计算，存储，调用其它系统的操作，把数据回传给表示层。
domain model是所谓的域模型， 跟客观世界中的实体相对应。
transaction script属于结构性思维，直观一些，在系统中如果domain model不是很明显，采用transaction script也是一个不错的选择。domain model属于oo思维，需要较强的抽象能力，习惯了就可以能够组织很复杂的逻辑，另外，我们必须考虑哪些行为是通用的、属于domain model的，哪些不是，可以通过一些xxxManager或者xxxController所实现的。
举一个例子，假如查看今天A银行到B银行的所有转帐记录， 是列出A银行所有帐户对象来查看是否进行了转帐，还是从数据库中直接查询今天的转帐记录直观。Transaction script还是有他的用处的，可以说，所有的程序都要通过Transaction script来组织，程度不同而已。
这个世界，除了对象，还是有对象间的关系、行为规则和记录（数据）的，观察的角度不同，就可以从不同的角度来组织系统，不一定需要用对象来表示。比如一个人是一个对象，档案所记录他一生的活动是什么，数据，是我们关注的一个方面，我们来查档案就够了，而不用去问这个人。
不排斥DB
在网上很多文章中，都会提到把系统想象成一个完美的oo世界，而是db只不过是一个持久化的手段而已。
我一直认为db也是一个完整的世界，能够做很多事情，特别是在效率方案。
所谓采用oo和j2ee的系统，模拟现实世界，注重对象间的行为和关系，比较适合oltp的应用。
而db则是从数据角度来进行关注一个系统的，没有oo那么复杂的关系，处理效率很高，特别是在大批量数据处理和长事务处理的时候有自己的优势。在不存在明显错误的前提下，db的实现一般要比oo语言要高效，只是从大的方向来讲有它自己的处理范围。
Oo和db需要一个适应、协作的过程。
你有多少系统是需要从不同数据库之间移植的，必要的时候，在j2ee方案中采用些db技术还是不错的选择。
MVC
Spring，struts，webwork2
Model
C/s结构下，在pb程序中，一个datawindow几乎可以从界面交互、数据绑定以及访问数据库等一系列功能，你专心考虑业务实现就可以了。
在多层结构的程序中，这种好日子一去不复返了，因为分层，属于接口性质的细节要靠你自己来实现，仅仅在数据方面，就出现了vo， dto，po，detached po，domain model等众多的名词。
不同的层专注于不同的功能，对于界面展现，在struts中有actionform用于显示，业务层的数据用vo来表示，在网络传输中又用到了dto（特殊的vo），数据保存又用到了po了。
在这种情况下，数据的完整性是一个很麻烦的问题，假如actionform可能和vo的数据不完全一致，不完全一致的内容在页面生成的时候就丢失了，要么把vo缓存起来在需要时进行更新，要么在业务层从新query数据到vo进行更新，如果业务层是单独的而且持久层是ejb还要再次进行查询更新。效率很低，而且容易出错。
在hibernate中出现detached po，可以当成vo,po来用，也可以把数据传送
