Seam上下文
Seam上下文是由框架创建和销毁的。应用程序不能通过显式的Java API调用来控制上下文划分。上下文通常是隐含的。然而，在某些情况下，上下文可以通过annotation（注解）划分。
基本的Seam上下文有:
Stateless context
Event （or request） context
Page context
Conversation context
Session context
Business process context
Application context
你可能在servlet及相关规范中已经见过其中一些上下文了，但其中有两个可能从未见过：conversation context（业务对话上下文），和 business process context（业务流程上下文）。 在Web应用程序中，状态管理如此凌乱和容易出错的原因就是，内置的三个上下文（request, session 和application）从业务逻辑的角度来看不是很有意义。 例如，用户登录session的构建，对应用实际的工作流程来说就是相当随意的。 因此，大部分的Seam组件被限定在业务会话或者业务流程上下文中，因为这些上下文从应用的角度来说最有意义。
让我们按顺序来考察每个context（上下文）。
Stateless context（无状态上下文）
那些确实没有状态的组件（主要是无状态Session Bean）总是运行在无状态上下文中（实际上就是上下文无关）。 无状态组件没什么太大的意思，也有争议认为它们不十分面向对象。但不管怎么样，它们还是很重要，并且通常很有用。
Event context（事件上下文）
事件上下文是“最窄”的有状态上下文，是Web Request 上下文的泛化，用以包含其他种类的事件。 然而，与JSF请求的生命周期相关联的事件上下文是事件上下文最重要的实例，并且也是你最常打交道的。 与事件上下文相关联的组件在请求结束时被销毁，但是它们的状态至少在请求的生命周期中是存在并且是定义良好的。
当你通过RMI或者Seam Remoting调用Seam组件的时候，一个事件上下文将为这个调用而被创建和销毁。
Page context（页面上下文）
页面上下文允许你将状态与一个渲染页面的实例相关联。 你可以在Event Listener中初始化状态，或者在实际渲染页面的时候初始化状态，任何源于该页面的事件都可以访问到这些状态。 这在支持像可点击列表这种的功能时特别有用，列表的内容通过服务器端的数据变化产生。 实际上状态被序列化到了客户端，因此在多窗口操作或者回退按钮的时候，这种结构是非常健壮的。
Conversation context（业务会话上下文）
业务会话上下文是Seam中最核心的概念。conversation（业务会话）是从用户的视角看待的一个工作单元。 它可能跨越与用户交互的多个Servlet、多个请求，和多个数据库事务。但是对用户来说，一个业务会话解决一个单一的问题。 例如说：“预订酒店”，“批准合同”，“创建订单”都是业务会话。 你可以将业务会话理解成对一个“use case（用例）”或“user story（用户故事）”的实现，当然特定的业务关联并非与此类例子完全一致。
业务会话保存关于“在此窗口中，用户正在干什么”的状态。在任何时间，一个用户可能同时位于多个业务会话活动中，一般是在几个不同窗口中。 业务会话上下文让我们可以确保不同业务会话的状态不会互相干扰，不会导致Bug。
你可能要花上一点时间才能习惯以这一业务会话的观点来思考你的应用程序。 但一旦你习惯于它，你会喜欢上这个术语，并且再不会不用业务会话来思考了！
一些业务会话仅存在在一次请求中。跨域多个请求的业务会话必须通过Seam提供的annotation注解来划分。
一些业务会话同时也是tasks（任务）。任务是一种业务会话，它特指一个长时间运行的业务流程，当正确完成后，可能会触发一个业务流程状态的转换。Seam为任务划分提供了专门的注解。
业务对话可以是nested（嵌套）的，一个业务对话嵌套“在”一个更大的业务对话中。这是一项高级特性。
通常，业务对话状态实际上由Seam保存在Servlet Session 中，跨越请求。Seam实现了可配置的 conversation timeout，可以自动销毁不活动的业务会话，这就可以确保，如果用户取消对话，用户的登录Session中保存的状态不会无限增长。
对于在一个长时间运行的业务会话中所产生的并发请求，Seam按顺序执行。
除此之外，Seam也可以配置成把对话状态保存在客户端浏览器中。
Session context（Session上下文）
Session上下文保存与用户登录session相关联的状态。虽然当需要在多个业务会话中交换状态的时候这很有用，但我们一般不建议使用Session 上下文保存组件，除非是保存有关登录用户的全局信息。
在JSR-168 Portal环境下，Session上下文代表Portlet上下文。
Business process context （业务流程上下文）
业务流程上下文保存了长时间运行的业务流程相关的状态。这种状态由BPM引擎（jBPM）管理和持久化。 业务流程跨越多个用户的交互，因此状态在多个用户之间通过良好定义的方式共享。 当前的任务决定当前的业务流程实例，业务流程的生命周期通过外置的 process definition language（流程定义语言） 来定义，因此没有特别的annotation注解用于划分业务流程。
Application context（应用上下文）
Application上下文就是Servlet规范中的Servlet上下文。应用程序上下文在保存静态信息方面有用，例如配置数据，引用数据或者元模型。 例如，Seam把自己的配置和元模型保存在应用程序上下文中。
Context variables（上下文变量）
上下文定义了命名空间，一组 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）把组件实例返回上下文。
Context搜索优先级
有时候如上面的例子所示，组件实例是从某个特定的已知范围内获取的。 其他的时候则是通过 priority order(优先级顺序) 在所有有状态范围内搜寻。这个顺序是这样的：
Event context
Page context
Conversation context
Session context
Business process context
Application context
你可以通过调用 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和会话状态，并且不需要开发者做任何特别的工作。
基本的Seam上下文有:
Stateless context
Event （or request） context
Page context
Conversation context
Session context
Business process context
Application context
你可能在servlet及相关规范中已经见过其中一些上下文了，但其中有两个可能从未见过：conversation context（业务对话上下文），和 business process context（业务流程上下文）。 在Web应用程序中，状态管理如此凌乱和容易出错的原因就是，内置的三个上下文（request, session 和application）从业务逻辑的角度来看不是很有意义。 例如，用户登录session的构建，对应用实际的工作流程来说就是相当随意的。 因此，大部分的Seam组件被限定在业务会话或者业务流程上下文中，因为这些上下文从应用的角度来说最有意义。
让我们按顺序来考察每个context（上下文）。
Stateless context（无状态上下文）
那些确实没有状态的组件（主要是无状态Session Bean）总是运行在无状态上下文中（实际上就是上下文无关）。 无状态组件没什么太大的意思，也有争议认为它们不十分面向对象。但不管怎么样，它们还是很重要，并且通常很有用。
Event context（事件上下文）
事件上下文是“最窄”的有状态上下文，是Web Request 上下文的泛化，用以包含其他种类的事件。 然而，与JSF请求的生命周期相关联的事件上下文是事件上下文最重要的实例，并且也是你最常打交道的。 与事件上下文相关联的组件在请求结束时被销毁，但是它们的状态至少在请求的生命周期中是存在并且是定义良好的。
当你通过RMI或者Seam Remoting调用Seam组件的时候，一个事件上下文将为这个调用而被创建和销毁。
Page context（页面上下文）
页面上下文允许你将状态与一个渲染页面的实例相关联。 你可以在Event Listener中初始化状态，或者在实际渲染页面的时候初始化状态，任何源于该页面的事件都可以访问到这些状态。 这在支持像可点击列表这种的功能时特别有用，列表的内容通过服务器端的数据变化产生。 实际上状态被序列化到了客户端，因此在多窗口操作或者回退按钮的时候，这种结构是非常健壮的。
Conversation context（业务会话上下文）
业务会话上下文是Seam中最核心的概念。conversation（业务会话）是从用户的视角看待的一个工作单元。 它可能跨越与用户交互的多个Servlet、多个请求，和多个数据库事务。但是对用户来说，一个业务会话解决一个单一的问题。 例如说：“预订酒店”，“批准合同”，“创建订单”都是业务会话。 你可以将业务会话理解成对一个“use case（用例）”或“user story（用户故事）”的实现，当然特定的业务关联并非与此类例子完全一致。
业务会话保存关于“在此窗口中，用户正在干什么”的状态。在任何时间，一个用户可能同时位于多个业务会话活动中，一般是在几个不同窗口中。 业务会话上下文让我们可以确保不同业务会话的状态不会互相干扰，不会导致Bug。
你可能要花上一点时间才能习惯以这一业务会话的观点来思考你的应用程序。 但一旦你习惯于它，你会喜欢上这个术语，并且再不会不用业务会话来思考了！
一些业务会话仅存在在一次请求中。跨域多个请求的业务会话必须通过Seam提供的annotation注解来划分。
一些业务会话同时也是tasks（任务）。任务是一种业务会话，它特指一个长时间运行的业务流程，当正确完成后，可能会触发一个业务流程状态的转换。Seam为任务划分提供了专门的注解。
业务对话可以是nested（嵌套）的，一个业务对话嵌套“在”一个更大的业务对话中。这是一项高级特性。
通常，业务对话状态实际上由Seam保存在Servlet Session 中，跨越请求。Seam实现了可配置的 conversation timeout，可以自动销毁不活动的业务会话，这就可以确保，如果用户取消对话，用户的登录Session中保存的状态不会无限增长。
对于在一个长时间运行的业务会话中所产生的并发请求，Seam按顺序执行。
除此之外，Seam也可以配置成把对话状态保存在客户端浏览器中。
Session context（Session上下文）
Session上下文保存与用户登录session相关联的状态。虽然当需要在多个业务会话中交换状态的时候这很有用，但我们一般不建议使用Session 上下文保存组件，除非是保存有关登录用户的全局信息。
在JSR-168 Portal环境下，Session上下文代表Portlet上下文。
Business process context （业务流程上下文）
业务流程上下文保存了长时间运行的业务流程相关的状态。这种状态由BPM引擎（jBPM）管理和持久化。 业务流程跨越多个用户的交互，因此状态在多个用户之间通过良好定义的方式共享。 当前的任务决定当前的业务流程实例，业务流程的生命周期通过外置的 process definition language（流程定义语言） 来定义，因此没有特别的annotation注解用于划分业务流程。
Application context（应用上下文）
Application上下文就是Servlet规范中的Servlet上下文。应用程序上下文在保存静态信息方面有用，例如配置数据，引用数据或者元模型。 例如，Seam把自己的配置和元模型保存在应用程序上下文中。
Context variables（上下文变量）
上下文定义了命名空间，一组 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）把组件实例返回上下文。
Context搜索优先级
有时候如上面的例子所示，组件实例是从某个特定的已知范围内获取的。 其他的时候则是通过 priority order(优先级顺序) 在所有有状态范围内搜寻。这个顺序是这样的：
Event context
Page context
Conversation context
Session context
Business process context
Application context
你可以通过调用 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和会话状态，并且不需要开发者做任何特别的工作。