J2EE 对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组 件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实 现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE 中， 这个运行在一个独立的服务器上，并封装了业务逻辑（执行特定任务的类）的组件就是EJB（Enterprise Java Bean）组件。 ———————————————— 版权声明：本文为CSDN博主「jojo52013145」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：blog.csdn.net/jojo5201314…
而EJB的实现又是基于RMI，RPC。RMI自己建立套接字和网络请求，依赖于计算机网络知识。 RMI的大致工作原理： 服务器端提供服务，服务中要暴露可以调用的远程方法，以接口的形式表现，这样在客户端可以通过服务接口来调用远程方法，实现复杂的业务逻辑。在服务器端，首先要对接口中提供的方法实现，以便客户端调用能够完成一定的业务逻辑；接着需要生成Skeleton，在Skeleton中真正地实现了对商业方法的调用，完成了客户请求的调用的过程，将获取到的调用方法的结果通过序列化机制返回给客户端，进行应答。在客户端，通过Stub来接收服务器返回的数据（对象），即在这里进行了反序列化，也就是读取网络传输的字节流，进而进行重构。在Skeleton和Stub中，都对网络通信进行了处理，例如建立套接字，建立网络连接，为实际的业务需要做好准备。
作者：技能树IT修真院 链接：www.zhihu.com/question/62… 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
很快，大部分的程序员就发现， 美好的前景并没有实现， EJB中用起来极为繁琐和笨重， 性能也不好， 为了获得所谓的分布式，反而背上了沉重的枷锁。
实体Bean很快没人用了， 就连简单的无状态Session bean 也被大家所诟病， 其中一条罪状就是“代码的侵入性”。
也是， 小码哥定义EJB的时候没考虑那么多，程序员在定义一个Session bean的时候，需要写一大堆和业务完全没有关系的类。
还需要被迫实现一些根本不应该实现的接口及其方法： 为了哪怕一点点业务逻辑， 我们都得写这么多无用的代码 ！ 程序员们出离愤怒了！ 岂止是without EJB, 他还“偷偷的”推出了一个叫什么Spring的框架， 已经迅速的流行开了。
Spring 框架顺应了POJO的潮流， 提供了一个spring 的容器来管理这些POJO, 好玩的是也叫做bean 。
看来我们的java bean 走了一圈又回到了原点。
对于一个Bean 来说，如果你依赖别的Bean , 只需要声明即可， spring 容器负责把依赖的bean 给“注入进去“， 起初大家称之为控制反转(IoC)
后来 Martin flower 给这种方式起来个更好的名字，叫“依赖注入”。
如果一个Bean 需要一些像事务，日志，安全这样的通用的服务， 也是只需要声明即可， spring 容器在运行时能够动态的“织入”这些服务， 这叫AOP。
后来我和小码哥商量， 我们EJB也学习Spring , 简化开发和配置， 但是为时已晚， Spring 已经成为事实上的标准了！程序员已经被spring 拉走了！
他们发起了一场叫做POJO (Plain Old Java Object)的运动， 高唱这POJO之歌， 要求我们整改。 mp.weixin.qq.com/s?__biz=MzA…
spring是个啥，spring是个框架。框架是个啥。 Spring Ioc，控制翻转又称依赖注入。
Spring 的启动化过程，也相当于Spring IOC容器的启动会过程，也就是建立上下文ApplicationContext的过程，已ApplicationContext的实现类ClassPathXmlApplicationContext为例，ClassPathXmlApplicationContext的构造函数代码如下：
