Java开发网 - J2EE 探险者：用于无状态网络的 J2EE 技术

Java开发网

您没有登录

» Java开发网 » 技术文章库

打印话题 寄给朋友 订阅主题

作者

J2EE 探险者：用于无状态网络的 J2EE 技术

palatum

CJSDN高级会员

发贴: 451
积分: 80

于 2003-05-11 14:13

J2EE 探险者：用于无状态网络的 J2EE 技术
servlet，无状态会话 bean，亦是两者都用？
级别：中级

Kyle Gabhart (kyle@gabhart.com)
高级顾问，LearningPatterns
2003 年 5 月

用 J2EE 开发企业应用程序时，它向人们提供了众多选项 — 使得为基础结构选择合适的解决方案不是一件简单的任务。J2EE 探险者是专门针对 Java 技术经理、架构设计师和开发人员的系列文章。该系列中的每一篇文章都会向您展示一种或几种 J2EE 技术，并经常对它们加以权衡，从而帮助您做出富有见识的决策。在本文，也就是该系列的第 1 部分中，LearningPatterns 的高级顾问 Kyle Gabhart 比较了两种用于无状态网络的 J2EE 技术：servlet 和 EJB 技术。
在最近几年里，Java 行业的发展呈指数级增长。作为一名企业应用程序开发人员、架构设计师或者技术经理，您可以从许多供应商、最佳实践、规范和组件类型中为您的 Java 技术实现进行选择。J2EE 探险者系列的目的是帮助您从这些选择中找到一条途径，对于任何一种给定的情形，协助您挑选合适的技术。

在本文，也就是第 1 部分中，我们将探讨无状态 J2EE 组件，并评估出最合适的组件来用于您的企业体系结构。说到无状态、请求处理组件，可供选择的 J2EE 技术主要有两种：servlet 或 Enterprise JavaBeans 技术 — 或更具体一点，无状态会话 bean。

一般而言，servlet 和 EJB 组件是设计用于作为企业体系结构的事务管理组件。每一种技术都有其长处。servlet 体系结构的长处在于它的整体效率和相对简单性。而 EJB 组件则更健壮，因此开发、维护和调试要更复杂。

我们首先简要讨论一下无状态（相对于有状态）网络的质量，然后从正反两方面详细探讨这两种无状态技术。在文章最后，我们泛泛地探讨一下 J2EE 企业编程中最常见的一些应用程序设置，以及对应我们所讨论的这两种选择的最佳技术解决方案。

EJB 入门
EJB 技术的初学者确实应该先阅读“EJB 入门”一文，这是一篇针对初学者的关于 Enterprise JavaBeans 技术的文章。
请注意，从本文的目的出发，JSP（Java ServerPages）技术被认为是特殊类型的 servlet。考虑到在执行每个 JSP 页面之前先将其转换成 servlet，因此这种说法不难理解。因为 servlet 固有的无状态性，所以我们只考虑无状态会话 bean 以及它们为处理无状态客户机请求所提供的特性。本系列的下一篇文章将对有状态会话 bean 与 servlet 和 HTTP 会话 API 进行比较。

无状态网络
可以将 Web 应用程序协议分为两大类：无状态和有状态。协议的状态是指下一次传输可以“记住”这次传输信息的能力。有状态协议能够根据客户机以前的请求创建上下文。无状态协议没有上下文；每个请求都是与服务器的独立连接。

HTTP 就是一个很好的无状态协议的示例，它建立在客户机-服务器请求和响应的基础之上。在 HTTP 中，不会为下一次请求维护这次请求中客户机-服务器间交互的信息。

当然，由于无法维护状态，因特网将只能成为漂亮的百科全书、电子黄页以及 Shockwave.com 上很酷的动画游戏。因此，出现了一些技巧在 HTTP 上模拟有状态会话。有状态信息可以存储在 HTML 表单域或用户机器的 cookie 中，也可以附到超级链接中。然后，应用程序开发人员负责管理、跟踪和维护客户机的状态以确保会话过程顺畅、安全以及让人着迷。

servlet 的适用情况
servlet 体系结构被设计成灵活的、与平台无关的组件模型，它在服务器上执行，并处理客户机的请求。Servlet 很灵活，因为它们是由服务器的部署描述符（它是特定于服务器的）和 Web 应用程序部署描述符（它是由 J2EE 规范定义的，与服务器无关，例如 web.xml）两者的组合唯一地配置的。Servlet 之所以与平台无关是因为它们可以运行在任何 OS 上（这得益于 JVM），可以在任何 J2EE Web 服务器中运行（这得益于 J2EE 标准）。最后，servlet 体系结构是一个组件模型，因为它使开发人员可以编写周全的、可实现特定接口的组件。然后在运行时将这些组件组装起来，以处理客户机请求。

虽然 servlet 通常处理 HTTP 请求，但 servlet 体系结构与协议无关。servlet 接口定义了与 servlet 通信所需的基本方法，而不用考虑网络协议。为了简单起见以及由于 HTTP servlet 是最常用的类型，因此我们将只讨论 HTTP servlet。事实上，如果从 HTTPServlet 扩展定制的 servlet 类，则无需担心解析 HTTP 请求流、抽取参数或其它任何典型的 HTTP 处理活动中所涉及到的细节, 就能够方便地使用和处理 HTTP 通信。

servlet 体系结构
人们通常将模型-视图-控制器（MVC）设计模式应用于需要某类人机界面的情形。该模式源自 Smalltalk 社区，在那里用它来构建灵活的且可重用的用户界面。Servlet 天生就适合于 MVC 设计方法。在这种体系结构中，模型是指正在被访问数据的结构和类型。模型组件通常包含业务逻辑，业务逻辑控制数据访问并为一个或多个视图服务。视图提供了用户界面，用户或应用程序组件可以通过用户界面来访问模型。可以用多个视图来提供模型的各个界面。最后，控制器组件协调整个通信。控制器处理客户机输入、操作模型以及决定将哪个视图发送给给定的客户机。

从体系结构角度来讲，servlet 可充当控制器和视图。通常，将 JSP 页面用作视图组件，将 JSP 页面或纯 servlet 用作控制器组件。Servlet 在处理如内容格式化和显示、基本请求处理、安全请求等等之类的用户交互工作时很有效。通常，servlet 会使用助手类（通常为 JavaBean 样式的类）来处理繁重的工作，或使用这些类与后端组件进行相互操作。这就允许 servlet 层专注于客户机交互，而不是业务处理。

Servlet 是非常轻量级的，因为只需要有限的资源来初始化以及维护 servlet 实例。servlet 的可伸缩性非常平滑和有效。在 servlet 体系结构下，给定的 servlet 实例通过为每个请求产生新的线程并在每个线程内执行 service() 方法来同时处理多个请求。图 1 显示了 servlet 实例的生命周期，展示了它的轻量级可伸缩性。

图 1. servlet 线程模型

无论是否需要管理 servlet 容器、设置服务器负载均衡、处理简单的 HTML 表单或甚至对 HTTP 数据流执行复杂的处理，servlet 体系结构和 API 都能使 Web 应用程序开发和部署变得非常容易。用 servlet 容器设置和管理 Web 服务器非常简单，只需要很少的配置。对于服务器部署，通常一个或两个 XML 文件就包含所有所需的配置设置。对 servlet 进行编程也很简单。servlet API 对以下过程中所涉及到的细节进行了抽象：截取客户机请求、将请求路由至相应的 servlet 实例、从线程池检索线程、调用正确的方法来处理请求（doGet()、doPost() 或其它任何从 service() 方法调用的方法）以及甚至为抽取和处理编码的 HTTP 数据提供方便的 API。

会话 bean 的适用情况
EJB 体系结构还被设计用来提供灵活的、与平台无关的、服务器端的组件模型。在这些特性和实现方面，EJB 规范是 Servlet 规范的翻版。通过使用用于部署阶段绑定的部署描述符，两种技术都具有灵活性；得益于 JVM 和 J2EE 规范，两种技术都与平台无关；两种技术都提供了服务器端组件模型，这两种模型使用接口和抽象类以减少开发时间和麻烦，并确保了最优的组件重用性。另外，无状态会话 bean 从 EJB 容器获得了一些好处，包括声明的安全性、声明的事务上下文、与其它企业 bean 的可配置关系，以及可以方便地通过资源管理器连接工厂与其它 J2EE API（譬如 JMS、JavaMail 和 JDBC）集成。

最初，与企业 bean 通信是通过人机接口进行的，最终是通过 bean 的 home 接口或本地接口进行。由于外部客户机不能使用本地接口，因此我们只探讨远程接口。通过使用 Java 远程方法调用（RMI）与远程接口进行通信。RMI 是特定于 Java 平台的网络协议，它使 Java 对象可以与远程 Java 对象进行交互，就好象该远程对象在本地一样。因此，只有 Java 组件（applet、servlet、AWT、Swing 和非 GUI Java 应用程序等）可直接用作 EJB 客户机。其它任何客户机类型（譬如手机、浏览器或非 Java 应用程序）都必须通过 Java 应用程序进行通信。

EJB 体系结构
从体系结构的角度，会话 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 最常用的一些情况。

下个月，我们将从正反两面权衡在 Web 层（使用 servlet 和 HTTPSessionAPI ）和业务层（使用有状态会话 bean）中管理状态。到那时，祝您“探路”愉快！

话题树型展开

人气	标题	作者	字数	发贴时间
8086	J2EE 探险者：用于无状态网络的 J2EE 技术	palatum	8461	2003-05-11 14:13
6261	Re:J2EE 探险者：用于无状态网络的 J2EE 技术（图2）	palatum	0	2003-05-11 14:15
7264	English Version	palatum	22538	2003-05-11 14:16

已读帖子

新的帖子

被删除的帖子