1.EJB技术
参考文章：
EJB是sun的JavaEE**服务器端组件模型，设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序（即：类）打包放在服务器上**执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。

EJB 是为了”服务集群”和”企业级开发”。

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

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

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

EJB 和JSP 有什么关系？EJB 和JSP 有关系，但是关系还真不怎么大，至多是在JSP 的服务器端调用远端服务上的EJB 类

EJB 的实现技术

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

理解RMI技术
对象的序列化
分布式计算与RPC

名词1：对象的序列化

对象的序列化概念：对象的序列化过程就是将对象状态转换成字节流和从字节流恢复对象。将对象状态转换成字节流之后，可以用java.io 包中的各种字节流类将其保存到文件中，或者通过网络连接将对象数据发送到另一个主机。
上面的说法有点”八股”，我们不妨再用白话解释一下：对象的序列化就是将你程序中实例化的某个类的对象，比如，你自定一个类MyClass，或者任何一个类的对象，将它转换成字节数组，也就是说可以放到一个byte 数组中，这时候，你既然已经把一个对象放到了byte数组中，那么你当然就可以随便处置了它了，用得最多的就是把他发送到网络上远程的计算机上了。

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

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

补充点：
既然已经知道了，RMI 是将各种任务与功能的类放到不同的服务器上，然后通过各个服务器间建立的调用规则实现分布式的运算，也就明白EJB 所谓的”服务群集”的概念。就是将原来在一个计算机上运算的几个类，分别放到其他计算机上去运行，以便分担运行这几个类所需要占用的CPU 和内存资源。同时，也可以将不同的软件功能模块放到不同的服务器上，当需要修改某些功能的时候直接修改这些服务器上的类就行了，修改以后所有客户端的软件都被修改了。如图2 14所示。

1. 这种部署难道是无懈可击
   图2 14所示的这个”服务群集”看似”无懈可击”，其实是它这个图没有画完整，我们来把这个图画完整，再来看看有什么问题没有。

6.1 瓶颈在数据库端
仔细观察之后，发现这种配置是有瓶颈的，如图2 15所示。

我们看看图2 15的结构图，现在如果想实现各个服务器针对同一个数据库的查询，那么，不管你部署多少个功能服务器，都需要针对一个数据库服务器进行查询操作。也就是说，不管你的”计算”有多么”分布”也同样需要从一台服务器中取得数据。虽然，看起来将各个功能模块分布在不同的服务器上从而分担了各个主计算机的CPU 资源，然而，真正的瓶颈并不在这里，而是，数据库服务器那里。数据库服务器都会非常忙的应付各个服务器的查询及操作请求。
因此，通过这个结构图使我们了解到了EJB 根本不能完全解决负载的问题，因为，瓶颈并不在功能模块的所在位置，而是在数据库服务器这里。

6.2 假如分开数据库，数据共享怎么办
有的读者一定会想到下面的这个应用结构，如图2 16所示。

就是把每一个功能服务器后面都部署一个数据库，这样不就解决了上节所说的问题了吗？是的解决了数据库查询负载的问题，然而又出现了新的问题，就是”数据共享”的问题就又不容易解决了。

6.3 网络面临较大压力，让你的应用慢如老牛
我们再向前翻看看如图2 15所示的这种架构中存在两个网络，一个是”A 网”一个是”B网”，这两个网络是不同的。”B 网”往往是局域网，一般带宽是10M/100M，速度较快，因此到还好说，然而，”A 网”往往是互联网或者是利用电信网络互联VPN 网或称广域网。”A 网”的特点是带宽一般较窄，如ADSL 的网络仅仅有512K-2M 的带宽，由于广域网互联的成本较高，所以一般不会有较高的带宽。而在这个网络上恰恰跑的是功能模块和客户端软件之间交换的数据，而这部分数据恰恰优势非常占用带宽的。因此，这个应用架构其运行速度可以想见是多么的慢了。说句不夸张的话，有点想老牛拉破车一样的慢。一个如老牛的系统：目前在中国互联网做运营商网络管理系统的一个大公司，它的一个早期的网管软件就是采用了这种架构来做的C/S 结构的应用系统。有一次，我作为评估者来对其应用系统进行评估，将其部署到一个非运营商大型的网络中的时候，便出现了我们上述描述的情况，速度已经到了难以忍受的地步，打开一个流量图，有时候需要用15分钟的时间才能呈现完整。然而，该系统在开发阶段并没有发现这个问题，为什么呢？因为，他们没有考虑到应用的实际用户连接网络的复杂性，从而给该公司造成较大损失，以至于，这个开发架构被最终遗弃。

1. EJB 活学活用，J2EE 不是必须使用EJB
   通过上面小节的讲解似乎好像EJB 和开发Web 应用的B/S 结构的系统关系并不大，其实倒也不然。我们如果把”客户端程序”理解成某一台服务器，这样也是可以被应用的，而且，如果是服务器互相之间做EJB 的调用的话，也就不存在广域网带宽限制的问题了。
   但是，如下情况尽量就不要使用EJB 了：
   1、较为简单的纯Web 应用开发，不需要用EJB。
   2、需要与其他服务程序配合使用的应用，但调用或返回的自定义的网络协议可以解决的应用程序,不需要使用EJB。
   3、较多人并发访问的C/S 结构的应用程序，尽量不要使用EJB。

spring

Spring框架是由于软件开发的复杂性而创建的。Spring使用的是基本的JavaBean来完成以前只可能由EJB完成的事情。

Spring是一个开源容器框架，可以接管web层，业务层，dao层，持久层的组件，并且可以配置各种bean,和维护bean与bean之间的关系。其核心就是控制反转(IOC),和面向切面(AOP),简单的说就是一个分层的轻量级开源框架。

　IOC：(全称:Inverse Of Control )控制反转，容器主动将资源推送给它所管理的组件，组件所做的是选择一种合理的方式接受资源。
　　简单的理解：把创建对象和维护之间的关系的权利由程序中转移到Spring容器的配置文件中。
　　DI:(全称：Dependency Injection)依赖注入，IOC的另一种表现方式，组件以一种预先定义好的方式来接受容器注入的资源

Spring的两大核心AOP与IOC，可以单独用于任何应用，包括与Struts等MVC框架与Hibernate等ORM框架的集成，目前很多公司所谓的轻量级开发就是用 Spring + Struts(2)+Hibernate。
Spring MVC就是一个MVC框架，个人觉得Spring MVC annotation式的开发比Struts2方便，可以直接代替上面的Struts（当然Struts的做为一个非常成熟的MVC，功能上感觉还是比Spring强一点，不过Spring MVC已经足够用了）。当然spring mvc的执行效率比struts高，是因为struts的值栈影响效率

spring mvc类似于struts的一个MVC开框架，其实都是属于spring，spring mvc需要有spring的架包作为支撑才能跑起来