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

从实际的应用来说，一个大型的ERP系统必须考虑到分布式的问题，不但是因为一个企业内部的库存、分销系统可能是分布的，作为供应链上的企业群它们之间的系统也需要分布协作，虽然现在往往是通过集中式子系统收集数据，在通过其他手段导入到整体系统去。

以前一般用的是CORBA，但现在用EJB来做恐怕还是合适的。当然不久地将来，我还是希望我前面提到的可任意重组的AOP服务来实现。

to robbin：
其实是否采用 EJB 绝对是一个公司技术战略的范畴。象 EJB 这样的大型 infrastructure 的选择绝对不是一个纯粹的技术问题（战略而非战术）。

另，我对 Rod 的看法和我对 potian 的看法一样，也并没有觉得他很神圣啊。

to potian：
其实就是个对于企业应用不同问题优先级考虑的不同，真的是没有必要激烈争论的。

这方面你是专家了。银行主要还是C/S加上TPMonitor居多。

我是询问一下robbin的看法，因为我自己还不知道什么样的情况需要在同一台机器上做分布式，尽管同一台机器上集群部署，我还是做过的。

为了避免多数据中心并存带来分布式的问题，他们还正在设计一个全国集中的数据中心，无论如何，他们都是在避免采用分布式开发的使用。
一来没实力！
而来没可靠技术支持！
三来没有国内成功的实施经验
四来可以省钱

是的，目前银行的趋势是大集中，ERP系统的趋势也是这样的，但我觉得这还是有点太一刀切了。尽管集中的好处确实非常非常的多。

To:potian

单台物理服务器上进行集群，我想你是不置疑的。至于单台服务器上的分布式应用，我想到一个场景，但是不知道是否有说服力。

IBM，HP这样的公司有一些小型机，工作站，为了充分挖掘机器的潜力，通常是在单台物理服务器上面运行n个操作系统的，并且操作系统之间的资源调度方式也很多样，例如哪个操作系统使用哪块内存区域，哪个操作系统占用哪个CPU的多少资源等等。

这其中不同的操作系统占用不同的硬件资源，表现出来不同的性能，有个可能运算能力强，有个可能内存大，有的可能IO负载高等等。

基于功能的不同，划分出来的不同的操作系统上面执行不同的分布式运算，这可能是一个例子。我是知道IBM有这样的东西的。

说道分布式，我立马就想到那个该死的DTO。
不知道怎么搞得，我一看到DTO，我就头大。
DTO好像我以前开发的银行报文。传来传去，还要用专门的method负责DTO的转换。DTO如果可以带service method就好了，客户端拿到一个完整定义的对象（对象没有行为是完整的对象嘛？我认为不是，最多不过是一个封装数据的报文替换品罢了），那就会使得RMI，分布式开发速度快上N倍。
以前在银行老跟Message打交道，现在又看到对象概念的DTO，气不打一处来。呵呵，说错了，别见怪。

实际上现在对于EJB的很多非议并不是对这个技术的否定，而是对这项技术当初承诺可以带来给使用者利益的未达成的一种反弹。这就好像你化500块买了一瓶号称可以治疗智商低下的水，结果却发现根本就是瞎掰。然后现在你说不能因为不能提高智商就把这瓶水一棍子打死。道理虽然不错，因为这瓶水毕竟当初给你喝了，至少解决了水分补充的问题。但是这个理由在多数人面前根本就说服不了他们。
实际上这是一种愤怒，这就好像当初到处是“未公开”系列的情况一样，是一种社区对厂商的愤怒。这才是问题的本质。在这种情绪下你去和他们讨论任何的技术细节都是不现实的，而且也是不必要的。

to robbin：
你的这个例子还是没有什么普遍性，除非你能证明很多场合在单台服务器上做分布式是合理的，否则你的言论我也就只能一笑置之。

在 Windows 上进程间通信有以下几种方式：
1、共享内存区
2、命名管道
3、Socket
（还有其他方式，我记不清了。很多年没有在 Windows 上做 C 开发了）

RMI 是基于 Socket 实现的对吧？ Socket 是这三种通信方式中最低效的。EJB2 新增的 local 接口大幅提高了 EJB 的性能，但是前提是 Client 与 Server 要跑在同一个 JVM 中。
所以单从性能上考虑，我一般是不会在单台服务器上使用多个 JVM 的。使用多个 JVM  可能会对提高应用的稳定性有好处，但是这些领域需要 robbin 更进一步的证明。