EJB 完全引错了路——论企业应用的核心问题

robbin

实际上这条理由是很牵强的。如果面对JVM崩溃最好的解决措施是JVM更加强健起来，当然这个对于多数人来说无能为力，但是这才是根本性的解决方法。次之是使用优化，这样的措施也是便宜的。而真正需要用分布式得到容错往往是最昂贵的做法。而且一般也不会有人在最早就考虑使用容错。
我想你明白在zope下就总是在考虑这个问题：为什么EJB是分布式的，而普通的java的bean或者干脆普通的java的class不是分布式的。

这我也同意，在开发的初期没有必要为分布式做过度设计，除非你一开始项目需求就确定要部署在分布式环境中。但是从你上面那么多贴我并没有看到这种言论，给的感觉就是一棍子把分布式和EJB打死。这并不是一种客观的态度。

说句诛心之论：“不要为了卖书而对特定理论产生偏执啊”。

要打倒EJB，也不要通过“揣摩大厂商的卑劣”来达到目的。

上面的讨论把两个问题混淆了。

第一个问题是分布式是否有用，这个问题是肯定的。对于这个问题我不想多费口舌，JVM的强健怎么提高？难道用分布式就不是提高了吗？在应用部署方面，进行分布式容错确实昂贵，但是你不要忘记了，容错这个概念就是用成本来换稳定的。否则我们干吗还要HA，异地容错，投资上千万去提高容错性，按照你的观点，我们就把应用系统搞的更坚固，让它不出现问题就可以解决容错咯？

zope确实不错，在zope下面编程不需要考虑是否要单独为分布式开发进行特定的编码，分布式完全是zope的事情。这才是我们真正需要的方式。

to 庄表伟：
这些感觉其实是长期存在于我头脑中的。读了 without EJB 后更增强了这些感觉。来这里讨论完全是我的个人行为，不要与这本书的翻译团队挂上钩。
这个话题再扯下去就全部是口水战了，建议锁贴。

其实选择什么方向，就是为自己的未来买单。OLAP、数据挖掘、分布式应用，每个人都可以自由选择的。

是啊，所以 Rod Johnson 所批评的 EJB 完全把对象模型和远程访问模型绑死在一起还是有些道理的。

其实我认为你们对EJB的攻击没有到点上，其实你们看看前面potian说的，我认为他才真正说到点上了。

我这话的打击面是过大了，但是这样的趋势是存在的。

EJB谁都可以批评，但是如何批评，有个手段选择的问题，有一个理论基础的落脚点的问题。

我们可以从技术上来分析，可以从易用性上来分析，可以从开发成本和效率上来分析。这些都没有问题，而且你的分析，以及你所引用的Rod Johnson的观点，我大多都是同意的。

唯一不同意的，就是“大厂商阴谋论”，以及你围绕这一论断所做出的各种“分析”。而这样的习惯性的思维，不止是你有，好多技术人员，内心里有隐隐约约的存在着。

EJB是业界标准，这不过是一个事实，既不是它的“原罪”，也不是当然的“选择理由”。

因为N多巨头支持某种技术，既不能成为我们盲目支持的理由，也不能成为我们盲目反对的理由。盲目支持的，JDON就是例子。盲目反对的，我看也要不得。

我看还是把问题先搞清楚，到底什么是分布式？

按我的概念是一个系统、功能（或资源）通过分布，也就是分散到不同的位置（物理的、逻辑的）协同来完成一个任务，从而可以各自更高效、更合适地完成任务。例如DNS服务器因为数据量、请求量太大而分布。或者一个ERP系统通过分散在全球各地的信息来DRP分销。分步实是和集中相反的一个概念。

如果两台机器或两个JVM完成一样的任务，以做负载均衡和容错，那是属于集群的范畴。因为系统中的对象之间本身不需要通讯，集群采用的技术不需要考虑系统中大量对象的remote机制，而只需要集群本身对某些需要的对象进行群组式地可信传递和同步，因而可能需要java应用程序的某些对象必须是serializable的，譬如Session。

所以我不是很理解为什么需要在同一台机器上分布应用程序？robbin能不能解释一下。

对于这个问题，我觉得 o6z 说的企业应用的核心是数据和流程，这个观点我认为是正确的（当然你可能认为因为他的观点和我非常接近，所以我才会接受他的观点）。这其实是我跟 ly、xel 等等对于项目开发非常有经验的朋友的共识。

另，你的观点其实也是会出错的。