Jdon根本没有搞清楚Spring框架使用的真相，就在这里把Spring和EJB对立起来，其实这只是两种不同的解决方案，每个都有不同的应用范围，这在without EJB中写很清楚，在大多数的项目中普通需要的是像Spring这样的轻量型容器，而不是EJB这样复杂的东东，而不是EJB的Stateful Session Bean和Entity Bean这些证明很失败的东东。
>Spring和EJB对立起来
不是Jdon搞对立，是Spring自己搞对立，without EJB，本身词语含义已经有黑与白的关系了，为何又总是反复申辩。
>大多数的项目中普通需要的是像Spring这样的轻量型容
Spring是轻量型容器吗？ 单一个实例配置曾单态还是多例，这个问题我想很多初学者就无法一下判断准确。至少，我个人认为Spring是伪轻量容器。
>EJB是失败的东西
EJB怎么是失败的东西，大量的人在使用啊，如下：
http://www.jdon.com/artichect/EntitBean.htm
再建议看看这篇文章，从模式角度理解Spring，就不会对之有神秘的感觉。
http://www.jdon.com/jive/article.jsp?forum=91&thread=16595
without EJB只是说了一个事实，说J2EE的有些项目中可以不用EJB;EJB与Spring的关系是并不是像异型和人的关系，他们有自己有应用的范围，spring不能包治一切，EJB也不能，spring不是来替代EJB的，without EJB只是说明了有些地方滥用了EJB，EJB并不是J2EE的全部。
EJB并不是失败，而是有些方面有些问题，像持久化，开发效率，可测性等都不怎么样，EJB并不完善，这是事实。
我用异型来比喻它，实际是惊叹Ioc的微内核概念，这个微内核可以寄生自由活动在Java各个平台上，J2SE、WEB容器和EJB容器，非常叹服这个设计概念。
这个概念实现的Spring/picoContainer可以寄生在EJB或WEB容器，从而在应用系统和容器之间又形成新的一层，这样，用户的应用系统可以配置在Web容器运行，也可以配置在EJB容器下运行，用户自由选择余地大了，这是Ioc产品最大的优点。
作为Ioc模式微内核的实现Spring最大的缺点是引入Singleton，这点是另外一个同样实现picoContainer极力反对的，既然是Ioc微内核容器，微内核容器本身就是单态，唯一的，那么其中实例再无需单态了，但是Spring提供这种选择，容易引起初学者误用和以后性能问题。
> 2.Sping 就把 性能的扩展性任务推给了 web
> container，那么我们就要求有一个好的Web容器提供Cluster?
> 持，但是遗憾的是，目前J2EE标准中并没有和涉及Web容器的?
> 何Cluster定义或接口，所以造成有的Web容器提供Cluster，?
> tomcat有一些，jetty比较好，大部分商业化产品如Weblogic?
> 没有，它们把Cluster集中在EJB层了。
这个话我们私底下说说就好，如果让BEA的同志们听到没准他们要生气的。下边这篇文章不妨看看：
最大化BEA WebLogic Cluster的性能、可用性和安全
> EJB怎么是失败的东西，大量的人在使用啊，如下：
> http://www.jdon.com/artichect/EntitBean.htm
我那天在TSS看到这篇原文，有一句读得不太懂，看banq的翻译好象也一带而过，想请banq再解释一下，可否？
what with everyone and their brother (and their brother's friend's cousin) being happy to publicly whine and moan about what a pain EJBs are
引用一下spring作者的观点，仅做参考：
If you need distributed transaction support, a JTA implementation provided by a
high-end application server is as essential in an IoC + AOP world as it is to EJB.
>what with everyone and their brother (and their brother's >friend's cousin) being happy to publicly whine and moan about >what a pain EJBs are
这句话翻译是“很多人包括他们周围的“兄弟”都乐于公然地抱怨和埋怨痛苦的EJB是：”。
我们已经看到很多人没有使用过EJB，但是附和在其他人后面一起抱怨EJB，其实在他们抱怨的时候，EJB本身已经在变化了。
好像这个话题不适合在这个帖子讨论，这里只是研究Spring，就此打住。
ejb已经出来5，6年了吧，即使是ejb2.0也是3年前的东西，它的一些缺陷也是渐渐出来，所以才有spring这些东西，很多方案是针对ejb的缺陷提出的。但ejb也是在进化中，大家可以看看一份非正式的ejb3.0 faq,很多思想都跟spring的一致。只是不知道何时出来.
>很多思想都跟spring的一致
我一直在强调，并不是EJB 3.0和Spring一致，他们都同是新的设计思想的产物。这如同类图中继承关系一下，都是抽象思想实现，两个都是儿子，一个先出生，一个后出生，老二象老大，是因为他们是同一个老子生的，但不能断章取义说，老二模仿老大的；或是从老大那里复制的。
这就象美国在先进科技和思想指导下最先研制出原子弹，而中国过后也在同样的科技思想下研制出原子弹，那么就说中国的原子弹和美国原子弹一致了，或者说就是他那个样子。
Ioc模式理解可见这个连接：
http://www.jdon.com/jive/article.jsp?forum=91&thread=16595
另外EJB 3.0也不是可望不可及的，JBoss ejb 3.0已经可以在JBoss 4.0下运行使用，见这里连接：
我这里并不是说EJB 3.0和Spring谁好谁坏，根据不同系统和自己的掌握能力选择，就象我回答另外一个帖子问题，如下：
http://www.jdon.com/jive/thread.jsp?forum=16&thread=16817
我前面已经指出，Spring目前版本缺点是引入Singleton，关于实现单态功能，EJB处理有其技巧，所以，在EJB环境中，是没有单态这个概念的，这也是为什么研究Petstore的人发现，serviceLocator有两种，一种是Web的单态，另外一种是EJB，这个问题，在Jdon很早时就讨论过了。
我也替Spring研究一下，引入Singleton是不得已而为之，实在想不出什么好办法为用户提供单态服务功能了。
目前设计领域大家已经普遍认识到Singelton的害处和危险，在Jdon的 “Java多线程 集群 并行模式 ”版块也有多个帖子讨论了单态对性能可能导致的影响，如果初学者再误用同步synchronized语法，整个系统可能变成单用户系统。我通过实践案例发现，初学者在做大系统时，特别喜欢用Singleton类和静态类，这是很现实的情况。
每次设置一个POJO的Spring配置时，脑海里都要考虑一下，是设置单态还是Pool，这个就如同使用EJB时，每次考虑是使用有态Bean和无态Bean考虑一下，因为EJB无单态，所以，比较容易选择Pool支持的无态Bean，但是如何在EJB实现全局唯一变量就费点思量。
dabb在这个帖子提出的问题就属于这种情况：
http://www.jdon.com/jive/thread.jsp?forum=16&thread=16893
从上面讨论，我们也看到，使用Spring并不简单，不是Spring框架或EJB做得不够好，是因为现实系统情况是复杂的，Spring或其他什么高级框架提供的选择越大，用户使用Spring这些框架和自己具体应用结合时，需要考虑得就越大，这增加了实际使用的复杂程度，所以我说，Spring这样框架其实并不能算轻量的（不是我一个人意见，我也看到有老外的同样想法）。
关于Singleton，我有些疑问想请教一下。banq说“目前设计领域大家已经普遍认识到Singelton的害处和危险”，但我还不是很清楚，Singleton的害处究竟在哪里。照我的理解，Spring容器将bean区分为singleton和prototype两种，意图是想区分有状态业务对象和无状态业务对象――有状态业务对象以prototype的方式创建，程序员须将其保存以便取回状态；无状态业务对象以singleton方式创建，任何时候使用同一对象。既然是无状态业务对象，自然也就是immutable的，自然就不需要synchronize，在这种情况下，Singleton会影响系统性能、使之变成“单用户系统”吗？希望banq不吝赐教。
是的，Spring这个目的我前面也提了，但是，有时我发现这么一个现实情况，初学者往往是从全局变量的角度来看待Singleton，例如有一个重要的功能类，有一个写操作方法，如果这个功能类被设定成Spring的Singleton，实际这个功能类变成全局唯一对象实例，会发生多线程争夺访问的现象，一般我们会在这个写操作方法加synchronized，这样这个方法执行变成一条线程通道了，如果这个方法处于全局系统的重要咽喉要道，那么，整个系统由于它可能变成单用户系统。
这样的讨论在 Java多线程 集群 并行模式 版块以前讨论很多，这里有一个贴供参考：
http://www.jdon.com/jive/thread.jsp?forum=121&thread=15399
>>例如有一个重要的功能类，有一个写操作方法，如果这个功能类被设定成Spring的Singleton，实际这个功能类变成全局唯一对象实例，会发生多线程争夺访问的现象，一般我们会在这个写操作方法加 synchronized，这样这个方法执行变成一条线程通道了，如果这个方法处于全局系统的重要咽喉要道，那么，整个系统由于它可能变成单用户系统
第一，业务逻辑的原子性不应该用业务代码中的synchronize来保证。banq很熟悉EJB，你当然知道，EJB根本不允许使用synchronized关键字，业务逻辑的原子性是靠transaction infrastructures来保证的。那么，换到与session bean对应的POJO service component这里，你怎么会忘记了这个原则，却想在业务代码里面写synchronized呢？既然EJB里面写synchronized会导致undefined的结果，难道在Spring这里不是一样的吗？
第二，设若你的业务代码确实需要synchronize，我请问了，这样一个thread aware的对象，你怎么能把它交给容器――不管是Spring还是EJB容器――去管理生命周期？没错，开发集群、并行等基础代码时我们确实需要synchronize，你会把这些逻辑放在session bean里面去吗？
banq很熟悉EJB，你应该很清楚，即便EJB社群也已经公认：最有价值、最成功的EJB尝试就是stateless session bean。因为stateless，所以immutable，所以thread unaware，所以不需要synchronize，所以可以用任何形式的生命周期、任何形式的transaction infrastructure来管理。Spring管理的正是stateless business components，何苦要用stateful的、thread aware的观点来吹毛求疵？照这个逻辑，如果我在session bean里面写上synchronized关键字，恐怕结局不仅仅是“变成单用户系统”这么简单吧――具体会怎么样，banq应该比我更清楚。
gigix 看来对多线程和Pool概念有些模糊，在EJB中，特别是无态会话Bean，都是Pool支持的，这个我们在Jdon很多帖子都讨论了，以前一个网友询问，是多个线程访问一个实例，还是一个线程访问多个实例效率高，我回答是：一个线程独占一个实例效率高，这就是Pool的由来，这样在EJB中完全避免了synchronize这样的尴尬。
>>我回答是：一个线程独占一个实例效率高
这句话我不是很明白。照我理解，如果对象本身是immutable的（因此没有使用同步语法），不管多少个线程使用它，根本不会有排队，所以效率都是一样的。举个最简单的例子，String常量对象都是Singleton的，比如不管你在多少个地方声明 String s = "Hello"，得到的都是同一个对象实例。如果照你的说法，岂不是这样也会降低效率？至于事实究竟是怎样，各位自己写个程序试试就知道。Singleton究竟为何降低效率，恐怕banq得把前几年JavaWorld那几篇文章翻出来仔细看看再说。