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

选择合适的技术
与无状态的 J2EE 体系结构不同，J2EE 应用程序不提供典型的配置来充当指南或蓝图。管理状态时，合适的体系结构取决于下列因素：

客户机是基于 Web（HTTP）的吗？
对话状态需要包含到 GUI 中吗？
服务器将处于哪种负载条件下呢？
有状态组件需要能够在服务器崩溃后仍然有效吗？
该组件需要哪种事务上下文呢？
有状态数据有多重要？
尽管上述一些问题似乎明显地倾向于其中一种技术，但是许多有状态方案实际上既需要使用 servlet 又需要使用 EJB 组件。至关重要的决定就是确定是在 Web 层还是在业务层上管理状态，或者同时在两个层上管理状态。在下一节中，我们将研究一些可能的企业应用程序方案，及其最适宜的解决方案。

应用程序客户机
标准的应用程序客户机是与另一个系统或组件相互操作的客户机。我们将研究三种典型的应用程序客户机方案，并且讨论每个客户机最适合的有状态解决方案：

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

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

一些应用程序服务器供应商以一种诸如接受本机 IIOP 调用的方式公开 EJB 容器，从而允许 CORBA 客户机将 EJB 组件当成本机 CORBA 应用程序。这允许非 Java 客户机使用 IIOP 协议与无状态会话 bean 进行通信。在该设置中，客户机绕过了 Web 层，并使用 IIOP 协议直接与业务层（会话 bean）进行通信。这时，体系结构分析与位于防火墙后的基于 Java 的应用程序分析是相同的。请参考第一种方案，以理解业务层上的状态管理问题。

电子商务随需应变环境
正如我们上个月讨论的，无状态会话 bean 是为电子商务随需应变（e-business on demand）应用程序精心设计的。它们是非常轻量级的，可以轻松地汇聚为池，以确保卓越的可伸缩性。相反，有状态会话 bean 并不是为这类应用程序而精心设计的。电子商务随需应变应用程序中通常需要状态管理，但是最好由专用的机制或通过 J2EE 事务进行处理。另一种可能性是调用 EJB 组件，就好象它是 CORBA 组件一样。当一个或多个被集成的应用程序是 CORBA 组件时，该选项特别有用。