EJB提供的应用程序可移植性，抽象性以及由抽象性而提供的向后兼容性

为什么80%的码农都做不了架构师？>>>   

首先，EJB不是人们想象中的样子：重量级。实际上，它的目标与“重量级”这三个字恰恰相反：轻量级。

意味着它的目标在于减轻企业级软件开发的任务。企业级开发的特点是什么呢？它的特点是：认为软件只是一个工具。企业有很多事情需要考虑。软件只是其中的一个环节。软件不是所有。所以，尽量减少在软件开发上的投资以及最大化软件资源的利用价值，对企业来说，是一件很重要的事情。

一切都是标准。EJB与SERVLET，JTA，JPA，JSP等一样，他们都是标准。这是另一个很重要的思想，也是理解J2EE的一个很重要的出发点------J2EE是一个标准：界于程序员与软件服务提供者之间的标准。微软做技术，SUN做标准。这是SUN与微软的主要差距。微软是小家。SUN才是大“家”。

为什么我要用EJB？因为你要么用EJB，要么用别的东西。你总要用些东西。但不是每一样东西都是标准。当你想把你的东西建立在标准之上的时候，EJB是唯一的选择。有人把SPRING与EJB作比较，这是不能比的。把SPRING与EJB作比较，就等于把微软与SUN作比较。因为技术与标准是不能比的。技术是实现标准的手段。技术不是标准。两者不属于同一个范畴。因此不能比较。

设想我已经把应用建立在EJB的基础上。因为EJB整个其实只是一个抽象化的体系，它已经囊括了几乎所有我需要考量的事情如事务，安全，持久化，缓存，会话，消息，分布式等等。并且，随着时间的发展，它还会包括进更多的东西------以一种完全抽象化的手段，这给我提供了莫大的方便：我再也不用关心我的系统的可移植性，或随着时间的转移，我的应用的“潮流化”需求。因为万变不离其宗：技术也许天天都在改变，但是我要的东西却永远都不会变或者说基本上，至少会变得很慢------我要什么？我要事务，安全性，持久化，缓存，会话，消息，分布式。。。。。。就跟我要吃饭一样：我天天都要吃饭。虽然我每天吃的东西都不一样。但吃饭这件事情，从本质上说，却亘古不变。

如果硬要说它有问题。它唯一的问题便是，它并不包括所有。如隐私保护，IT审计，配置管理，质量管理等等，所有的东西，但是基本上所有这些东西都属于个性化需求。它们并不是所有应用或每个人都需要的东西。但是至少，它标准化了一些东西。减轻了我很大的压力。我只需FOCUS到我的特殊需求上：如作为出发点的业务需求。我当然需要工作。但我也只想为“我”工作。如果单独为了出行就独自去修路，那是一件很愚蠢的事。单独为了事务去写一个事务库，那当然也是愚蠢的。为什么我会去做那件事情？我的工作到底是什么？

 

那么，EJB与SERVLET是什么关系呢？

首先要摆正的是视角。从程序员或软件开发者的视角来看，EJB提供一个向（提供实现手段）下的标准，而SERVLET提供一个向上（提供服务）的标准。虽然EJB也可以用来实现向上的服务，如果我的客户端可以接受采用一个对象级而不是一个文本级的WEB服务的话。EJB是一个对象级的标准。对象级的东西从来都是复杂的，所以很难理解，如WEB SERVICE，CORBA，IIOP，IDL等（如很多人想象的相反，OO并不是一种适合于人类的思考模式------我们并不是以对象的模式去思考问题的。关于我们到底是怎么思考的，它一直是个问题）。这很可能是EJB很难流行的原因之一。我觉得，如果SUN能尝试把EJB与SERVLET结合起来，也许会是一个很好的推广手段。象COLDFUSION开始做的一样，EJB在COLDFUSION里面用得就很舒服。因此在COLDFUSION环境里面，EJB得到很好的应用。。。。想象一下，即使在J2EE的环境里面，竟然不存在一种方便地使用EJB的手段。这难道不是个问题吗？。。。。。。语义上的连结，在编程理论中是一个不容忽视的因素！

为什么EJB宁愿提供WEB SERVICE服务却不愿意提供更基础的HTTP服务呢？如果是这样的话，我们还需要SERVLET吗？WEB SERVICE真是个奇怪的东西，它先把对象级的东西封装成文本级的东西，然后又在这个文本级的东西上面实现对象级的技术（RPC）。难怪人们理解不了它。它完全超出了常理。

对象级的东西，只应该存在于本地应用即同一片地址空间如进程，或虚拟机中。

为什么它会进入通信系统呢？。。。

 

 

 

 

 

转载于:https://my.oschina.net/digerl/blog/29733