J2EE探索 有状态网络的J2EE技术 （4）

“富”GUI 客户机
有三种基本的“富”GUI（不是 HTML，也不是命令行）客户机类型：Java applet、独立应用程序和 Java Web Start。下列解决方案适用于这三种“富”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 应用程序
在标准的、基于 Web 的应用程序情形中，客户机位于防火墙的哪一侧并不重要；使用 servlet 是必需的。因为您将使用 HTTP 作为传输协议，所以将在 Web 层上工作。唯一实际的决定 ? 是否在幕后使用 EJB 组件 ? 将取决于对 EJB 容器服务的相关需求。首先，您将选择通用的组件类型（如 servlet 和会话 bean）。接下来，您将选择一些匹配应用程序的用户界面显示和业务请求处理需求的更特定类型（如 JSP 页面和有状态会话 bean）。就所关心的状态管理而言，Web 应用程序中存在着和其它客户机类型中类似的问题。一些标准问题（和答案）将有助于您为您的 Web 应用程序确定合适的状态管理解决方案：

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

您的业务过程需要跨越来自客户机的多个调用吗？ 如果是，您有三种选项：
使用有状态会话 bean 来提供有状态业务过程。

使用无状态会话 bean，并且让持久数据高速缓存在服务器上。接着对高速缓存的引用可以存储在客户机的 HTTPSession 对象中。

通过调用 bean 上的方法使 JavaBean 充当业务委派（请参阅参考资料），从而使 bean 批处理所有来自客户机的数据，并且仅在客户机准备提交业务过程时才联系无状态会话 EJB 组件。再次使用了 HTTPSession API 来持久化 JavaBean 实例。

您的有状态业务过程需要故障保护吗？ 如果是，您有三种选项：
使用应用程序服务器，该服务器为有状态会话 bean 的状态恢复提供自动支持。

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

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

多客户机类型
最后的情形需要客户机类型的组合，例如基于 Web 的浏览器和标准的“富”GUI 桌面。在这种情形下，有状态选项同无状态选项没有区别。请参考本系列的第一篇文章以获取详细信息。

结束语
在本部分（J2EE Pathfinder 系列的第二部分）中，我们探讨了使用 Java servlet 和有状态会话 bean 来执行客户机请求和提供有状态体验的相对优缺点。本文讨论的方案并未包含所有情形，但是它们代表了有状态通信环境中的 servlet 和会话 EJB 组件的一些最常见用法。

在下一部分中，我们将开始有关持久数据管理的两部分探讨，首先将比较实体 bean 和 JDBC。愿我们到时“探索”愉快！