那些确实没有状态的组件（主要是无状态Session Bean）总是运行在无状态上下文中（实际上就是上下文无关）。 无状态组件没什么太大的意思，也有争议认为它们不十分面向对象。但不管怎么样，它们还是很重要，并且通常很有用。

事件上下文是“最窄”的有状态上下文，是Web Request 上下文的泛化，用以包含其他种类的事件。 然而，与JSF请求的生命周期相关联的事件上下文是事件上下文最重要的实例，并且也是你最常打交道的。 与事件上下文相关联的组件在请求结束时被销毁，但是它们的状态至少在请求的生命周期中是存在并且是定义良好的。

当你通过RMI或者Seam Remoting调用Seam组件的时候，一个事件上下文将为这个调用而被创建和销毁。

页面上下文允许你将状态与一个渲染页面的实例相关联。 你可以在Event Listener中初始化状态，或者在实际渲染页面的时候初始化状态，任何源于该页面的事件都可以访问到这些状态。 这在支持像可点击列表这种的功能时特别有用，列表的内容通过服务器端的数据变化产生。 实际上状态被序列化到了客户端，因此在多窗口操作或者回退按钮的时候，这种结构是非常健壮的。

业务会话上下文是Seam中最核心的概念。conversation（业务会话）是从用户的视角看待的一个工作单元。 它可能跨越与用户交互的多个Servlet、多个请求，和多个数据库事务。但是对用户来说，一个业务会话解决一个单一的问题。 例如说：“预订酒店”，“批准合同”，“创建订单”都是业务会话。 你可以将业务会话理解成对一个“use case（用例）”或“user story（用户故事）”的实现，当然特定的业务关联并非与此类例子完全一致。

业务会话保存关于“在此窗口中，用户正在干什么”的状态。在任何时间，一个用户可能同时位于多个业务会话活动中，一般是在几个不同窗口中。 业务会话上下文让我们可以确保不同业务会话的状态不会互相干扰，不会导致Bug。

你可能要花上一点时间才能习惯以这一业务会话的观点来思考你的应用程序。 但一旦你习惯于它，你会喜欢上这个术语，并且再不会不用业务会话来思考了！

一些业务会话仅存在在一次请求中。跨域多个请求的业务会话必须通过Seam提供的annotation注解来划分。

一些业务会话同时也是tasks（任务）。任务是一种业务会话，它特指一个长时间运行的业务流程，当正确完成后，可能会触发一个业务流程状态的转换。Seam为任务划分提供了专门的注解。

业务对话可以是nested（嵌套）的，一个业务对话嵌套“在”一个更大的业务对话中。这是一项高级特性。

通常，业务对话状态实际上由Seam保存在Servlet Session 中，跨越请求。Seam实现了可配置的 conversation timeout，可以自动销毁不活动的业务会话，这就可以确保，如果用户取消对话，用户的登录Session中保存的状态不会无限增长。

对于在一个长时间运行的业务会话中所产生的并发请求，Seam按顺序执行。

除此之外，Seam也可以配置成把对话状态保存在客户端浏览器中。

Session上下文保存与用户登录session相关联的状态。虽然当需要在多个业务会话中交换状态的时候这很有用，但我们一般不建议使用Session 上下文保存组件，除非是保存有关登录用户的全局信息。

在JSR-168 Portal环境下，Session上下文代表Portlet上下文。

业务流程上下文保存了长时间运行的业务流程相关的状态。这种状态由BPM引擎（jBPM）管理和持久化。 业务流程跨越多个用户的交互，因此状态在多个用户之间通过良好定义的方式共享。 当前的任务决定当前的业务流程实例，业务流程的生命周期通过外置的 process definition language（流程定义语言） 来定义，因此没有特别的annotation注解用于划分业务流程。

Application上下文就是Servlet规范中的Servlet上下文。应用程序上下文在保存静态信息方面有用，例如配置数据，引用数据或者元模型。 例如，Seam把自己的配置和元模型保存在应用程序上下文中。

上下文定义了命名空间，一组 context variables（上下文变量）。 这些工作很类似Servlet规范中对Session或Request attributes的定义。 你可以绑定任何你喜欢的值到Context Variable，但通常我们会绑定Seam组件实例到Context Variables。

因此，在上下文中，组件实例是通过上下文变量名字来辨别的（通常是这样，但并非绝对，就和组件名称一样）。 你可以通过程序在特定范围内访问被命名的组件实例，这是通过 Contexts 类进行的，它提供了对 Context 接口的几个线程绑定的实例的访问：

User user = (User) Contexts.getSessionContext().get("user");

你也可以通过名字来设置或修改变量值：

Contexts.getSessionContext().set("user", user);

但通常，我们通过注射（injection）来从上下文中获得组件，并且通过反向注射（outjection）把组件实例返回上下文。

有时候如上面的例子所示，组件实例是从某个特定的已知范围内获取的。 其他的时候则是通过 priority order(优先级顺序) 在所有有状态范围内搜寻。这个顺序是这样的：

你可以通过调用 Contexts.lookupInStatefulContexts() 来执行带优先级的搜索。你在JSF页面中通过名字访问组件的时候，执行的就是这种带优先级的搜索。

Servlet和EJB规范都没有定义任何关于如何管理来自同一个客户端的并发请求的条款。 Servlet容器简单地让所有的线程并发运行，把线程资源安全共享的任务交给应用程序代码。 EJB容器允许无状态组件并发访问，但如果并发访问一个有状态Session Bean,就会抛出一个异常。

旧式的Web应用程序是围绕细粒度的同步请求编写的，因此这种行为可能还OK。 但是对现代的程序而言，由于大量使用了很多细粒度的异步（AJAX）请求，并发是实际存在的，并且必须被程序模型支持。 Seam在其上下文模型中加入了并发管理层。

Seam Session 和应用上下文是多线程的。Seam允许在一个上下文中并发请求，并发处理。事件（Event）和页面（Page）上下文自然是单线程的。 业务流程（business process）上下文严格而言是多线程的，但实际情况中并发很少见，因此大多数情况不会出现并发。 最后，Seam为Conversation Context提供了 每对话每进程单线程 模型，这是通过把同一个长时间运行的对话上下文中的并发请求序列化实现的。

因为Session上下文是多线程的，并且经常包含不稳定的状态，所以Session范围内的组件总是被Seam保护以防止并发操作。 Seam默认把针对Session范围的Session Bean和JavaBean的请求序列化（并且检测、解决任何发生的死锁）。 对Application Scoped的组件来说，这却不是默认行为，因为Application Scoped的组件通常不会包含的不稳定状态，并且在全局级别进行同步代价 极其 高昂。但是，你可以强制对任何Session Bean或JavaBean组件采用序列化的线程模型，要做的就是加上 @Synchronized 注解。

并发模型意味着AJAX客户端可以安全的使用不稳定的Session和会话状态，并且不需要开发者做任何特别的工作。

无状态Session Bean组件无法在多次调用之间保持状态。因此，它们通常在不同的Seam上下文中，操作其他组件的状态。他们可以作为JSF的action listener，但是不能为JSF组件的显示提供属性。

因为每次请求都产生一个新的实例，无状态session bean可以并发访问。把其实例和请求相关联是EJB3容器的责任（通常这些实例会从一个可重用的池中分配，所以你可能会发现某些实例变量还保存着上次使用的痕迹。）

无状态Session Bean总是生活在无状态上下文中。

无状态Session Bean是Seam组件中最没趣的了。

Seam无状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

有状态Session Bean不仅可以在bean的多次调用之间保持状态，而且在多次请求之间也可以保持状态。 不由数据库保存的状态通常应该由有状态Session Bean保持。这是Seam和其他web框架之间的一个显著的不同点。 其他框架把当前会话的信息直接保存在 HttpSession 中，而在Seam中你应该把它们保存在有状态Session Bean的实例中，该实例被绑定到会话上下文。这可以让Seam来替你管理状态的生命周期，并且保证在多个不同的并发会话中没有状态冲突。

有状态Session Bean经常被作为JSF action listener使用，也可以作为JSF显示或者form提交的backing bean(支持bean ,或称后台bean)，提供属性供组件访问。

默认情况下，有状态Session Bean会被绑定到Conversation Context。它们绝不会绑定到page或stateless context。

对Session范围的有状态Session Bean的并发请求，会被Seam按顺序串行处理。

Seam有状态Session Bean组件可以使用 Component.getInstance() 或者 @In(create=true) 实例化。它们不能直接使用JNDI或者 new 操作实例化。

实体Bean可以被绑定到上下文变量，起到Seam组件的作用。因为Entity除了上下文标识之外，还有持久标识，Entity实体通常明确的由Java Code绑定，而非由Seam隐性初始化。

Entity Bean实体不支持双向注入或者上下文划分。对Entity Bean的调用也不会触发验证。

Entity Bean通常不作为JSF的action listener使用，但经常作为JSF组件用于显示或者form提交的后台bean,提供属性功能。 特别是，当Entity作为后台Bean的时候，它会和一个无状态Session Bean扮演的action listener联用，来实现CRUD之类的功能。

默认情况下，Entity Bean被绑定到Conversation Context。他们永远不能被绑定到无状态Context。

注意，在集群环境中，把Entity Bean直接绑定到Conversation或者Session范围的Seam上下文变量，与在有状态Session Bean中保持一个对Entity Bean的引用相比，性能比较差。因此，并非所有的Seam应用程序都会把Entity Bean定义为Seam组件。

Seam实体Bean组件可以使用 Component.getInstance()、@In(create=true) 或者直接使用 new 操作来实例化。

JavaBeans可以像无状态或者有状态Session Bean那样使用。但是，它们不能提供Session Bean那么多的功能（声明式事务划分、声明式安全性、高效的集群状态复制、EJB 3.0持久化、超时方法等等）。

在后面有一章，我们会展示如何在没有EJB容器的情况下使用Seam和Hibernate。此时，组件是JavaBeans，而非Session Beans。 但是注意，在很多应用服务器中，对Conversation或Session 范围的Seam JavaBean组件集群操作，要比对有状态Session Bean组件集群慢。

默认，JavaBeans是绑定到Event Context的。

对Session范围的JavaBeans的并发请求总是会被Seam转化为串行执行。

Seam JavaBean组件可以使用 Component.getInstance()、@In(create=true) 或者直接使用 new 操作来实例化。

消息驱动Bean通常作为Seam组件。但是，消息驱动Bean与其他Seam组件的调用方式非常不同——它们并非通过Context变量调用，它们会监听发送到JMS Queue或者Topic的消息。

消息驱动Bean不能被绑定到Seam上下文。它们也不能访问它们的“调用者”的Session或者会话状态。但是，它们支持双向注入和一些其他的Seam功能。

消息驱动Bean不会被应用实例化，它是在接受到一条消息时由EJB容器来完成实例化的。

为了表演Seam的魔术（双向注入，上下文划分，校验等），它必须对组件调用进行拦截。 对JavaBean而言，Seam可以完全控制组件的初始化，不需要特别的配置。对于Entity Bean，也不需要拦截器，因为双向注入和上下文划分不起作用。 对Session Bean，我们必须为它注册EJB拦截器。我们可以使用注解，比如：

@Stateless
@Interceptors(SeamInterceptor.class)
public class LoginAction implements Login {
    ...
}

但是更好的办法是在 ejb-jar.xml 中定义拦截器。

<interceptors>
   <interceptor>
      <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
   </interceptor>
</interceptors>

<assembly-descriptor>
   <interceptor-binding>
      <ejb-name>*</ejb-name>
      <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
   </interceptor-binding>
</assembly-descriptor>

所有Seam组件都需要名字。我们可以通过 @Name 注解来命名组件：

@Name("loginAction")
@Stateless
public class LoginAction implements Login {
    ...
}

这个名字是 seam component name，和EJB规范定义的任何其他名字都没有关系。 但是，Seam组件名字就相当于JSF管理的Bean Name的名字，因此，可以理解为这两个概念是等同的。

@Name 不是定义组件名称的唯一方式，但是我们总得要在 某个地方 来指定名字。 否则，Seam 所有的注解部分就无法工作。

就如同在JSF中，Seam组件实例绑定成上下文变量时，其名字通常和组件名相同。 因此，例如我们可以通过 Contexts.getStatelessContext().get("loginAction") 来访问 LoginAction。 特别是，不管Seam自己何时初始化一个组件，它将这个新实例以组件的名字绑定成一个变量。 但是，又和JSF一样，应用程序也可以把组件绑定成其他的上下文变量，只需通过API编程调用。 例如，当前登录的用户（User）可以被绑定成为Session上下文中的 currentUser 变量，而同时，另一个用作某种管理功能的用户则被绑定成对话上下文的 user 变量。

对非常大型的应用程序，经常使用全限定名；内置的Seam组件就是这样。

@Name("com.jboss.myapp.loginAction")
@Stateless
@Interceptors(SeamInterceptor.class)
public class LoginAction implements Login {
    ...
}

我们可以在Java代码和JSF表达式语言中使用全限定的组件名称。

<h:commandButton type="submit" value="Login"
                 action="#{com.jboss.myapp.loginAction.login}"/>

这很啰嗦，Seam也提供了把全限定名简写的办法。在 components.xml 文件中加入类似这样的一行：

<factory name="loginAction" scope="STATELESS" value="#{com.jboss.myapp.loginAction}"/>

所有的Seam内置组件都有全限定名，但大多数都在Seam jar文件的 components.xml 中简写为简单的名字。

我们可以使用 @Scope 注解来覆盖默认的组件范围（上下文）。这可以让我们定义组件实例被Seam初始化后绑定到的具体上下文。

@Name("user")
@Entity
@Scope(SESSION)
public class User {
    ...
}

org.jboss.seam.ScopeType定义了可能范围的枚举.

有些Seam组件类可以在系统中具有多个角色。例如，我们经常有一个 User 类用作Session-Scoped组件，代表当前用户，同时它又在用户管理界面中被用作Conversation-Scoped组件。@Role 注解让我们可以定义组件在另一个范围中的额外角色名 —— 这可以让我们把相同的组件类绑定成不同的上下文变量。（任何Seam组件 实例 都可以被绑定到多个上下文变量，但@Role使得我们也可以在类的级别做到这一点，从而享受自动实例化的优点。）

@Name("user")
@Entity
@Scope(CONVERSATION)
@Role(name="currentUser", scope=SESSION)
public class User {
    ...
}

@Roles 注解可以让我们为组件指定任意多的附加角色。

@Name("user")
@Entity
@Scope(CONVERSATION)
@Roles({@Role(name="currentUser", scope=SESSION),
        @Role(name="tempUser", scope=EVENT)})
public class User {
    ...
}

和很多优秀的框架一样，Seam自产自用，主要实现了一系列的内置Seam拦截器（后文详述）和Seam组件。这让应用程序在运行时和内置的组件交互变得很容易，甚至可以用自己编写的实现来替换掉内置组件，由此来定制Seam的基本功能。内置组件在 org.jboss.seam.core 这个Seam 命名空间中定义，Java包名也是相同的。

像所有Seam组件一样，内置组件也可以被注射，但是它们也提供了便利的instance()静态方法：

FacesMessages.instance().add("Welcome back, #{user.name}!");