【IT168 技术文档】
灵活性/定制性/透明性

　　当然这个答案有时我们自己也可能很难给出，那么我们还需要从其他角度来考量EJB和非EJB之选，例如笔者曾经经历一个大型实时娱乐平台社区系统，从规模上说肯定是大型系统，设计目标10万人在线，从这个角度非选用EJB不可！

　　但是，EJB因为还有事务机制，虽然应用程序可以选择失效EJB事务，但是EJB容器设计因为考虑了事务，所以在其内核上总是会显得臃肿，是一种累赘，这也是一种重量表示，不需要的东西存在肯定会影响效率，那么难道我不能根据我的需求，对EJB整体包括EJB容器进行可配置式的切割？也就是说，我上面这个案例只需要EJB的分布式计算功能，其他的功能我都拆除，只剩余我需要的功能能运行就可以了，轻装上阵。

　　可惜，这种任意切割，应需而定的目标在EJB3标准还没有被重视，所幸的是，Ioc/AOP技术为这种目标实现提供了实现可能，但是，只有Ioc/AOP还是不够，特别是看Ioc的范围，如果你只把应用系统组件纳入Ioc管理时，自由解耦只属于应用系统，我上面案例的目标还是无法达到，当你把框架本身组件也纳入Ioc管理时，任意切割，应需而定的目标才真正实现。

　　Spring和EJB3属于“只把应用系统组件纳入Ioc管理”，这从JBoss 4.0版本可以看出；那什么框架会把框架本身组件也纳入Ioc管理呢？Apache的Hivemind和笔者开发的Jdon框架。

　　什么样的组件可以被纳入Ioc管理呢？POJO组件，POJO这个概念其实当初是针对EJB缺点而推出，EJB要求应用系统的组件必须继承或依赖EJB容器，这样使得调试变的不方便，但是后来，POJO的概念已经不只最初这些概念，POJO代表那种与周围完全脱离关系、自由自在的Object了，如果应用系统的Model或者Service都是POJO，意味着你的应用系统不依赖任何其他系统，解耦性灵活性高。

　　POJO是因为EJB而提出的，当EJB自己倾向POJO时，大家都在宣称自己是POJO时，POJO概念就没有立足点了，这也是Java领域哭笑不得的现象，但是我个人更倾向把非EJB的JavaBeans组件通称为POJO。

　　Hivemind的Ioc依赖注射部分功能和Jdon框架非常类似，当上百个POJO组件配置时，完全不必指定它们之间的依赖关系；你可以将自己应用程序的组件注册到Registry中，这样Hivemind将帮助你启动这些组件，正如你在Jdon框架中将你的组件写入mycontainer.xml中，Jdon框架也将自动启动你这些组件，并解决它们之间的互相调用，包括和框架本身组件互动。

　　HiveMind和Jdon框架定义的POJO Service有如下特点：

　　不象EJB那样缺乏本地透明化(location transparency)概念，这些POJO Service总是能定位到同样一个JVM；也不象基于XML的Web服务web services那样没有语言透明(language transparency)概念，这些POJO Service总是可以被一组Java接口来概括替代(通过调用Java interface来替代调用这些具体Service)；当然，更不会类似JMX或Jini，不能进行service的热装载（ hot-loading）。

　　注意：当Ioc/AOP提供高度灵活的同时，已经有初学者开始抱怨Spring的过分灵活，那么比Spring在组件上更灵活的Jdon框架只能算是一种追求极端，它不一定构成你进行架构选择的主要依据！

　　上面这些讨论只是表明在灵活性（解耦性/透明性）这条需求道路上深究下去的选择，你自己的应用系统需求会产生各种不同的要求，有些要求甚至是极致的，这种偏向程度就成为你架构选择的目标，如果你的这种极致要求在目前Java世界里还没有可选框架时，那么你就要动手自己做了，这也说明什么时候你开始自己做框架（如Jdon框架），虽然在大多数情况下我们是不必要自己发明轮子的。