contextual component model

语境组件模型的三句话解释

1. seam是根据组件定义构建对象的工厂
2. 创建完成后，seam在几个语境容器中选择一个把这个对象丢进去，这个对象就有了对应的生命周期和上下文关系，当然还能保存状态
3. 接下来，seam就能根据各个类中定义的metadata来把各个语境中的对象整到一起，让他们互动起来。

      回到unification上来了，Seam的unification是通过统一组件注册、注解、基于异常情况的配置、方法注入和统一的EL这些工具来实现的。

1.组件注册中心

       开始点名啦！seam把所有的JavaEE组件都放到统一的注册中心，无论你是EJB session Bean，还是JavaBean，Spring bean，JPA的entity bean，一个都不能少！所有拉进seam阵营的技术，都可以凭组件名称跟seam container要组件的实例，也可以通过seam container交换状态。blablabla，又点名了，一大堆。seam的container统一了Servlet API的变量scope，还很体贴的给程序员开辟了两个新的变量空间，conversation和business process，以便更好的支持用户交互。

       当然这些组件不是一生下来就掉进了蜜罐里，seam可是很辛苦的找遍了classpath中的每一个类，千辛万苦的把用注解标记的seam组件加到container中来的。这个神秘的注解，先不说，说了后面就没东西卖了！(是不是传说中的@Name?)

2.用注解，不用XML

       想当年XML配置编程出来的时候，是何等的风光啊！可最终，先贤们发明的神器给老百姓耍起来有那么点不顺手啊！虽然外部配置很灵活，但内容那么多，一有改动就这一下哪一下的，凡夫俗子很快就头晕眼花，顾头顾不了腚！Seam 就来了个返璞归真，把配置信息又放回代码里面。

     @Name

     和

<managed-bean>
     <managed-bean-name>
          NumberBean
     </managed-bean-name>
     <managed-bean-class>
         guess.NumberBean
     </managed-bean-class>
</managed-bean>

      你选哪一个？什么？还是喜欢XML？大哥，别走啊！您也可以在seam里用XML配置组件啊！您真得不再试试简单精确，玉树临风，稀里哗啦的annoatation?最起码您还能少敲几下键盘呢！

3.根据异常情况构建

      所谓根据异常情况构建，就是说软件都是固执己见的。通常，框架都喜欢依照当初的设计工作。你越符合他的默认情况，那你所要做的工作也越少。只有当软件功能与典型行为不同时，你才需要做些工作。

     注解可以告诉seam该怎么做，seam也尽可能的根据注解和命名规范来推测出声明相关内容，从而减轻你的负担。

4.给组件加上些服务

      既然对组件的请求都是发给seam container的，seam就有机会在他们的整个生命周期中管理这些实例。seam把这些对象裹上interceptors，封装成object proxy。这样seam就可以成为这些对象的操纵者，用interceptor给每个方法都加上隐含的应用逻辑。比如开始和提交事务，安全性检查等。如果因某种原因，不能使用默认行为，类定义中的注解会告诉这些interceptor如何应用这些额外的功能。

      unification藏宝图的最后一片！应用程序需要一种通用的方法访问container中的组件，这个重任落到了unified EL肩上。

5.让unified EL的手伸的更长

      unified EL可以用来解析变量，把组件绑定到JavaBean的属性和方法上。他最初是为了更好的整合JSF和JSP，为了查找managed bean和web层中的其他对象，作为JSF绑定机制的基础。然而由于他的可插入设计，他的影响远不止于此。

      EL的开放API允许注册自定义的解析器，这让EL成为了变量中心。使用EL的API，可以把不同的变量语境统一起来。

      Seam对EL的应用包括两个方面。首先是注册一个访问seam container的变量解析器，这样在程序中EL能出现的地方（那就是任何地方啦）就能访问seam组件。其次，seam大量的使用了EL，EL能出现在注解、配置文件、log和message 资源，JPQL查询，页面流定义，甚至业务流程中。