seam integrates jsf, jpa, and pojo components

1.把EJB3 献给WEB 层

      设计EJB3的时候，并没有考虑让他的组件能够直接绑定到JSF的view。虽然EJB3组件的安全性，可扩展能力，事务能力，线程安全性很诱人，但如果她完全和web层隔离，仅能通过JSF的back bean这个中介访问，她的优点就大打折扣了。因为整合工作很复杂，EJB3应用在web应用程序中会受到很多限制，EJB3组件不能访问web层中的任何数据（request, session, application），也不能访问JSF组件树。因此妨碍她们进入程序中最基本的部分。另外在web层中使用EJB3组件时，一致性也是个难题。唯一的办法就是建立一个中间层。seam就是英雄啊，他为web层提供了一个管理EJB3组件状态的方法，使web层可以安全的使用他们。

2.给JSF挂上一个更好的Back End

     JSF的 managed bean容器需要用繁杂的xml配置（相比EJB3的注解方式的确比较繁杂），  依赖注入的实现也不太灵光。他当然也不具备EJB3组件所具有的优点。实现业务逻辑，还是EJB3更适合。

     Seam上来直接把managed bean废了，她把JSF 的UI 组件放到EJB层中，让EJB3组件替代了JSF的managed bean和action listener。

3.Seam是？

     Seam不仅仅是为了满足“这些东西要整合到一起”而搞出来的。他还封装了很多很好的第三方类库包。用dell和Mac的区别描述了下seam给我们开发人员带来的简单生活。不用做那么多选择了，听说过“选择困难症”吗？刘青云和张柏芝一起演过一个什么片子来着？

      用seam写程序，只要做两个选择（广告词）。一个是state provider，一个是persistence provider。state provider 负责处理应用逻辑，响应UI事件。persistence provider 负责数据到存储层的读取和写入。seam管理下的persistence provider使得persistence context可以跨越一系列的页面，也可以在多个组件中共享。

      用JavaBean和hibernate还是用EJB3？还是EJB3加上JPA和JavaBean混着来？Seam出来前，把他们弄到一块可累人呢，现在不用自己整了。集中注意力，看看啥是seam的contextual component model。