有状态网络的J2EE技术

　　Web 应用程序协议被分成两大类别：无状态（stateless）和有状态（stateful），协议的状态指的是它"记忆"从一个传输到下一个传输的信息的能力。因为有状态连通性是大多数企业应用程序的基本需求之一，并且因为 Web 应用程序依赖于 HTTP（内在的无状态协议），所以聪明的开发人员已经找到了许多技巧来在 HTTP 上模拟有状态连接。有状态信息可以存储在 HTML 表单字段中、附加到超链接或者存储在客户机端的 cookie 中。 

　　客户机和服务器之间的有状态交互可以在 Web 层或业务层上进行管理。要在 Web 层上管理状态，我们使用与 HTTPSession API 结合的 servlet.要在业务层上管理状态，我们使用有状态会话 EJB 组件。在接下来的章节里，我们将探究这两种开发选项。 

　　Web 层  

Servlet 体系结构并没有因为使用 HTTPSession API 而发生改变。就象在无状态网络中一样，servlet 代表客户机执行业务请求，并且充当控制器、视图，或者二者同时兼任。Servlet 还可以有效地处理用户交互，如内容格式化和显示、基本请求处理和安全性请求及更多。就象在无状态网络中一样，servlet 最好用于管理客户机交互，那么通常可使用助手类（如 JavaBeans）来应付繁重的处理或者与后端组件相互操作（interface）。 

　　因此，HTTPSession 接口允许 servlet 容器创建和管理客户机会话，并且使 servlet 能访问与会话相关的信息、将对象绑定到会话以及访问先前绑定的对象。到现在为止，一直都还不错。但是 servlet 容器如何跟踪通过无状态协议（如 HTTP）通信的客户机呢？为了实现这一点，为每个 HTTPSession 对象都提供一个唯一的标识，以确保每个客户机会话和与会话相关的数据可以被唯一标识。考虑到 HTTP 内在的无状态本质，在每次请求时，该会话标识必须被客户机传递给服务器，以便于 servlet 容器将客户机与正确的会话相关联。会话标识可以用三种方式中一种进行传递：作为 HTML 表单中的参数（通常是隐藏字段）；作为附加在查询字符串后的参数；或者作为 cookie 的属性。不管会话标识如何传递，servlet 容器都将拦截它，检查它，并找到与之关联的 HTTPSession 对象。 

　　Servlet 性能  

　　业务层  
  
从体系结构的观点看，有状态会话 bean 与其无状态的同类没有任何差别。两种类型的 bean 都可以很好地充当视图、控制器或模型；二者通常都可以实现虚包（Facade）模式或业务委派（Business Delegate）模式；二者都可以与多个客户机类型一起使用。有状态会话 bean 可以通过 servlet（或 JSP 文件）、帮助 servlet（或 JSP 文件）的 JavaBean 和另一个企业 bean 访问，或者直接通过 applet、Swing 应用程序或其它 Java 应用程序，或者甚至是使用 IIOP 协议的非 Java 客户机访问。 

　　管理有状态 bean  

　　相反，有状态会话 bean 与容器资源并不那样友好。有状态会话 bean 的池不能象无状态 EJB 组件的池那样用来容纳任何客户机请求。有状态 bean 只能处理来自一个客户机的请求，直到该客户机释放其对那个特殊 bean 实例的控制。有状态会话 bean 消耗了容器的大量时间和内存。为了保存客户机调用之间的 bean 状态，容器必须将 bean 实例保存在活动内存中，或者临时将状态写到持久性存储（如文件系统或数据库）中。将状态分配到持久性存储中就是所谓的钝化（passivation）。当以前钝化的企业 bean 被再次请求时，容器通过从池中检索 bean，并且利用钝化前 bean 的持久性状态对它进行初始化，来激活它。下图阐明了有状态会话 bean 的钝化和激活： 

　　决定将 bean 保存在内存中还是对它进行钝化，然后再激活它，这取决于各个供应商。尽管在释放容器资源方面钝化机制非常有帮助，但是在防止服务器崩溃以避免丢失有状态会话 bean 的活动状态方面却无能为力。尽管一些供应商提供了会话恢复功能以解决这个问题，但它不是标准的，因此依赖该功能会降低应用程序的可移植性。但是，别担心！EJB 规范确实定义了一个接口（javax.ejb.SessionSynchronization），它可以向企业 bean 警报事务的状态，包括由于服务器崩溃而失败的事务（假定不是拔了服务器的插头）。实现 SessionSynchronization 接口的企业 bean 必须定义三个已声明的方法特征符：afterBegin（）、beforeCompletion（） 和 afterCompletion（boolean）。这些方法使 bean 可以从容器接收三个额外的回调，以允许正确处理 bean 中的事务状态。 
EJB 组件性能  

　　选择合适的技术  
客户机是基于 Web（HTTP）的吗？  
服务器将处于哪种负载条件下呢？  
该组件需要哪种事务上下文呢？  
  

　　应用程序客户机  

　　如果客户机是基于 Java 的，并且与服务器处于相同的防火墙之后，那么您首先应该决定有状态交互模型是否是必需的。管理有状态会话 bean 是资源密集型的，因此您应该考虑更轻量级的备用方案。最佳解决方案就是使用 RMI 直接与应用程序服务器中的无状态会话 bean 对话。如果有状态解决方案是必需的，则请考虑使用带有简单事务层的无状态会话 bean，或者在业务层上创建瘦 servlet 层。任何一种解决方案花费部分成本即可提供有状态体验。最后，如果您的客户机必须与跨多个请求的业务过程的状态进行紧耦合，并且不能接受添加 Web 层，那么有状态会话 bean 是显而易见的选择。  |||

　　如果您正在使用非 Java 的客户机或者使用与服务器不在同一个防火墙之后的客户机，那么状态管理问题略有不同。在这种方案中，您首先应该确定状态管理的目标。如果目标是通过某种 GUI 为用户提供流畅的体验，那么您可以在 Web 层上管理状态。如果目标是将跨多个请求的复杂业务过程联系在一起，那么状态管理应该在业务层上进行。再次强调，您应当始终探索其它选项，如使用带有事务层的无状态会话 bean.  

　　电子商务随需应变环境  

　　"富"GUI 客户机  

　　如果您的客户机和服务器被防火墙分隔，您应该让客户机通过 HTTP 与 servlet 直接通信。该 servlet 层可以使用助手类应付简单的业务处理。如果您的应用程序有更复杂的需求，或者对企业资源有更高的请求频率，您应该使用会话 bean 来处理业务过程。这里再强调一次，您应当将有状态交互模型的必要性作为决策过程的一部分进行考虑。 

　　如果您的客户机和服务器位于同一个防火墙之后，直接的 RMI 调用可能是您的最佳选择。在这种情形下，servlet 只会带来额外的开销和不必要的体系结构复杂性。在 applet 或 Java Web Start 情形中，通过提供带有 applet 或 Java Web Start 应用程序链接的首个 HTML 文档，servlet 可以启动事务。然后，最好使客户机与一个或多个会话 bean 建立直接的 RMI 连接。该方案的设置与典型的应用程序客户机方案（与服务器不在同一个防火墙之后）的设置相同。 

　　如果您正在使用本机 GUI 客户机，并且需要管理复杂的事务或事务系列，那么您应该再次考虑调用 EJB 组件，就象它是 CORBA 组件一样。如果不能那样做，您可以始终让客户机通过 HTTP 与 servlet 通信，并且相应地管理会话。 

　　Web 应用程序  

　　有状态体验需要直接与用户界面联系吗？ 如果是，那么必须使用 servlet 和 HTTPSession API 管理状态。 

　　您的业务过程需要跨越来自客户机的多个调用吗？ 如果是，您有三种选项：  
使用无状态会话 bean，并且让持久数据高速缓存在服务器上。接着对高速缓存的引用可以存储在客户机的 HTTPSession 对象中。  

使用应用程序服务器，该服务器为有状态会话 bean 的状态恢复提供自动支持。 

　　SessionSycnhronization 接口允许无状态或有状态会话 bean 对事务故障做出响应。这将允许您回滚事务、持久化数据或执行您可能需要的任何其它清除功能。通常，服务器故障将不会阻碍容器调用由接口声明的回调方法。 

　　许多 Web 服务器都提供了故障保护 HTTPSession 实现。如果您的服务器可以这样做，那么您可以使用 JavaBean 作为业务委派。 

　　多客户机类型