摘抄：ejb的概念和原理解说

转自《java程序员 编程那些事儿》

3.5.3.1 EJB概念的剖析

我们先看一下，EJB的官方解释：

商务软件的核心部分是它的业务逻辑。业务逻辑抽象了整个商务过程的流程，并使用计算机语言将他们实现。

……

J2EE对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE中，这个运行在一个独立的服务器上，并封装了业务逻辑的组件就是EJB（Enterprise Java Bean）组件。

这其中我们主要关注这么几点，我们来逐条剖析：

剖析1：所谓："业务逻辑"

我们注意到在EJB的概念中主要提到的就是"业务逻辑"的封装，而这个业务逻辑到底是什么？说的那么悬乎，其实这个所谓的"业务逻辑"我们完全可以理解成执行特定任务的"类"。

剖析2：所谓："将业务逻辑从客户端软件中抽取出来，封装在组件中……运行在一个服务器上"

既然我们知道了"业务逻辑"的概念就是执行特定任务的"类"，那么，什么叫"从客户端软件中抽取出来"？其实，这个就是把原来放到客户端的"类"，拿出来不放到客户端了，放到一个组件中，并将这个组件放到一个服务器上去运行。

3.5.4.1 EJB的实现技术

EJB是运行在独立服务器上的组件，客户端是通过网络对EJB对象进行调用的。在Java中，能够实现远程对象调用的技术是RMI，而EJB技术基础正是RMI。通过RMI技术，J2EE将EJB组件创建为远程对象，客户端就可以通过网络调用EJB对象了。


3.5.4.2 看看RMI是什么东东

在说RMI之前，需要理解两个名词：

对象的序列化

分布式计算与RPC

3.5.4.2.1.1 名词1：对象的序列化

对象的序列化概念：对象的序列化过程就是将对象状态转换成字节流和从字节流恢复对象。将对象状态转换成字节流之后，可以用java.io包中的各种字节流类将其保存到文件中，或者通过网络连接将对象数据发送到另一个主机。

上面的说法有点"八股"，我们不妨再用白话解释一下：对象的序列化就是将你程序中实例化的某个类的对象，比如，你自定一个类MyClass，或者任何一个类的对象，将它转换成字节数组，也就是说可以放到一个byte数组中，这时候，你既然已经把一个对象放到了byte数组中，那么你当然就可以随便处置了它了，用得最多的就是把他发送到网络上远程的计算机上了。
3.5.4.2.2 名词2：分布式计算与RPC

RPC并不是一个纯粹的Java概念，因为在Java诞生之前就已经有了RPC的这个概念，RPC是"Remote Procedure Call"的缩写，也就是"远程过程调用"。在Java之前的大多数编程语言，如，Fortran、C、COBOL等等，都是过程性的语言，而不是面向对象的。所以，这些编程语言很自然地用过程表示工作，如，函数或子程序，让其在网络上另一台机器上执行。说白了，就是本地计算机调用远程计算机上的一个函数。

3.5.4.2.3 名词3：二者结合就是RMI

RMI英文全称是"Remote Method Invocation"，它的中文名称是"远程方法调用"，它就是利用Java对象序列化的机制实现分布式计算，实现远程类对象的实例化以及调用的方法。说的更清楚些，就是利用对象序列化来实现远程调用，也就是上面两个概念的结合体，利用这个方法来调用远程的类的时候，就不需要编写Socket程序了，也不需要把对象进行序列化操作，直接调用就行了非常方便。
远程方法调用是一种计算机之间对象互相调用对方函数，启动对方进程的一种机制，使用这种机制，某一台计算机上的对象在调用另外一台计算机上的方法时，使用的程序语法规则和在本地机上对象间的方法调用的语法规则一样。

3.5.4.2.3.1 优点

这种机制给分布计算的系统设计、编程都带来了极大的方便。只要按照RMI规则设计程序，可以不必再过问在RMI之下的网络细节了，如：TCP和Socket等等。任意两台计算机之间的通讯完全由RMI负责。调用远程计算机上的对象就像本地对象一样方便。

RMI可将完整的对象作为参数和返回值进行传递，而不仅仅是预定义的数据类型。也就是说，可以将类似Java哈西表这样的复杂类型作为一个参数进行传递。

3.5.4.2.3.2 缺点

如果是较为简单的方法调用，其执行效率也许会比本地执行慢很多，即使和远程Socket机制的简单数据返回的应用相比，也会慢一些，原因是，其在网络间需要传递的信息不仅仅包含该函数的返回值信息，还会包含该对象序列化后的字节内容。


3.5.4.3 EJB是以RMI为基础的

通过RMI技术，J2EE将EJB组件创建为远程对象，EJB虽然用了RMI技术，但是却只需要定义远程接口而无需生成他们的实现类，这样就将RMI技术中的一些细节问题屏蔽了。

但不管怎么说，EJB的基础仍然是RMI，所以，如果你想了解EJB的原理，只要把RMI的原理搞清楚就行了。你也就弄清楚了什么时候用EJB什么时候不需要用EJB了。


3.5.5 EJB中所谓的"服务群集"

既然已经知道了，RMI是将各种任务与功能的类放到不同的服务器上，然后通过各个服务器间建立的调用规则实现分布式的运算，也就明白EJB所谓的"服务群集"的概念。

就是将原来在一个计算机上运算的几个类，分别放到其他计算机上去运行，以便分担运行这几个类所需要占用的CPU和内存资源。同时，也可以将不同的软件功能模块放到不同的服务器上，当需要修改某些功能的时候直接修改这些服务器上的类就行了，修改以后所有客户端的软件都被修改了。
3.5.7 EJB活学活用，J2EE不是必须使用EJB

通过上面小节的讲解似乎好像EJB和开发Web应用的B/S结构的系统关系并不大，其实倒也不然。我们如果把"客户端程序"理解成某一台服务器，这样也是可以被应用的，而且，如果是服务器互相之间做EJB的调用的话，也就不存在广域网带宽限制的问题了。

但是，如下情况尽量就不要使用EJB了：

1、较为简单的纯Web应用开发，不需要用EJB。

2、需要与其他服务程序配合使用的应用，但调用或返回的自定义的网络协议可以解决的应用程序,不需要使用EJB。

3、较多人并发访问的C/S结构的应用程序，尽量不要使用EJB。