【IT168 技术文章】用 J2EE 开发企业应用程序时，它向人们提供了众多选项 ― 使得为基础结构选择合适的解决方案不是一件简单的任务。J2EE探险者是专门针对 Java 技术经理、架构设计师和开发人员的系列文章。该系列中的每一篇文章都会向您展示一种或几种J2EE 技术，并经常对它们加以权衡，从而帮助您做出富有见识的决策。

　　在最近几年里，Java 行业的发展呈指数级增长。作为一名企业应用程序开发人员、架构设计师或者技术经理，您可以从许多供应商、非常好的实践、规范和组件类型中为您的 Java 技术实现进行选择。 J2EE 探险者系列的目的是帮助您从这些选择中找到一条途径，对于任何一种给定的情形，协助您挑选合适的技术。

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

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

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

　　请注意，从本文的目的出发，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 实例的生命周期，展示了它的轻量级可伸缩性。

　　无论是否需要管理 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 应用程序进行通信。