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