【IT168 技术文章】

        为何要转向 J2EE?

　　如果您不是十分渴望冒险投入一种新的开发环境，可以考虑以下这些 J2EE 好处：

　　选择，更多的选择：由于 J2EE 是一个定义良好的标准集，您在部署自己的代码时有许多 J2EE 实现可供选择。只要坚持使用标准 API 和避免厂商专用的扩展，应用程序无需编码变更就能在各种各样的 J2EE 实现上运行。

　　我们是在说选择吗?：J2EE 实现在从大型机到 Wintel、UNIX 和 Linux 的各种平台上可用。您可以编写应用程序一次，然后在各种不同的平台上部署它。

　　我们不能就安于现状吗?：J2EE 包括一个用于访问许多诸如 CICS、IMS、ERP 和 CRM 这样的遗留 EIS 系统的标准 API。它还包括 Web 服务支持，因此您可以集成 .NET 系统和支持行业 Web 服务标准的其他系统。J2EE 还包括标准消息 API 支持(Java Message Service，JMS)，以及一个用于访问关系数据库的 API(Java Database Connectivity，JDBC)。这样广泛的选择允许您集成各种现有的系统，而不会损失您对它们的投资。

　　机房不再烟雾缭绕：来自世界各地的专家通过 Java Community Process(JCP)开发 J2EE 规范。JCP 发布了初步的规范草案以供公众评论。即使您不主动参与，也总是会知道哪些未来的规范正在筹备之中。该规范还包括一个参考实现，您可以在决定实现它之前使用它来检查新技术。

　　J2EE 简介

　　J2EE、即 Java 2 Enterprise Edition，是一个由许多与使用 Java 语言开发分布式应用程序相关的组件组成的规范。您可以使用 J2EE 组件来编写基于 Web 的应用程序和传统的客户机-服务器应用程序，以及使用标准的 API 来连接到诸如关系数据库等遗留资源。如果您来自 ASP.NET 开发背景， Java Servlets和 JavaServer Pages(JSP)技术就是对您最有用的组件。

　　Java Servlets

　　Java Servlets 是作为诸如 IIS 或 Apache Web Server 等 Web 服务器的扩展来运行的 Java 类。Java Servlet 类似于 ISAPI 过滤器，即 ASP.NET HttpHandler 类，或类似于 cgi-bin 程序/脚本。Java Servlet 在客户端浏览器直接或间接地调用一个专门配置的 URL 时运行。servlet 能够访问 HTTP 请求中的所有信息，并且能够通过提供返回给客户端的内容来直接处理该请求。或者，servlet 能够将客户端浏览器重定向到另一个资源。大多数 J2EE Web 应用程序都主要把 servlet 用作 HTML 表单的目标以处理用户输入，然后作相应的处理。响应页面的生成通常委托给 JSP 页面。

　　JavaServer Pages 技术

　　JSP 页面类似于 ASP.NET 页面。也就是说，它们也是包含脚本元素的 HTML 页面，这些脚本在用户请求该页面时在服务器上运行。ASP.NET 页面和 JSP 页面之间的一个关键区别在于，ASP.NET 页面使用某种 .NET 语言(比如 C# 和 VB.NET)作为脚本语言，而 JSP 页面使用 Java 语言。典型的 JSP 页面包含 Java 代码片断和 JSP 规范中定义的一些特殊的类 HTML 标签，它们与标准 HTML 交织在一起以提供静态和动态内容的组合。Java Servlet 和 JSP 页面之间的区别在概念上类似于 ASP.NET HttpHandler 类和 ASP.NET 页面之间的区别。在两种情况下，前者都是可用于直接或间接地向其他资源发送 HTML 的一段代码，后者都是一个可以包含嵌入代码的 HTML 文档。

　　Web 服务器和应用服务器

　　如果熟悉 ASP.NET 页面，您应该知道运行这些页面的 ASP.NET 运行库――它配合 IIS 工作。您还会向 Web 应用程序添加自己的 HttpHandler 类以及托管的和非托管的组件，ASP.NET 运行库也会调用这些组件。这使得在 IIS 上部署 Web 应用程序很容易。但是它把您限制在 Windows 平台上，即唯一能够运行 IIS 的平台。J2EE 使用一种不同的方法，因为它的设计目标就是运行在各种不同的操作系统上(包括 Windows)。与尝试将运行 Java Servlet 和 JSP 页面的代码直接嵌入 Web 服务器不同，它使用一个称为 应用服务器的单独服务器组件来运行它们。大多数应用服务器(比如 IBM WebSphere Application Server)还有一个单独的插入组件，用于桥接应用服务器和特定的 Web 服务器。例如，WebSphere Application Server 附带了针对 IIS 和 Apache Web server 的单独插件。这样允许您在运行 J2EE 组件时使用自己选择的 Web 服务器。

　　应用服务器作为单独的可插入服务器组件这种角色带来了多个优点：

　　Web 服务器选择：您不会被限定使用某个 Web 服务器来提供 HTML 页面服务。您可以继续使用自己最喜欢的 Web 服务器来用于此目的，并且使用任何应用服务器来处理 Java Servlet 和 JSP 页面。这种能力在您将 ASP.NET 应用程序移植到 J2EE 时特别有用。您可以继续运行 IIS 和 ASP.NET 运行库，并且分阶段地移植应用程序。您不需要一下子改写整个应用程序。

　　平台选择：你可以编写 J2EE 应用程序一次，然后在能够运行应用服务器的各种不同操作系统上部署它——包括 Windows、AIX 和 Linxu。您不会被限定于某个能够运行特定 Web 服务器的平台。

　　应用服务器厂商选择：由于行业标准规范定义了 Java Servlets 和 JavaServer Pages 技术，您可以编写 J2EE 应用程序一次，然后在多种应用服务器环境中部署它，比如 WebSphere Express 或 Apache Tomcat，Apache Tomcat 是一个流行的开放源代码应用服务器。J2EE 还定义了必须如何打包 Web 应用程序，因此您可以将自己开发的应用程序引入某个 J2EE 环境，无需更改代码或重新编译应用程序，就能将它重新部署到另一个应用服务器中。将应用程序部署到多个平台也是如此。

　　应用服务器如何运行 servlet 和 JSP 代码

　　正如前面提到过的，J2EE 规范强制一种部署 Java Servlet 和其他 J2EE 组件的标准格式。一个称为 部署描述符的 XML 文档就是这种标准格式的一部分。部署描述符包含从每个 servlet 到用于调用特定 servlet 的 URL 的映射。应用服务器使用部署描述符中的信息来决定应该针对给定的请求调用哪个 servlet。

　　应用服务器调用 JSP 页面的方式类似于 ASP.NET 运行库调用 ASP.NET 页面的方式。 J2EE 应用服务器将每个 JSP 页面转换为一个单独的特殊 servlet，它在该页面被请求时编译和运行。这个特殊的 servlet 保持加载在内存中，直至 JSP 文件改变。这样最大限度地降低了必须为每个 JSP 页面创建和编译一个类所导致的性能影响。

　　模型-视图-控制器(MVC)体系结构

　　J2EE 是在考虑到一个特定的应用程序结构的情况下开发的，这个结构称为 模型-视图-控制器(Model-View-Controller，MVC)。MVC 定义了三个应用程序层之间的清楚分离：

　　模型：应用程序的数据和业务规则集——通常称为应用程序的业务逻辑。

　　视图：应用程序的用户界面。

　　控制器：定义了应用程序如何对用户输入或模型层的变化作出反应——通常称为应用逻辑。

　　MVC 体系结构的优点

　　J2EE 中没有任何东西强迫您使用 MVC 体系结构来组织应用程序，但是存在这样做的许多很好理由。通过定义三个层之间的清楚分离，MVC 允许构成每个层的组件之间的松散耦合。这样使得组件更加可复用和更灵活。例如，假设您的需求之一是支持某个 Web 应用程序中相同数据的不同类型的视图，因为不同的部门需要数据库中相同数据的不同子集。您需要开发特定于每个必需子集的新的视图组件。如果视图逻辑和数据库访问代码是紧密耦合的——ASP.NET 页面就是将数据库访问代码和 HTML 交织在一起，那么每个视图都要包含数据库访问代码。维护重复的代码不仅需要大量的工作，而且还可能导致出错。MVC 体系结构在这种场景中使用数据库代码作为该模型的一部分，而不同的视图组件可以复用它。

　　J2EE 组件和 MVC

　　图 1 显示了我们到目前为止所讨论的 J2EE 组件如何映射到一个 MVC 体系结构。注意模型和视图之间不存在任何联系。控制器的功能是充当两者之间的中转站。

　　图 1. MVC 与 J2EE Web 应用程序

　　在典型场景中，用户提交一个其目标是一个 servlet 的 HTML。servlet 分析输入，并使用模型中的类来调用业务逻辑以满足该请求。然后 servlet 将结果传递给一个 JSP 页面，以便向用户显示那些结果。

　　JavaServer Faces

　　您或许使用过 Web Forms 来开发 ASP.NET 应用程序的用户界面和 UI 控制逻辑。 JavaServer Faces(JSF)规范提供了 J2EE 编程世界中的等价功能。像 Web Forms 一样，JSF 提供运行库组件，这些组件允许工具厂商为基于 Web 的 UI 开发提供拖放功能。它还允许厂商开发可供他们的开发工具使用的自定义组件。

　　要看到 JSF 的实际应用，可考察一下 WebSphere Studio 5.11 版中的系列工具(请参阅 参考资料)。WebSphere Studio 还有一个名为 Page Designer 的完全集成的工具，可以使用它通过拖放操作来可视化地开发 HTML 页面和 JSP 页面。Page Designer 已实现了 JavaServer Faces 规范，您在使用它时应该会看到一些熟悉的组件，比如 HTML 表单、DataGrids 和 DataList。您还会看到熟悉的“代码分离(code behind)文件(使用 Java 语言)，它们包含特定页面的 UI 事件处理代码。

　　JSF 环境的一个杰出特性在于，它允许您将页面分组为符合逻辑的树形结构。例如，如果有一组包含多个表单的页面，那么 JSF 树形结构就很理想——特别是在用户可能基于先前的输入或基于某些用户特征，通过一条不同的路径经历那些页面的情况下。该结构为树中的每个页面指定一个合理的名称。您在自己的事件处理代码中使用这些名称来导航不同的分支，具体取决于特定的运行时条件。

　　其他 J2EE 技术

　　Java Servlets 和 JSP 技术为您提供用 Java 语言开发平台无关的 Web 应用程序所需要的工具。其他一些 J2EE 规范和组件为您带来更高级的功能：

　　Enterprise JavaBeans(EJB)技术：企业组件(或者说 bean)存在三种形式：

　　会话 bean：类似于 .NET 中的 COM+ 服务的特殊 Java 类。像 COM+ 服务一样，会话 bean 在容器中运行，容器提供诸如声明事务管理、基于角色的安全、分布式环境中的无缝访问以及根据需要激活等服务。会话 bean 又存在两种形式：

　　无状态的：方法调用之间没有维护状态，因此您必须提供通过参数来调用某个方法时所需要的全部信息。无状态会话 bean 的优点在于，容器可以使用任何实例来服务于任何客户机调用。

　　有状态的：方法调用之间的状态得到保持，以便客户机总是与特定的实例相关联。有状态的会话 bean 的优点在于，客户机可以使用对话模式来与有状态的会话 bean 交互。当重新创建中间状态信息的成本很昂贵时，这是特别有用的。

　　实体 bean：可看作是 ADO.NET DataSets 的更高级实现的特殊 Java 类。虽然概念上类似于 DataSets，但是实体 bean 的实现更像是 COM+ 服务。像 DataSets 一样，它们是存储在关系数据库或其他持久存储中的持久数据的对象表示，并且可以封装数据模型中的表之间的关系。像 COM+ 服务一样，它们在容器中运行，容器提供诸如声明事务管理、基于角色的安全、分布式环境中的无缝访问等服务。实体 bean 是共享对象，因此容器还要处理并发控制，并确保底层的持久数据保持其 ACID(Atomicity、Consistency、Isolation 和 Durability——原子性、一致性、隔离性和持久性)属性。(与会话 bean 不同，实体 bean 是共享对象，因此多个客户机可以并发地访问单个实例。)简而言之，实体 bean 防止您直接访问底层的持久存储。无需作出任何应用程序更改，就可以将它们部署到各种不同的持久存储中。(也就是说，无需改动任何代码，就可以在部署时将实体 bean 映射到它的持久存储。)

　　消息驱动的 bean：充当 JMS 相容的消息中间件的监听器的特殊 Java 类。JMS 是用于访问消息队列的标准 Java API。可以将消息驱动的 bean 配置为指向特定的消息队列;容器会在消息到达该队列中时激活它们。消息驱动的 bean 给应用程序提供了在消息到达时调用的应用逻辑。每种 J2EE 1.3 相容的应用服务器都必须提供一个 JMS 实现，不过您也可以使用诸如 WebSphere MQ(以前名为 MQSeries)这样的流行消息中间件。

　　Java 连接器体系结构(Java Connector Architecture，JCA)：用于访问许多诸如 CICS、IMS、ERP 和 CRM 这样的遗留 EIS 系统的标准 API。JCA 把您解放出来，从此不必再学习针对每种 EIS 系统的单独 API。