从体系结构的角度，会话 bean 可以用作视图、控制器或甚至模型本身。通常，它们还实现虚包(Facade)模式或业务委派(Business Delegate)模式。servlet(或 JSP 页面)、帮助 servlet 的 JavaBean(或 JSP 页面)、另一个企业 bean 可以访问会话 bean，也可以直接通过 applet、Swing 应用程序或其它 Java 应用程序访问会话 bean。

　　虽然到目前为止会话 bean 是最轻量级的 EJB 类型，但使用 EJB 容器和 EJB 体系结构是有代价的。EJB 容器需要占用服务器大量的处理能力和内存。不象 Java servlet 所采用的轻量级线程机制，EJB 组件需要创建和管理多个对象实例和相关资源(请参阅图 2)。然而，较高的开销所换来的好处是，在不牺牲很多响应时间和整体可伸缩性的情形下，EJB 组件向企业资源、事务和安全性检查提供了有效的管理。因为无状态会话 bean 不一定需要维护任何客户机状态，所以可以有效地合用无状态会话 bean，使用它们来完成任何客户机的请求。

　　图 2. 企业 bean 管理

　　无论您需要管理 EJB 容器、设置服务器群集、为企业 bean 声明配置设置还是需要利用容器众多服务(包括安全性、事务管理和资源管理等)中的某项服务，EJB 体系结构和 API 都能使开发和部署健壮且功能齐全的 J2EE 应用程序变得出奇的简单。部署描述符定义了容器和 bean 配置，EJB API 使用接口、bean 生命周期回调方法和工厂模式清晰地分隔开容器和企业 bean，同时仍使 bean 开发人员能方便地访问容器服务。

　　选择正确的技术

　　在某些情况下，确定使用 servlet(或 JSP 技术)、无状态会话 bean 还是同时使用这两者是一件非常简单的事情，而在另外一些情况下，这种选择却需要不少技巧。通常的配置是使用 servlet 层来处理与 HTTP 客户机的交互，然后将业务处理交给 EJB 层(主要由无状态会话 bean 组成，偶尔也有实体 bean 组成)。在这一节，我们将研究几个典型的应用程序情况，并讨论解决这些情况的组件或非常好的组件。

　　当您研究这些情况时，请牢记就每种技术您所了解的内容。尤其要记住，servlet 体系结构的轻量级线程模型使 servlet 的可伸缩性特别有效，而无状态会话 bean 极好地平衡了健壮企业资源的访问、恰当的响应时间和整体可伸缩性，有时无状态会话 bean 能较好地适合比较重量级的应用程序。

　　应用程序客户机

　　标准的应用程序客户机是与另一系统或组件进行相互操作的用户，而不是与应用程序进行相互操作的用户。我们将研究三种典型的应用程序客户机情况，以及它们最可能的解决方案：

　　如果客户机是基于 Java 的，并且和服务器位于同一个防火墙之后，则最好的解决方案是使用 RMI，直接与应用程序服务器上的无状态会话 bean 通信。

　　如果正在使用非 Java 客户机，或者客户机没有位于服务器的防火墙之后，则您会希望使用 HTTP 协议来与 servlet 进行相互操作。(应该根据是否需要访问由 EJB 组件所提供的广泛的企业支持来决定是只使用 servlet 还是通过 servlet 访问会话 bean)。

　　第三种情形较少见，但确实会出现。一些应用程序服务器供应商采用接受本机 IIOP 调用这样的方式将其 EJB 容器公开，使 CORBA 客户机将 EJB 组件看作本机 CORBA 应用程序。这允许非 Java 客户机使用 IIOP 协议来与无状态会话 bean 进行通信。在这种设置中，客户机绕过了整个 Web 层，使用 IIOP 协议直接与业务层(无状态会话 EJB 组件)通信。

　　企业应用程序集成(EAI)

　　EAI 通常使用一个或多个事务将两个或多个企业应用程序集成到无缝值链中。由于 J2EE 对原有应用程序、消息传递系统、各种数据源和其它企业应用程序提供了广泛的支持，所以它常常被用来将各种应用程序“粘合”成相连的集成系统。

　　在 EAI 这种情形中，servlet 和 EJB 组件作用差不多，因为在集成环境中使用 servlet 已经受到了限制。在这种罕见的情形中：应用程序需要调用 J2EE 方法，而除 HTTP 之外没有其它机制可用，对于 EAI，servlet 是很有用的。否则，它只能带来额外的开销，以及造成体系结构不必要的复杂性。

　　不象 servlet，无状态会话 bean 很好地被设计用于 EAI。无状态会话 bean 是非常轻量级的(相对于有状态会话 bean)，可以方便地合用它们以确保较好的可伸缩性。在 EAI 中常常需要状态管理，但可以通过专门机制或通过 J2EE 事务来解决此问题。因此，从应用程序服务器中除去了状态管理的负担。

　　另一种可能性是调用 EJB 组件，就好象它是 CORBA(公共对象请求代理)组件。在被集成的一个或多个应用程序为 CORBA 组件的 EAI 情形中，这是特别有用的选项。

　　丰富的 GUI 客户机

　　当构建丰富的用户界面来访问 J2EE 服务器端的功能时，您有几种选择：applet、独立应用程序、Java Web Start 和本机 GUI。

　　applet 是作为 HTML 页面的一部分装入的，从而提供了丰富的动态用户界面，人们一直都期望可以从 Web 上看到这种用户界面。(在显示文本方面，HTML 表现较好，而在制作用户界面方面，它却不行)。applet 是一项功能强大的技术，因为它们与浏览器无关，而且提供了丰富的 GUI 界面，同时，由 applet 沙箱来防止在未经许可的情况下访问本地资源。对于更新客户机接口问题，applet 还提供了引人注目的解决方案：只需在服务器上安装最新的 applet 类和支持库，在每次访问 applet 时，客户机会自动下载新文件。这种灵活性的代价是，每次访问 applet 时，必须将 applet 类和所支持的库下载到客户机。

　　独立应用程序被直接安装在最终用户的机器上。这些应用程序与浏览器无关，它们被存储在本地，而不需要从远程站点下载。结果，启动时间和响应时间大大缩短。独立应用程序没有 applet 的安全限制，所以可以较方便地访问本地客户机机器以及任何可以访问的远程服务器。不利的一面是，独立应用程序极难维护和更新。每台机器在本地都有一个副本，所以不可能自动更新网络上所有的应用程序。

　　Java Web Start实际上是 applet 和独立应用程序的混合物，它是一项较新的技术，它有许多较突出的优点(关于更多这方面的信息。象 applet 一样，可以从 Web 浏览器调用 Java Web Start，它也可以与 servlet 交互。与 applet 不同的是，Java Web Start 应用程序将文件缓存在本地硬盘，只有当需要时才下载额外的文件。可以从本地资源安装或通过 Web 远程安装 Java Web Start 应用程序。此外，启动的 GUI 是功能齐全的 Swing 客户机。可以在不妨碍应用程序的情况下关闭浏览器。其结果是结合了 applet 和非 applet 两者的优点。然而，Java Web Start 并不是十全十美。它需要将所有资源都包含在本地 JAR 文件中(而不是松散的文件中);它不允许直接访问资源(资源是通过抽象的资源管理机制来访问的);它不支持本机应用程序的部署。

　　以下解决方案可应用于这三个丰富 GUI 组件类型中的任何一个：

　　如果客户机和服务器分别位于防火墙的两侧，则您会希望客户机通过 HTTP 与 servlet 通信。使用助手类，servlet 层可以进行简单的业务处理(解析 XML 文档、通过 JDBC 访问数据源、用 JavaMail 或 JMS 来处理简单的消息或者甚至用 JTS/JTA 协调简单的事务)。对于较复杂的需求或者需要较频繁地请求企业资源，业务处理应该用会话 bean。

　　如果客户机和服务器都位于同一防火墙之后，则纯粹使用 RMI 调用来直接与应用程序服务器通信，这样可以提高性能和方便编程。在这种情形，使用 servlet 只能带来额外的开销，以及造成体系结构不必要的复杂性。在使用 applet 或 Java Web Start 的情况下，带有 applet 或 Java Web Start 应用程序链接的 HTML 文档可能最初使用 servlet，但在后来，为了处理客户机请求，客户机将与一个或多个无状态会话 bean 建立直接的 RMI 连接。

　　最后，如果客户机使用 非 Java GUI(即本机 GUI)，并且客户机需要管理复杂的事务或一系列的事务，则您会希望考虑选择使用这种方法：调用 EJB 组件，就好象它是 CORBA 组件。

　　Web 应用程序

　　在标准的基于 Web 的应用程序(譬如 Web 浏览器)情形下，您会采用支持 HTTP 的客户机，它需要访问一个或多个后端业务服务。在这种情形下，不需要考虑客户机位于防火墙的哪一侧，因为必须要使用 servlet。显而易见，HTTP 的需求会利用 Web 层。实质上将根据对 EJB 容器服务的相对需求来决定是否使用 EJB 组件。

　　多种客户机类型

　　最后一种情形是需要多种客户机类型。也许外部客户需要使用基于 Web 浏览器的客户机，而内部员工需要使用标准的桌面、丰富的 GUI。在提供高性能和可靠性的需求与重用需求之间，如何平衡?

　　如果不需要管理复杂的事务，或者不需要访问多个企业资源，则可以简单地使用与一系列助手类进行相互操作的 servlet 层来进行业务处理。外部浏览器客户机将通过这个 Web 层与系统进行相互操作。然后，重用助手 bean 来直接为内部应用程序的请求提供服务，或者内部应用程序通过 servlet 层进行通信。虽然这样能解决问题，但它不是最干净、最有效或可伸缩性最好的解决方案。

　　较常用的解决方案是将业务逻辑放入无状态会话 bean 中，让外部应用程序通过 servlet 层与应用程序服务器通信，让内部应用程序直接与 bean 通信。这种做法使表示与业务逻辑分离得最彻底，使内部应用程序直接地、自由地访问业务逻辑，从而在达到同一目的的情况下，这种做法采用的抽象最少。

　　结束语

　　在 J2EE 探险者系列的第 1 部分中，我们研究了使用 Java servlet 和无状态会话 bean 来完成客户机的请求时，它们之间相对的长处和短处。这里所讨论的各种情形并没有涵盖所有情况，但这些情形代表了无状态通信环境中 servlet 和会话 EJB 最常用的一些情况。