seam in action 第一部分 1.2

1.2选择Seam

    你可能会认为Seam就是在大量框架中进行竞争的一个web框架。事实上，把Seam看作一个web框架十分不恰当。Seam远比传统的web框架，如Struts，涉及的范围更广范，最好把它说成是一个应用堆栈(application stack)。

1.2.1一个全应用堆栈

    我们来看下应用堆栈和web框架之间的区别。Web框架类似于客人，这些客人在吃饭的时候即时出现，吃完后就离开走人。他们享受并受到大家的关注，但是他们通常不帮忙。他们那样来的还那样走。相比之下，应用堆栈好比是一个帮助计划宴会、帮助购物、做饭、布置会场、服务、制作咖啡的人，并且在宴会结束的时候帮助收拾。他们坚实可靠并且足智多谋。但可悲的是他们的工作通常是不为人所知。

在一个每个人都想成为摇滚明显的世界里(即web框架)，Seam是你的实用的伙伴，是你的大厨。Seam应用堆栈包括框架、类库、构建脚本以及项目生成器、IDE集成、基础测试类、可嵌入的JBoss容器，而且与许多技术集成。Seam显然是个工作努力的家伙，图1.2是Seam将java技术整合到一个典型应用中的截面图。

 

    尽管这个图给你展示了在seam应用中所使用技术的理念，但是它并没有给你一幅清晰的关于Seam目的和它存在意义的图画。为了了解为什么创建Seam，你需要知道它所面临过的挑战。尽管Java EE 5的发布已经为向着企业级Java开发建立敏捷平台前进了一大步，但是它在JSF管理的web层组件和JEB3管理的业务层组件之间留下了一个相当大的鸿沟，因此需要一个将二者连接起来的桥梁纽带。

1.2.2为什么创建Seam

        Java EE 5规范为了创建基于web的业务应用，合并了两个关键组件架构(用于创建可重用对象的规范)，：Java Server Faces(JSF) 1.2和Enterprise JavaBeans（EJB）3。JSF是一个web层的标准表现框架，它提供了用户界面组件模型和服务器端的事件模型。EJB3是一个标准的编程模型，它用来创建安全的、可以访问事务资源的可扩展业务组件。EJB3也包括Java Persisten API(JPA)，JPA定义了在关系数据库和Java实体类之间传输数据的标准持久化模型。

       除了都是Java EE5的规范之外，刚才说的两个架构几乎没有相似之处，两者就像硬币的正反面。这种沟通障碍为各有着巨大潜力的技术蒙上了一层阴影。尽管开发人员能够使这两中Java EE层之间共同协作，但是这需要许多“粘结”代码。Seam担负起了这个职责，使JSF和EJB 3能够彼此一致，这“熨平”了Java EE5规范中最粗糙的一点，并填补了Java EE平台演化过程中完全缺少的一个环。Seam已把自己定位为将来Java EE规范的蓝本，到现在为止，已有三个Java 请求规范被接受了：JSR299(Web Beans),JSR314(JavaServer Faces2.0)和JSR303(Bean Validation)。Seam不是像图1.2所示就只能和JSF或者EJB3结合，你可以调换视图技术，如Wicket，Tapestry，GWT和Flex，来代替JSF。在业务层，Seam支持使用JavaBeans作为业务组件并且自夸可以与Spirng容器集成，相对于EJB3来说这两者是更好的选择。

       成为Java EE将来重要的一部分和成为许多开源技术的一个集成点并不是促使创建Seam的初衷，这只是Seam要设法实现的。像大多数的软件项目，Seam也是始于解决某一个开发人员的问题。

真实的故事

随着故事(真实的)的发展，Gavin King 受够了那些不正确使用Hiberante的开发人员，这种情况在无状态设计的Spring框架中激增。他意识到不将JSF和EJB3集成只会进一步滥用作为JPA提供者的Hhibernate，于是他决定提高并构建一个能够让持久化上下文(Hibernate Session或者JPA EntityManager) 超越层级以及允许有状态会话Bean直接对JSF组件做出响应的基础架构。为了支持这个构想，Seam鼓励采用有状态而且有效的架构。因此，构建在Seam之上的应用不用费劲儿就能从一个用户交互(或者事件)持续到下一个交互，这个特性被称为一个web对话(conversation)，专注于变量作用域，从而使Seam上下文相关。

       为项目取名为Seam，是因为它提供了将JSF和EJB3结合在一起的基础并且使他们能够在同一个沙箱中很好的通力合作。在处理Seam和EJB3的不匹配问题过程中，Seam架构师扩宽了它的解决方案，不只EJB3可以作为业务组件，其他任何POJO也可以作为业务组件。Seam的统一组件模型将EJB3编程模型支持的隐含和声明式的服务，例如事务、拦截器、线程、安全引人到非EJB组件，如JavaBeans和Spring beans。对于非EJB组件，Seam负责处理Java EE5注解——或者来自Seam API且与Java EE5注解同义的注释——将其编织成受管服务。除非对EJB3有特殊需要你可以重新考虑使用EJB3，否则，选择JavaBean代替EJB就行了。你可能已经听说过了，不管是如何选择，你不必把seam应用非得部署到JBoss应用服务器上。

1.2.3揭穿“受限于提供商”传言

       对于说Seam是JBoss为核心的技术或者说使用Seam就会受困于JBoss而无法摆脱它了这样的传言我不想回避。Seam的开发团队会毫不犹豫地做出与JBoss发展方针的相背的建议。Seam应用堆栈就是为人所知的、能够很好协同工作的、同类技术中最好的技术聚合。与Struts是一个Apache技术或者说Spring是一个SpringSource技术来说，Seam己经不是一个JBoss技术了。一项调查表明在企业级java领域中，JBoss之外的大多数成功的复杂项目，例如Spring、Hibernate、Eclipse以及Java EE平台本身都是有付薪水的组织支持的。而Seam是一个开源的，可以由任何人和社区来驱动开发。尽管项目是在JBoss/Red Hat旗下由JBoss Labs主持，但是你可以复制、修改和共享源码。特别是，JBoss Seam的许可证是基于Lesser GNU Public License，LGPL被认为更具有灵活性的选择。

       Seam被设计为容器不可知的并且做出了许多努力，确保Seam与所有的主流应用服务器兼容，包括BEA WebLogic，IBM WebSphere，Oracle Container for Java EE，Apache Tomcat，和GlassFish。但是兼容性问题不止是部署方面，由Seam带给Java EE的改进正以Java Community Process(JCP)作为媒介作为标准回馈给平台，这在JSR299中有所记录：如前面提到的Web Beans。该JSR的目标是EJB组件模型和JSF受管bean组件模型统一，形成构建基于web应用开发的相当简化的编程模型。该JSR的结果孕育一个Seam创新实现的替代品。

       知道了Seam为什么会存在，并且你也相信不会由于选择这个技术而受限于JBoss，那么，现在需要根据Seam的优点考虑它是否适合你。虽然Seam已经拯救了Java EE，但是作为你们的开发框架它符合要求吗？

1.2.4 对Seam做出决策

       真的需要另一应用框架吗？Spring不就是一个可以统治现有技术的框架吗？我要用Ruby on Rails的成功和Java开发人员波涛汹涌般地涌向它来证明我们需要一个适合Java的应用框架——或者，在一些开发人员头脑中，依然需要整体的编程环境。那么，你是否要随大流呢？我的建议是先看看再说。

       承诺框架可以简化开发工作一般来说只是应酬话，因为用框架创建一个用于宣传的blog应用没有实际价值。为了赢得被称为企业级软件的权利，框架要不加掩盖地面对现实世界中的挑战，帮助开发人员创建设计良好的、健壮的和可读性好的代码，这就是Seam地目标。Seam消除了复杂性并使经过检验的类库更容易使用。Seam不是背弃无处不在的Java EE平台，而是要充当黏合剂使Java EE真正地集成在一起。Seam不是鼓励你忘掉任何你知道的东西，而是通过找到一个让你以更敏捷的方式使用Java EE服务的方式。同时它通过扩展和与第三方集成的方式为你提供了足够多的新玩意，让使用Seam变的充满乐趣。

下面是Seam带给Java EE许多改进中的一小部分例子，所有这些都成功地使平台得到了简化。

n         消除了JSF中令无数人痛恨的缺点

n         改善了JSF和事务性业务组件之间的通讯

n         合并了没必要的层并且去掉了被动的middle-man组件

n         提供了上下文状态管理的解决方案，不鼓励使用无状态的架构（即过程性的业务逻辑）

n         管理持久上下文(Hibernate Session或者JPA EntityManager)来避免在视图和随后请求中的懒初始化异常

n         提供了在用例期间延续持久化上下文的手段

n         利用有状态页面流使视图页面连接在一起

n         将业务处理流程带入web应用世界

n         接入一个由JAAS支持的在JSF视图ID级别进行的基于POJO的认证和授权机制，可通过EL进行访问，并且可以使用声明规则和ACLs来扩展

n         提供了一个用于在非Java EE环境中测试的嵌入容器

n         随分发包带有30多个参考实例

     正如你所看到的，Seam没有回避解决平台中的问题，特别是JSF中的那些问题。对于现有的JSF开发者，第一点就有足够理由使用该框架。他们可以证实JSF有时让人相当痛苦的事实。在Seam的帮助下痛苦将不复存在了。第二点证明了在基于标准的环境中Seam的用处，Seam在其中相处的很融洽。但是Seam不只停留在这些上，它鼓励开发人员合并不必要的分层以简化架构，并且提倡使用长时间存在的上下文减轻状态管理的负担。除了改善编程模型，Seam提供了一个用于准备基于Seam工程的脚手架工具；从已有的database schema生成一个创建、读取、更新、删除数据的应用；以各种方式提供Ajava支持。