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

EJB 规范承诺道，EJB 将使开发企业应用变得更加简单。这个承诺做到了吗？很遗憾，没有。而且 EJB 把分布式开发（注意，不是 TPMoniter，我要是不注明，某位兄台又要发火了）抬高到了一个不恰当的地位，使很多人对分布式开发趋之若鹜，误以为分布式开发就是企业应用这只皇冠上的明珠。有些人一提到企业应用，就开始高谈阔论什么分布式。这里我要指出的是：J2EE，特别是 EJB 把我们的方向完全引错了。

企业应用的核心从来都不是什么分布式，现在是而且永远都将是对数据更有效的抽取和利用。企业高层关心的永远都是数据，或者说是隐藏在庞大的数据之中的信息。

目前大多数 MIS 系统的一个最大的问题是面向的用户群层次太低，基本上就是面向底层的操作人员。所生成的数据过于琐碎，以至于对辅助企业高层制订决策几乎没有任何帮助。目前企业界对于普通 MIS 系统的需求即将呈现饱和状态，仅仅在办公自动化一类的传统 MIS 系统中已经几乎无法再玩什么花头。现在已经有很多公司把精力转向 OLAP、数据仓库、数据挖掘等领域，将来会有越来越多的公司把精力投向这些领域的。

那么这些大厂极力推崇 EJB 居心何在？
鼓励所有的人把所有的应用都做成分布式。你不会脑子进水非要在一台服务器上做什么分布式吧？做分布式应用当然至少要两台服务器了。

分布式意味着什么？更多的服务器，更高的性能要求，更强的硬件。想想 Sun 和 IBM 是做什么的你就会明白他们为什么一定要让你把应用做成分布式。

这件皇帝身上的子虚乌有的新衣直到有一天有个叫做 Rod Johnson 的家伙喊了一声：
其实大多数情况下我们并不需要做分布式应用
才终于被大多数人看穿。

难道我们单独用 Spring 就做不好 OLAP 吗？

EJB 的模型（model）分成两部分：一个组件模型和一个基于 RMI 的远程访问模型（或者叫分布式模型）。
如果 EJB 能够把这两个模型分开，而不是象现在这样死死地绑在一起，EJB 将变得更好。实际上这个远程访问模型我们很多时候其实不需要（可能现在绝大多数 EJB 开发者都是在使用 local 接口了），或者我们需要的并不是基于 RMI，而是基于 Web Service 的远程访问模型。

我们来观察 EJB 3.0 如何解决好这个问题。Let's wait and see.

还真有人在一台服务器上做的，理由是“构造伸缩性强的系统"。

也许在单台服务器上做分布式应用有些好处。比如把 EJB Client 和 EJB Server 部署在不同的 JVM 中可能会提高系统的鲁棒性。
但是这些做法解决的毕竟都只是些次要问题。这些应用服务器大厂始终都在打擦边球，始终无法为我们提供一个真正针对企业应用核心问题的解决方案。当然他们肯定有这样的技术，但是他们不会公布出来，要想免费使用他们的这些技术，那是在做梦。

很多人对 EJB、Web Service 趋之若鹜，一出现新技术就忙不迭地跑去学。但是这些东西其实根本就不代表这些大厂的核心技术，只是他们市场博弈过程中的一个棋子而已。

那种解决核心问题的，不是技术，而是方案，或者叫skeleton application，就是Rod Johnson在without EJB第二章里讲的那种。像IBM、SUN、BEA这样的公司，他们对几乎任何需求都有成熟的skeleton，你只要往里面填填自己特定的业务逻辑就可以搞定了。不过除非你成为他们的合作伙伴，比如SUN的JCOA，否则你根本没机会看到这些东西。就像我上次回TrustNo1说的，不光是我们，这些大公司也要想办法把关于行业的东西藏起来，拿出来讨论的肯定是什么架构啦模式啦之类的玩意，没跑。

gigix 说的就是我认为这些大厂不值得信任的原因。他们往往会出于自己商业利益的考虑向我们推销一些并不是真正实用的技术，盲目跟风最后只会竹篮打水。Sun  连 Solaris 也会开源，SPARC 也扔掉了，有一天抛弃 EJB 也是极有可能的事情。

请dlee分析一下，象bea这样的纯应用服务器厂商，日子是不是越来越难过了？
BEA高层震荡加剧 首席营销官宣布明日辞职

BEA难过又不是从今天开始的。但是如果J2EE朝着现在这种更开放、更组件化、更轻量级的方向发展，BEA或许又有一次新的机会。

什么时候这个世界才没有EJB!..

我一直对EJB的使用感到迷惑，以前也在这里发过帖子询问有关EJB、分布式和集群的问题。
我曾经的领导是EJB的支持者，坚持要在项目中采用EJB，我写了一长篇的报告论述当前项目不需要EJB技术。领导们觉得有道理，但依然不能放弃EJB，因为这在产品中是个卖点（显得产品比较上档次），对此我真是无语了。我想这都是那些EJB的鼓吹者造成的恶果。

我当时总结了一下EJB的应用场合：服务器在物理位置的分布上不在同一区域内，这时可以考虑使用EJB。
例如以下的情况：
1.国际性的大公司，分公司遍布全球，分公司需要同总公司的服务器进行交互。
2.出于职权与安全原因，有的服务器必须由专门的部门或人来管理。

当时领导说访问量大，我们需要分布式，一个WEB SERVER和N个EJB SERVER（据说很流行？）。这样真能解决问题么？请求还是那么多，不管EJB SERVER有多少台，WEB SERVER同它们之间的交互依然那么多，我不明白这样的架构能解决什么问题。并且这里产生一个问题，通过服务器之间的交互我们在程序效率上的损失很大，真是得不偿失。
很多门户网站在ASP、PHP年代怎么解决访问量大的问题？用集群啊。准确的说是负载均衡集群（集群分三种，有一种科学集群是采用分布式计算的。）负载均衡集群需要EJB吗？不需要。
我怀疑自己一辈子都可能不会做需要使用EJB技术的项目，但现在却不得不去了解EJB。那些EJB的鼓吹者（大多都是一些学术派的或者是以公司利益为出发点的人），他们并不会赔偿我为此付出的时间，我恨！