这是一篇关于未来的预测。预测未来是件危险的事情，既可能在未来也可能在现在遭到嘲笑。尽管如此，阐述一个美好的未来愿景可能有助于实现那个未来。
我的预测是，EJB3编程模型最终将像现在的JavaBeans一样，成为Java开发的一部分。
这是一个大胆的断言，有些自大。JavaBeans是一个如此成功的组件模型，以至于我们现在几乎不再考虑使用它。我们不说“我要写一个JavaBean来做blah”，我们通常只是说“我要写一个类来做blah”，然后不自觉地遵循JavaBeans规范。我们很久以前就忘记了JavaBeans容器的原始定义（BeanBox，有人记得吗？），现在几乎无处不在地使用JavaBeans。JavaBeans的定义与其说是JCP规范的一部分，不如说是Java文化的一部分。
我对是什么使编程模型成功非常感兴趣。所以我试图列出我认为JavaBeans之所以如此成功的原因。
JavaBeans组件是
- 易于编写和修改
- 面向对象的
- 有一定的自我文档化
- 足够通用——组件模型并没有对bean容器的本质或组件的目的做出太多假设
- 细粒度
- 可以在任何容器之外完全执行
这些属性使得使用JavaBeans模型来处理设计者未曾预料到的事情变得容易。JavaBean“容器”现在与编程模型创建者的期望大不相同。同时，我们使用JavaBeans本身来构建各种东西，而不仅仅是GUI组件！
JSR-220之前的EJB失败在上述大多数点上。我不会再次重述当前EJB模型的缺点，因为这个话题现在已经非常无聊了。我将重点讨论模型的一个特定部分，我认为这是关键：部署描述符。
EJB 2.x的部署描述符既不适用于文档目的，也不足够通用。它太嘈杂，无法帮助文档化组件，也太具体，以至于EJB规范设计者理解的EJB容器环境无法由其他容器重用。
有趣的是，JSR-220定义的基于注解的元数据似乎没有这些问题。注解是出色的自我文档，注解的性质也相对通用。例如，@Stateful、@Stateless、@Entity、@Table、@Remote、@ManyToOne等注解，关于组件本身的语义比关于容器的语义说得多。
这些新EJB3风格注解的通用性意味着，当我编写EJB时，我总是在表达我对业务问题的解决方案，而不是容器的需求。更重要的是，这意味着一个容器
如果不是JSR-220的EJB3容器，也能消费这些注解，并对其做有用的事情。
当然，有一些注解和注解属性与规范文本非常具体，但我认为这是例外而不是规则。
我认为EJB3组件模型的其余规定同样通用。实际上，它们并没有超出JavaBeans约定太多。因此，像JavaBeans一样，EJB3模型满足上述列表中的每个点。因此，我倾向于将EJB3组件模型解释为JavaBeans的增强：具有这些通用注解定义的额外语义的JavaBeans。
希望那些不构建EJB容器的人能够重用EJB3注解和组件编程模型。
以下是一个具体的例子，说明我希望看到的情况。我认为会话bean是完美的Web框架动作！目前，如果我们想从Struts调用EJB容器，我们必须编写一个Action并显式查找和调用会话bean。但想象一下，如果这个动作本身就是一个局部、无状态的会话bean：我们就可以在Web层获得EJB容器的所有服务。这还只是开始。如果我们的动作是会话bean，那么我们就不需要在那个恶魔般产生的HashMap（我通常在触摸那个东西后需要洗个澡）中保持与用户的关联状态，而是可以将会话状态保存在有状态的bean中（每个应用程序事务一个，当然）。我知道你在想哦，但我不想只为了得到一个Web动作而编写整个EJB
。回头看看：那不是一个完整的EJB
；那只是一个EJB
。记住，在EJB3中，会话bean只是一个带有可能两个或三个注解的JavaBean。事实上，你甚至不会考虑编写EJB
；你只是编写一个@Stateless类
。
