什么样的人更伟大，站在巨人肩膀上的人。
当
COM/DCOM
仅仅局限于
Windows
平台上时，
CORBA
的跨平台应运而生；当
CORBA
开发部署应用过于繁杂时，
EJB
石破天惊；当
EJB
测试不利侵入严重效率不佳开发成本依然很大之际，
Spring
当仁不让。新事物的产生首先吸收了前人的优势，在此基础上不断完善改进，直到让不断成熟的用户群满意。
从
EJB
说起，其技术承诺是解决
CORBA
的所有问题并降低其复杂性，其定位于大型应用，尤其是对高可靠性、分布式、远程访问、集群等场合。但一开始
EJB
提出并解决了
JavaBean
不具备的系统级服务的特性，并着实降低了
CORBA
的复杂性，也可以跨越平台，受到人们的钟爱，甚至在没有任何意义的情况下也在应用程序中使用到
EJB
，当使用不到
EJB
本身的扩展性好以及其它优点时，开发者群开始抱怨甚至倒戈
EJB
。这也符合历史，当狂热之后，便是思想成熟后的反思，反思驱使改良，改良就是进步。
EJB
提出了
EJB
组件的生成、销毁、钝化、锐化、管理由容器来做，这本身就是依赖倒置的前身。当人们提出了工厂方法模式（生成单一对象）、抽象工厂模式（生成一系列对象）、
ServiceLocator
模式（查找某种已有的服务）等模式时，已经在使用这控制反转的思想。更甚者，人们提出了回调思想，用底层的框架调用上层的应用，而不是一般意义的上层访问底层，
EJB
大量使用了
Callback
钩子方法，比如
EJBCreate
，
EJBRemove
等；当
TemplateMethod
模式再次在应用中归纳出时，当我们这个也模版模式那个也模版模式时，
Spring
将此运用到淋漓尽致，其封装
StatelessSessionBean
到
AbstractStatelessSessionBean
之类为开发者封装了
EJB
使用的侵入性时，我再一次感想，何以是思想真正得以了运用？！这些都可以关联涉及到
IoC
思想。
IoC
本质是为达到松耦合的目标，正在这个时候另外的一个思想
AOP
随着人们不断的推敲研究正茁壮成长着。
OOP
面向业务逻辑，人们在
AOP
是否可取代
OOP
的摸索中，发现有许多比如日志、事务、安全等系统级的服务并不属于某个模块而是贯穿于整个业务，如果
OOP
比作是纵向的业务逻辑，那
AOP
岂不正是横面的服务。但是如何取得具备业务逻辑功能的业务对象？
IoC
不正是把对象的创建、管理、销毁都放到框架容器中处理的么，
IoC
与
AOP
的结合点一出现，就整个业界带来了前所未有的冲击。思想都是现成的，思想的发展升华却是空前的。
EJB2
终于被批驳的体无完肤，虽然有些不合理，
Spring
，
HiveMind
等一大批优秀框架竞相而出，不是喧闹，而是对应用的经验的累积。
EJB3.0
也走上了这条路。更有甚者，
JBoss
推出了
MicroContainer
容器，以打破服务迁移的困顿。
站在巨人肩膀上的人才是更伟大的，无论是
IoC
还是
AOP
，概念是新的，但是其思想的应用却早已出现，甚至有变相的应用，但却没有突破了以前的圈子。说成一个是改良一个是革命，应该不属为过。量的累积导致质变的过程也得以体现。
由此不由得想起
JDK
提供的
reflect
机制，当
JDK
牛牛人指定并推出后，当
JBoss
创始人灵光一闪，推出
JBoss
后，反射机制被人们认识到，而刚刚说的又哪个离开了反射？！
呵呵，看来，巨人的肩膀扛起一波又一波的人是没有问题的，我们开始攀登？！呵呵。从业界的发展看，浮躁是不利的，累积总结深入到底层本质方是正确之道。
新补充续篇：
什么样的人更伟大，站在巨人肩膀上的人---由业界思想进化的反思(二:IoC价值强化篇)