J2EE without EJB

第一：你在混淆分布式和集群这两个不同的应用。

第二：Spring是支持分布式系统的，请认真看Spring的文档，它支持RMI/Hessian/Burlap/Web Services四种方式。

第三：做集群有很多种办法，光是硬件的集群就有n种，基于不同的策略，即使说到软件的集群，那么Web集群的整体效率高，资源消耗少，还是EJB集群整体效率高，资源消耗少，我想大家心里面都有数。

第四：拿分布式协议来说，你认为Hessian效率高，还是基于RMI的EJB效率高呢？哪种协议能够无障碍的穿越防火墙呢？

第五：如果Spring架构的分布式的、集群的的软件系统性能已经无法满足要求，你认为EJB的分布式的、集群的软件系统性能就能更高吗？真到了这个时候就是BEA的Tuexdo，IBM的CICS出手的时候了，而没用EJB的份。



第一：分布式事务是必须的吗？不才刚刚翻译《J2EE without EJB》的Transaction一章，我同意Rod Johnson的看法，当代分布式系统，基本上的是采用数据库集群，例如Oracle RAC，SQL Server Cluster，数据库本身做透明集群，给上层应用提供一个单一的访问入口，而不是在App Server端进行分布式事务处理。

第二：Hibernate是ORM，不是事务处理框架，你怎么不说用EJB去试试做GUI呢？如果EJB真的可以做GUI，那么你可以去自己设计一个重量级的桌面应用程序了。

第三：SpringFramework现在就是一个轻量级的、支持分布式的J2EE框架，虽然分布式支持不是那么完美，但是我要提醒的是分布式是必须的吗？你哪怕找出来超过3个分布式应用的具体场景都困难。



那你给我解释一下Tomcat5为什么可以做到集群功能好吗？



但是也不能中庸到什么都是各打五十大板。



好轻松的一个个案而已。要求用Struts的客户绝对不是个案，我们不谈struts的技术限制，struts是java MVC框架的事实标准是不容置疑的。就像我告诉你的情况，客户拒绝EJB已经绝对不是个案，我自己已经遇到很多情况了，只不过碰到IBM的客户都拒绝，确实已经到了非常严重的地步了。

你的第一个例子只能说明JOTM能做到分布式，不能说对于分布式事务的处理它比EJB强，不能说明问题，同样的分布式实现，你是选择主流的被广泛验证的EJB容器给你提供的分布式处理，还是选择一个非标准的组件？理智的人肯定会选择前者，这一点和你发明的“architect的畏难情绪”的概念没有关系，非要自己去发明轮子有什么意义？

至于EJB的规范有没有考虑分布式计算的问题，真的不值一驳，难道EJB的远程接口仅仅是让你一个非EJB客户端在远程调用的？若不考虑分布式的问题，它设计一个remote接口干什么，劝你还是去研究一下EJB的动态对象模型吧。EJB远比你想象的强大。

你若说EJB的易用性差，这个我确实赞成，说它的灵活性不行，也基本赞同，但若说它的规范没有考虑分布式，我只能说你没有深入研究EJB，还停留在简单使用的层面。

我什么时候说过EJB规范没有考虑分布式？它当然考虑了。恰恰这种考虑很多时候是不必要的。application负载大了就必须clustering，这是毫无疑问的。但clustering应该由business层来负责吗？这本身就很可置疑。事实证明，大多数application要么是需要数据库集群（如果数据访问频繁的话），要么是需要web garden（如果负载量大的话）。且不说谁好谁坏，单单要证明business层集群的必要性，恐怕你就得费点脑筋——请别忘了分布式应用第一法则：不要分布你的对象。为一个罕见的需求，而不得不始终背负它的一切cost，难道这是一个合理的、不偷懒的architect所为吗？

其次，究竟“被广泛验证的”是EJB还是JOTM恐怕还得两说。首先，在transaction infrastructure这里，EJB和JOTM并没有区别，它们都是利用application server提供的infrastructure（你当然不会想告诉我说EJB容器实现了自己的transaction infrastructure吧？）。其次，在易用性方面，一个spec-driven的技术和一个出自实践经验总结的open source技术，哪个更易用我想是不言自明的。再次，别忘了，需要在business层实现分布式事务的场景本身就罕见（你不妨试着举个例子看看），对于一个罕见的需求，我更愿意要一种容易剥离的solution，而不是始终背着这个用不上的solution跑。

刚开始研究Spring，感觉思路确实很独特，但初步的印象是Spring架构似乎也不比EJB规范简单，不过对Hibernate的集成做得很不错，完全可以取代Entity Bean，但不知道它如何克服EJB的技术门槛过高、易用性差的问题，一个框架的普及一定要具备简练易学的特点，否则随着框架外围的支撑组件的丰富和成熟，框架本身也会变得复杂起来，可能又成了一个新的“EJB”。

可能是刚开始了解，不敢妄下评论，各位还是慢点拍砖，待我研究后会写一个Spring和EJB对比的个人感受，到时欢迎拍砖。

那是因为企业应用本身就不是一件简单的事。它们的区别在于，lightweight solution没有绑定，需要哪些东西是on-demand地选择的，而不是all-in-one地捆绑上去的。所以从某种意义上，lightweight solution对architect的要求更高，因为他必须仔细衡量自己application的每个需求。



不知道你有没有想过，为什么EJB会变成现在的样子。在我看来很大程度上是由于技术局限：EJB没有利用动态代理技术。只要以AOP的方式提供infrastructure，business object就能保持POJO的形态，就不会变得很难用。



如果说session bean只是“不够好”的话，entity bean就是“不可用”。一个连继承都不支持的O/R mapping，你说它有什么用呢？entity bean和Hibernate/JDO完全是不具可比性的。

我们公司目前使用的webwork+spring+hibernate。感觉还是不错。我觉得spring并不是大家说的那样神，hibernate也有很多功能需要扩展。看了ejb3.0的文档感觉。它融全目前spring+hibernate优点。并且也扩展了我很想要的功能。下个项目我一定要选择ejb3.0+webwork来实现。哈哈 

不妨介绍一下，ejb3扩展了哪些你很想要的功能？另外ejb3是如何实现spring带有的强大的AOP功能的？又是如何实现Hibernate带有的Criteria查询功能的？

其实最初EJB3竞争对手有不少。
hibernate就一个。


从历史角度看，
EJB3再等等看。

我觉得without EJB 里对thread management 和object pooling的分析不好， 把SLSB说的一无是处， 我觉得SLSB还是很有用的。

Using the Spring AOP Framework with EJB Components

http://dev2dev.bea.com/pub/a/2005/12/spring-aop-with-ejb.html