面向对象奠基人之一Grady Booch说：The great thing about objects is they can be replaced.对象最伟大的之处是其可被替代（这也是使用OO的主要原因之一）。
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
每个对象都是可替代意味着高度的灵活性，我们曾经梦想的“按需装配”时代已经来临，由Ioc模式/依靠注射组成微容器可以帮助我们实现对象的可替代性。
Spring/HiveMind 包括Jdon Framework都是Ioc组成的一种微容器，在Java企业系统架构选择考量一文中，我已经在灵活性方面对几个组件架构进行了比较。
其中一个重要的疑问：EJB3是POJO吗？这里面有两个概念：EJB3是否支持POJO？EJB3本身是否是POJO？前者答案是肯定的，但是后者则曾经是否定的。
在回答之前，我们必须对POJO有一个具体了解，最初POJO是相对EJB提出的，Martin Fowler 对POJO定义是：我发现：人们已经忘记了原来正常的Java Object，因为这些对象还没有一个很非凡的名字，....这样我給它们取名为POJO(Plain Old Java Object), 一个POJO domain model轻易放在一起，快速build，在EJB容器以外运行和测试，并且不依靠EJB。http://mindprod.com/jgloss/pojo.Html
但是，随着EJB3支持POJO，POJO的概念从原来相对EJB的定义已经引申开来，代指一种相当灵活的对象，也就是可被随时替换的对象，不因为依附任何框架而不能被替换。
那么，EJB3本身是否是POJO？实际意义是EJB container是否是POJO，也就是说：EJB本身组件是否可被替换?
正如我在Java企业系统架构选择考量一文中所写，当我们只需要EJB3的集群，而事务等基础功能都不需要时，EJB服务器是否支持我们这种任意配置和切割？或者我想替代其中一个基础功能，是否可任意供我们切换，也就是Grady Booch那句话：对象是否可替换？
当然，在这场“EJB3是否是POJO”讨论中，有人引用一些老外名言：EJB3本身是否是POJO没有讨论意义，可惜说这话的老外自己的概念没有达到最新理念上。
那么，作为一种组件结构，是否可以既支持应用系统的任何一个组件对象可替换，而且也支持框架本身的组件也是可替换，这个境界是否可以达到呢？
完全没有问题，目前,开源软件HiveMind和Jdon框架都是支持彻底的可替换，所谓彻底的可替换就是框架本身一些功能也是可配置，可嵌入的，而不只是应用程序是可替换的。
这就实现了组件架构的完全的、彻底的可配置性，是一种Embeddable或Plug-in架构，这样的架构可答应开发者介入任何一个层次进行拓展和维护，从而形成强大的可定制性和可拓展性，可以使用建筑的一个比喻，这种Embeddable架构类似钢筋结构建筑，它只有固定几个框架和板筋，你喜欢划分什么样的房间完全由你来决定。唯一的限制是你的想像了。
现在，作为EJB3 container设计领先的开源软件JBoss即将推出JBoss 5版本，在其JBoss 5版本中，其微核心本身将是可配置的，最终将实现EJB3的彻底的可配置性。
我们看看JBoss Blog(http://www.jboss.org/jbossBlog/blog/)上这段文字：
JBoss微容器将是彻底的反转控制，依靠注射的轻量容器，它答应你通过XML配置POJO，这些POJO有自己的生命周期，能够作为服务Service，它并不需要JBoss的应用服务器，..大多数JBoss提供的功能将都会转为POJO，并且可配置...这些都将在2006年的JBoss 5版本中完全实现。
在这篇现场录像（http://www.javalobby.org/av/javazone/69/aardal-jboss）中 Thomas Roka-Aardal介绍了JBoss 5 – lightweight middleware with EJB3，他介绍了企业Java将被简化和增强，通过结合新的JBoss微内核，显示什么是真正的轻量应用服务器，它又是怎样影响未来企业开发市场的，中间件将会到处被看到。
对于现在大部分初学者来说，首先需要从jsp中嵌入Java代码的坏习惯中改变过来，将你的Java代码使用组件JavaBeans来实现，然后逐步走上面向组件（面向构件）的开发方式，进而上升到可彻底配置的组件化编程层次。
