Question

上一篇 提到 Java bean 的规范虽然定义的不错， 但却没有获得意料中的成功， 尤其是 Java 帝国所期待的桌面开发组件化市场上。

我和小码哥多么期待 CSDN 也能出一期《程序员大本营》， 里边包含成千上万的 java bean 组件啊。

不要幻想了， 赶紧把 java bean 应用在服务器端才是正事。 小码哥建议先用在 jsp 上试试， 可以用 java bean 来封装业务逻辑，保存数据到数据库， 像这样： 这几千个 JSP 就像这碗面条一样，搅在一起， 根本理不清楚。

为了解决这个问题，小码哥又推出了 ：JSP Model 2 , 这是个模型真正的体现了 Model-View-Controller 的思想： Servlet 充当 Controller , jsp 充当 View Java bean 当然就是 Model 了！

业务逻辑， 页面显示， 和处理过程做了很好的分离。

基于这个模型的扩展和改进， 很多 Web 开发框架开始如雨后春笋一样出现， 其中最著名的就是 Struts， SpringMVC 了。

Java Web 开发迅速的繁荣了。

我们再一次体会到了开放的好处 ！ 但是好景不长， 自从 Java 帝国统治了所谓的“企业级应用”开发领地， 各种各样的游行和抗议层出不穷： “我们要分布式” “我们要安全” “我们要事务”

“我们要高可用性” “......” 帝国分析了一下， 其实这些程序员的诉求可以归结为： “我们只想关注我们的业务逻辑， 我们不想， 也不应该由我们来处理‘低级’的事务， 多线程，连接池，以及其他各种各种的‘低级’API， 此外 Java 帝国一定得提供集群功能， 这样我们的一台机器死机以后，整个系统还能运转。 ”

我们不能坐着不管， 企业级应用是我们的命根子。 小码哥彻夜工作， 最终拿出了一个叫做 J2EE 的东西， 像 Java bean 一样， 这还是一个规范， 但是比 Java bean 复杂的多， 其中有：

JDBC : Java 数据库连接， 没有数据库的支持怎么能叫企业级应用？

JNDI : Java 命名和目录接口， 通过一个名称就可以定位到一个数据源， 连 jdbc 连接都不用了

RMI ： 远程过程调用， 让一个机器上的 java 对象可以调用另外一个机器上的 java 对象 ， 你们不是要分布式吗？

JMS : Java 消息服务， 可以使用消息队列了， 这不是企业级应用非常需要的吗？

JTA ： Java 事务管理， 支持分布式事务， 能在访问、更新多个数据库的时候，仍然保证事务， 还是分布式。

Java mail : 收发邮件也是必不可少的啊。

刘欣注： J2EE 后来改成了 Java EE。

当然还有最最最重要的升级， 小码哥把 java bean 变成了 Enterprise Java bean , 简称 EJB 。

小码哥宣称： 使用了 EJB， 你就可以把精力只放在业务上了， 那些烦人的事务管理， 安全管理，线程 统统交给容器（应用服务器）来处理吧。

我们还提供了额外的福利， 只要你的应用服务器是由多个机器组成的集群， EJB 就可以无缝的运行在这个集群上， 你完全不用考虑一个机器死掉了应用该怎么办。我们都帮你搞定了。

使用 Session Bean ， 可以轻松的处理你的业务。

使用实体 Bean (Entity bean ) , 你和数据库打交道会变得极为轻松， 甚至 sql 都不用写了。

使用消息驱动 Bean(Message Driven bean ) , 你可以轻松的和一个消息队列连接， 处理消息。

听起来很美好是不是？

企业级开发领地的程序员们欢呼雀跃， 坐上了 J2EE 这条船，似乎一下子高贵起来， 开始鄙视微软的 ASP, 开源的 PHP, Python 等“不入流”的语言了 。

Weblogic , Websphere 等符合 J2EE 规范的应用服务器趁势而上， 摇旗呐喊， 仿佛一个新的时代要来临了， 当然他们在背后一直闷声发大财。 有句古话是对的， 捧的越高， 跌的越惨。

很快，大部分的程序员就发现， 美好的前景并没有实现， EJB 中用起来极为繁琐和笨重， 性能也不好， 为了获得所谓的分布式，反而背上了沉重的枷锁。

实体 Bean 很快没人用了， 就连简单的无状态 Session bean 也被大家所诟病， 其中一条罪状就是“代码的侵入性”。

也是， 小码哥定义 EJB 的时候没考虑那么多，程序员在定义一个 Session bean 的时候，需要写一大堆和业务完全没有关系的类。

还需要被迫实现一些根本不应该实现的接口及其方法： 为了哪怕一点点业务逻辑， 我们都得写这么多无用的代码 ！ 程序员们出离愤怒了！

他们发起了一场叫做 POJO (Plain Old Java Object) 的运动， 高唱这 POJO 之歌， 要求我们整改。

他们希望这个样子： public class HelloworldBean{ public String hello(){ return "hello world" } } 与此同时，他们还过分的要求保留事务了， 安全了这些必备的东西。

程序员确实不好伺候， 但是我们已经被 Weblogic, Websphere 这些大佬们“绑架”， 想改动谈何容易 ！

2002 年， 小码哥看到了 Rod Johnson 写的一本书《Expert one on one J2EE development withoutEJB》 ， 赶紧跑来找我： “老大， 坏了坏了， 你快看看这本书吧， 这个叫 Rod 的家伙写的这本书直击我们的命门，这厮要搞 without EJB” （注： 虽然这本书翻译的很差，但由于是 spring 的开山之作，还是值得读一下， 最好中英文对照)

岂止是 without EJB, 他还“偷偷的”推出了一个叫什么 Spring 的框架， 已经迅速的流行开了。

Spring 框架顺应了 POJO 的潮流， 提供了一个 spring 的容器来管理这些 POJO, 好玩的是也叫做 bean 。 看来我们的 java bean 走了一圈又回到了原点。

对于一个 Bean 来说，如果你依赖别的 Bean , 只需要声明即可， spring 容器负责把依赖的 bean 给“注入进去“， 起初大家称之为控制反转(IoC)

后来 Martin flower 给这种方式起来个更好的名字，叫“依赖注入”。

如果一个 Bean 需要一些像事务，日志，安全这样的通用的服务， 也是只需要声明即可， spring 容器在运行时能够动态的“织入”这些服务， 这叫 AOP。

后来我和小码哥商量， 我们 EJB 也学习 Spring , 简化开发和配置， 但是为时已晚， Spring 已经成为事实上的标准了！程序员已经被 spring 拉走了！

不过令我们欣慰的是， spring 和 spring mvc 极大的增加了我们对 web 开发领地的统治力, java 帝国更加强盛了。