EJB到底是什么，真的那么神秘吗？？

1. 我们不禁要问，什么是"服务集群"？什么是"企业级开发"？
既然说了EJB 是为了"服务集群"和"企业级开发"，那么，总得说说什么是所谓的"服务
集群"和"企业级开发"吧！
这个问题其实挺关键的，因为J2EE 中并没有说明白，也没有具体的指标或者事例告诉
广大程序员什么时候用EJB 什么时候不用。于是大家都产生一些联想，认为EJB"分布式运
算"指得是"负载均衡"提高系统的运行效率。然而，估计很多人都搞错了，这个"服务群集"
和"分布式运算"并没有根本解决运行负载的问题，尤其是针对数据库的应用系统。
为什么？
我们先把EJB 打回原形给大家来慢慢分析。

2. 深入剖析EJB的概念
通过这样的方式可以看出什么端倪。

3.1 EJB 概念的剖析
我们先看一下，EJB 的官方解释：
商务软件的核心部分是它的业务逻辑。业务逻辑抽象了整个商务过程的流程，并使用计
算机语言将他们实现。
……
J2EE 对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组
件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实
现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE 中，
这个运行在一个独立的服务器上，并封装了业务逻辑的组件就是EJB（Enterprise Java
Bean）组件。
这其中我们主要关注这么几点，我们来逐条剖析：
剖析1：所谓："业务逻辑"
我们注意到在EJB 的概念中主要提到的就是"业务逻辑"的封装，而这个业务逻辑到底是
什么？说的那么悬乎，其实这个所谓的"业务逻辑"我们完全可以理解成执行特定任务的"类
"。
剖析2：所谓："将业务逻辑从客户端软件中抽取出来，封装在组件中……运行在一个服
务器上"
既然我们知道了"业务逻辑"的概念就是执行特定任务的"类"，那么，什么叫"从客户端
软件中抽取出来"？其实，这个就是把原来放到客户端的"类"，拿出来不放到客户端了，放
到一个组件中，并将这个组件放到一个服务器上去运行。
3.2 把EJB 这个概念变成大白话
变成大白话就是，"把你编写的软件中那些需要执行制定的任务的类，不放到客户端软
件上了，而是给他打成包放到一个服务器上了"。
3.3 发现问题了
不管是用"八股文"说，还是用大白话说这个EJB 概念都提到了一个词--"客户端软件"。
"客户端软件"？难道EJB 的概念中说的是C/S 软件？
是的，没错！
EJB 就是将那些"类"放到一个服务器上，用C/S 形式的软件客户端对服务器上的"类"进
行调用。
快崩溃了吧！
EJB 和JSP 有什么关系？EJB 和JSP 有关系，但是关系还真不怎么大，至多是在JSP 的
服务器端调用远端服务上的EJB 类，仅此而已。

探讨EJB的本质是什么？我们深入解析了其"八股"概念的核心理念。接下来将从其核心机制的角度深入剖析其底层架构。

4.2 EJB 的实现技术
EJB 是运行在独立服务器上的组件，客户端是通过网络对EJB 对象进行调用的。在Java
中，能够实现远程对象调用的技术是RMI，而EJB 技术基础正是RMI。通过RMI 技术，J2EE
将EJB 组件创建为远程对象，客户端就可以通过网络调用EJB 对象了。
4.3 看看RMI 是什么东东
在说RMI 之前，需要理解两个名词：
对象的序列化
分布式计算与RPC
名词1：对象的序列化
对象的序列化概念：对象的序列化过程就是将对象状态转换成字节流和从字节流恢复对
象。将对象状态转换成字节流之后，可以用java.io 包中的各种字节流类将其保存到文件中，
或者通过网络连接将对象数据发送到另一个主机。
上面的说法有点"八股"，我们不妨再用白话解释一下：对象的序列化就是将你程序中实
例化的某个类的对象，比如，你自定一个类MyClass，或者任何一个类的对象，将它转换成
字节数组，也就是说可以放到一个byte 数组中，这时候，你既然已经把一个对象放到了byte
数组中，那么你当然就可以随便处置了它了，用得最多的就是把他发送到网络上远程的计算
机上了。如图2 11所示。

名词2：分布式计算与RPC
RPC 也不是完全属于Java的概念。事实上，在Java并未诞生之前就已经存在了RPC这一概念。RPC即为"远程过程调用"（Remote Procedure Call）的技术术语，在早期的一些编程语言中已经有了相应的实现机制。需要注意的是，在那些编程语言中（如Fortran、C、COBOL等），虽然它们都属于过程性的程序设计语言而非面向对象的语言（Object-Oriented Programming），但在运行时却采用了类似的过程调用机制来实现跨平台通信。
图2-12所示。

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

4.4 优点
这种机制给分布计算的系统设计、编程都带来了极大的方便。只要按照RMI 规则设计程
序，可以不必再过问在RMI 之下的网络细节了，如：TCP 和Socket 等等。任意两台计算机
之间的通讯完全由RMI 负责。调用远程计算机上的对象就像本地对象一样方便。
RMI 可将完整的对象作为参数和返回值进行传递，而不仅仅是预定义的数据类型。也就
是说，可以将类似Java 哈西表这样的复杂类型作为一个参数进行传递。
4.5 缺点
如果是较为简单的方法调用，其执行效率也许会比本地执行慢很多，即使和远程Socket
机制的简单数据返回的应用相比，也会慢一些，原因是，其在网络间需要传递的信息不仅仅
包含该函数的返回值信息，还会包含该对象序列化后的字节内容。
4.6 EJB 是以RMI 为基础的
通过RMI 技术，J2EE 将EJB 组件创建为远程对象，EJB 虽然用了RMI 技术，但是却只需
要定义远程接口而无需生成他们的实现类，这样就将RMI 技术中的一些细节问题屏蔽了。
但不管怎么说，EJB 的基础仍然是RMI，所以，如果你想了解EJB 的原理，只要把RMI
的原理搞清楚就行了。你也就弄清楚了什么时候用EJB 什么时候不需要用EJB 了。

EVB 中所指的"服务集群"即意味着将原本在单个计算设备上运行的一些特定类分散到多个计算设备中执行。这种技术使得这些类能够分担所需占用的计算资源（如CPU和内存），从而实现分布式计算的优势。同时也可以将不同软件功能模块部署到各自独立的服务端上，在需要更改某些功能时只需修改相应服务端上的代码即可。这样不仅能够减轻单个设备的工作负担还能提高系统的扩展性和维护性。例如图2-14所示的例子就可以很好地说明这一技术的应用场景。

6. 这样的部署看来是不可攻破的
图2-14所示的这一项'服务群集'看似无法反驳。实际上这一项存在不足之处在于绘图不完整。我们来进一步分析后发现问题。
6.1 其中一项明显的限制因素在于数据库端的性能。深入分析后发现问题。

观察图2-15的结构示例后可以看出：当各个服务器需要针对同一个数据库执行查询操作时，则无论部署多少个功能型服务器都需要向同一个数据库服务器发起查询请求。这表明无论系统整体计算资源如何分布最终都会面临数据库服务器这一瓶颈节点。具体而言虽然看似将各个功能模块分散至不同服务器以分担各主计算机CPU资源的效果显著但实际上真正的性能瓶颈依然存在于数据库层面上因为所有的查询请求都需要通过该层节点进行处理导致其负载压力极大。因此通过这种架构设计我们能够深刻理解EJB机制无法彻底解决系统负载均衡问题的根本原因在于系统的性能瓶颈始终固定在数据库服务节点这一特定位置上

对于如何解决分开数据库的数据共享问题呢？有些读者可能会考虑如图2-16所示的应用架构。

每个功能服务器都需要配置一个数据库来解决上一节提到的问题。虽然这个问题得到了缓解但随之而来的是'数据共享'的新挑战这一难题同样不容易解决。

7. EJB 灵活运用能显著提升开发效率 J2EE 并非必须依赖于EJB
通过上一节的内容讲解似乎并没有揭示EVB 与开发Web 应用所采用的B/S 结构系统之间的密切关联 实际上
并非如此。如果我们把"客户端程序"这一概念理解为某一台服务器 那么这种观点也是成立的
而且 如果各个服务器之间能够实现基于EVB 的交互 则完全能够消除因广域网带宽限制而产生的通信问题。
不过 我们应当避免使用EVB 的情况主要包括以下几点：
1、对于相对简单的Web 应用开发 如果无需依赖EVB 则应优先选择其他解决方案
2、当需要与其他服务系统配合运行时 如果通过自定义网络协议解决调用或数据传输问题则无需采用EBV
3、面对多用户同时访问的基于C/S 结构的应用系统 在这种情况下尽量避免使用EBV

**总结： **

a.EJB实现原理：其核心在于通过将原有的客户端代码移至服务器端，并结合RMI技术实现数据传输。

b.RMI实现原理 ：就是通过Java对象可序列化机制实现分布计算。

c. 服务器集群: 就是借助基于RMI通信技术, 建立起各功能模块间的连接, 从而实现整个系统的完整运行。