评论

J2EE 状态评论
作者：Peter Zadrozny

J2EE 计算的趋势以及值得关注的关键技术

多年来，我亲眼见证了 Java 的“进化”- 由最初用于电视机顶盒的 Oak 语言进化为 Java（一种很有用的编程语言，最初适用于浏览器内部的客户端），最后进化为 Java 2 企业版（一个能够在多个服务器上运行的企业平台）。作为一个成熟的框架，J2EE 比单纯的 Java 语言更进一步提高了开发人员的生产效率。毫无疑问，Java 和 J2EE 经历了漫长的道路 - 从一个很不稳定、容易崩溃的 Java 虚拟机 (JVM) 一直演变为一个支持使命关键应用程序的强健的企业级基础架构和服务软件系列。

我们现在何处？又要走向何方？我们将重点介绍 J2EE 事务的当前状态，并首先简单了解一下 Java Community Process (JCP)。

Java Community Process 和开放源代码的背景知识

JCP 为开发人员社区提供了一个用于创建 Java 兼容技术 API 的过程机制。JCP 通过发布 Java 规范请求 (JSR) 启动新 API 的开发。从根本上来说，JCP 的工作产品包括 API 规范、参考实现 (RI) 和技术兼容性工具包 (TCK)。

多年来，JCP 一直饱受批评，而这些批评却对此过程的调整起到了帮助作用。尽管某些开发人员可能认为此过程的限制程度过高（某些开发人员可能觉得它有些专横），但我却认为 JCP 是一个很不错的过程，同任何其他民主过程一样，它虽然称不上完美，但确是最好的方法。只需回顾一下自 1998 年（JCP 诞生之年）以来所取得的成就，您便会认识到该过程的效率有多么高 - 不断增长的 Java API 数量本身就足以说明问题。

显而易见，谈到 JCP 就不得不说说开放源代码，许多开发人员认为它是一个更好的开发方法。开放源代码产生了（并不断发起）大量的项目（仅 SourceForge.net 上就至少超过 100,000 个），这些项目可以解决任何可能的问题。这些项目中所体现的创造力令人振奋。毫不夸张地说，开放源代码已成为近 30 多年来技术革命所不可分割的一部分。

在我看来，开放源代码的真正价值在于它的感染力 - 它是一个高效的机制，可迅速传播创新性的问题解决方法，而这些方法又可以与其他新的或现有的项目整合。我将它看作是我们行业的高级研究实验室。例如，几个开放源代码轻型容器（如 Pico Container、Hivemind 和 Spring）最先在 Java 中引入了控制反转机制 (IoC)，这些机制现在已经集成到了 EJB 3.0 中。

围绕开放源代码展开的争论主要是与业务模型相关。在此我们可以将开放源代码分为两类，即具有商业模型开放源代码和某些人称为“真正的”开放源代码。无论它们使用哪种许可证（另一个争论点），基于开放源代码的商业公司也是要盈利的，尽管采用的是非传统方式。

他们往往免费（或只收取最低费用）发布软件，而通过提供支持、指导或服务组合赢利。因此，他们不过是另一种供应商，在做购买决策时您应权宜处理。

对于“真正”的开放源代码产品，主要应考虑其用户群的规模和质量，并非所有项目都像 Struts 或 Linux 那样获得广泛成功。

值得关注的主要 J2EE 技术

接下来，我们将从以往比较薄弱的前端开始介绍 J2EE 系列：实际上，使用 Servlet 和 JavaServer Page (JSP) 一直都不是创建基于 Web 的用户界面的最简单方法。Struts 解决了某些 API 问题，但即使使用 Struts，开发人员也仍需要执行大量重复工作。开发人员需要一个更好的解决方案，还好现在以 JSR 127 (JavaServer Faces 1.0) 和 JSR 252 (JavaServer Faces 1.2) 的形式提供了这样的解决方案。JavaServer Faces (JSF) 1.2 将在 J2EE 1.5 (JSR 244) 发布（2006 年的第一个季度）时正式成为 J2EE 的一部分。

JavaServer Faces。JavaServer Faces 之所以比较重要有多方面原因。首先，它与标记语言无关，因此可以在任何客户端上运行。其次，尽管它将应用程序与表示分离，但却实现了两者之间的轻松连接。

“我将开放源代码看作是我们行业的高级研究实验室。”

一个基本的 JSF 应用程序由 JSF 组件、导航模型和被管理的 bean（也称作后端 bean）组成。此导航模型与 Struts 的导航模型非常类似，而被管理的 bean 提供应用程序的业务逻辑。JSF 组件由以下部分组成：组件和呈现器。

组件本身定义了行为或功能，例如，用户必须选择一个选项。呈现器用于定义呈现给最终用户的外观，例如，以列表框或菜单形式将选项呈现给用户。呈现器处理实际的标记语言。例如，行为只定义一次，而多个呈现器可以定义不同方法将同一组件呈现给不同客户端。可以按标记语言对呈现器进行分组，因此就有了用于组件的 HTML 呈现器工具包和 WML 呈现器工具包。尽管进行了高度的简化，但本描述还是说明了实际的责任分隔。

JSF 的魅力在于，由于我们有一个社区的人在编写组件，因此您有可能找到所需的功能。否则，您可以扩展一个具有相似功能的现有组件，或编写一个新组件，然后将它贡献给该社区。Oracle 已经创建了 100 多个组件，您可以免费下载。这些组件包括表格、流程图、颜色选择器和媒体播放器等。由 Sun 提供的参考实现包含一个 HTML 呈现器工具包。

Oracle 将很快提供一个非常强大的用于 DHTML 的呈现器工具包，即富客户端呈现器工具包，它将 JavaScript 用于部分页面呈现。DHTML 呈现器工具包的功能如此强大以至您不必对客户端界面使用 Swing 了。另一个呈现器可用于 Telnet 设备。理论上，更多供应商将会赶赶呈现器工具包的时髦，例如有一个可用于 Macromedia Flash 的呈现器工具包将是一件很不错的事情。

JSF 后续步骤 JSF 简介 获取 Oracle ADF Faces 组件预先试用版：一组非常丰富的 JSF 组件。 收藏 JSF 资源页面

EJB。此系列的下一层是 EJB 容器，该容器饱受批评，尤其是在实体 bean 方面更是如此。许多批评是有根据的。

就其核心而言，EJB 可被看作是位于 Java 之上的一组设计模式和反模式，它们可以简化开发人员的工作。可以将 EJB 看作是一个用于负责处理远程过程调用和事务语意以便开发人员可以集中精力编写实际业务逻辑的框架。

但开发人员却需要执行大量重复、烦琐的工作，如创建部署描述文件、主接口和数据传输对象等。由于 J2EE 对一些开发人员来说太复杂了，因此他们就创造了一组很有创造性的解决方案即轻型容器，如 Spring 和 Pico Container。

好消息是，下一个革命性举措 EJB 3.0 (JSR 220) 是一次进行简化的努力。其中易于使用的新增关键特性包括：

• 使用批注元数据，而不是更复杂的 XML
• 通过默认设置简化操作，使您不必完全指定所有元数据
• 更少的代码编写，提供更简单的开发
• 一个更简单的、基于控制反转（相关性注入等）的客户端模型

更重要的是，EJB 3.0 包含一个强大的、已修订的实体 bean 持久性模型。该模型

• 基于轻型 POJO（传统 Java 对象）
• 更安全、更强健，这是因为安全性和容器事务开销现在位于它所属的会话级别，而不再位于实体级别
• 因使用内置的回调机制而变得更强大、更灵活
• 因使用标准化的对象/关系映射模型而变得更具可移植性

并且，似乎仅这些改进还不足以满足需要，因此 EJB 3.0 还支持容器外测试。（正如您所看到的，EJB 3.0 是对当前版本的巨大改进。下载 EJB 3.0 的 Oracle 实现开发人员预览版，立即开始使用这些简化的新特性。）

EJB 后续步骤 下载 Oracle 应用服务器 EJB 3.0 预览版。Oracle EJB 3.0 容器允许您构建和测试 EJB 3.0 组件。 阅读为 EJB 3.0 做好准备 在容器外测试 EJB 3.0 实体：示例代码 收藏 EJB 3.0 资源页面

超越对象/关系映射。当应用程序需要访问多个不同的数据源时，仅有对象/关系映射远远不够的矛盾就凸现出来。

这就是 Oracle 提出数据服务概念的原因。其思想是无论您拥有哪种应用程序（门户、BPEL、J2EE、J2SE 或 Web 服务），以及使用哪种编程模型（EJB、WSDL、POJO），都可以轻松访问任何数据源（如关系数据库、XML、打包的应用程序或原有系统）中的信息。

为实现此目标，您需要一组不但为您提供对象/关系映射并提供对象/XML 映射和 WSDL 数据表示的数据服务。与各种数据服务关联的应是另一组为您提供基础架构功能的服务（以便您不必亲自构建它们），如：

• 用于在单个实例上实现高性能的缓存以及用于集群环境的分布式缓存
• 数据访问安全性允许您实施数据库安全策略，全面保护您的 J2EE 应用程序

您还应寻找一个允许您定义数据相关事件的服务，以便以编程方式确定一个在操作（如数据源中的删除操作）之前或之后发生的具体操作。

彻底集成数据服务（如这些服务）提供了很高的价值和灵活性 - 您可以移动信息而不必更改您认为是最好的编程模型。

Oracle 在 Oracle TopLink 中提供了与当前相同的数据服务。10 多年前作为强大映射引擎首次发布（由 Object People 发布）的 Oracle TopLink 已发展为包含前述的特性。尽管对象/关系映射功能开始在 EJB 3.0 中得到标准化，且 XML/对象映射在 JAXB 中得到标准化，但没有哪个 JSR 包含所有这些特性。请注意，JAXB 2.0 新增的许多功能都直接由 Oracle TopLink 提供 - 这不过是一个供应商如何利用最初作为专利技术的功能并将它提供给行业内的其他人以为 JSR 规范做出贡献的例子。

与对象/关系映射相关的资源 TopLink 的历史 “关于持久性和 POJO” Spring TopLink 预览版

一提到与 XML 相关的 JSR 就有很多东西要讲 - 与 XML 相关的 JSR 的数量很多，而且会越来越多。首先，Web 服务完全基于 XML。JSR 224 (JAX-RPC 2.0) 负责进行远程过程调用，该功能使用基于 SOAP、HTTP 和 WSDL 的 XML 协议。JAXR (JSR 93) 提供了 XML 注册表，从而能够基于 ebXML、UDDI 或其他提供程序构建、部署和发现 Web 服务。这些 JSR 由 JSR 181（Web 服务元数据）和 JSR 261（JAX-Web 服务寻址）提供补充。

此外，由于我们开始更大量使用 Java 元数据 API，因此 XML 功能变得更加重要。

我们从 JAXP 开始介绍 XML。JAXP 由 SAX 分析器、文档对象模型 (DOM) 和 XSLT 转换程序包组成。这些程序包当前根据 JSR 206 推出了它们的第三个版本。根据 JSR 173，有一个用于 XML 的流分析器（称作 StAX）。

前面提到了 JAXB，它的 2.0 版 (JSR 222) 包含缺少的对象/XML 等功能。

通常，构成 J2EE 的其他规范（如 JTA）非常稳定，因此我们对它们非常放心，这是非常好的一件事。

“公司使用软件对业务流程进行建模，而 AOP 主要用于横向分析问题，这基本上与业务流程相反。”

我必须提到面向方面的编程，即 AOP，这是因为它更为人们所知。尽管 AOP 是一项非常有意义的技术（已经与 J2EE 紧密联系在一起），但它尚未达到一流水平，尤其是在企业应用中。我认为造成这种局面的主要原因是公司使用软件对业务流程进行建模，而 AOP 主要用于横向分析问题，这基本上与业务流程相反。请别误会。AOP 是很重要，但我认为只有为我们提供基础架构和框架程序包的软件公司才能充分利用它。AOP 为他们提供了所有必要的工具，以便根据客户要求快速更改和改进功能。我认为，用“不要随便尝试这件事。请专家为您代劳吧”这句话来形容 AOP 最恰当不过。

管理和监视

尽管 Java 和 J2EE 正在成为开发界的主流，但 IT 操作人员仍不情愿每天都负责运行 J2EE 应用程序。部分原因是因为帮助对基于 Java/J2EE 应用程序的日常操作进行管理和监视的工具不足。另外就是缺乏操作这些应用程序的最佳实践。

当今企业环境的典型特征是对资源和职责的清楚划分 - 您拥有网络、大量计算机、各种客户端/服务器应用程序、一个或多个数据库，还可能拥有一个包含其他应用程序和资源的大型机。在这样的环境中，如果某个资源出现故障，操作人员可以轻松地识别问题并将其解决。

由于 Java/J2EE 应用程序通常与大量其他系统（例如，可能是在大型机上运行的数据库）进行交互，因此当出现问题时很难找出问题的根源。

例如，大多数可用工具无法提供完整信息，如使用 JSF 组件（调用 EJB 中嵌入的某些业务逻辑，而该 EJB 又调用数据库）与应用程序交互的最终用户的完整信息，也没有哪个工具能在分布式事务的整个生命周期中跟踪该事务。因此，问题诊断速度慢且负担重 - 操作人员不太愿意负责运行应用程序，原因是操作人员无法真正控制应用程序，并且也没有最佳实践和高效的管理工具，这是可以理解的。

实际上，我们已经看到，在很多情况下应用程序的开发人员和架构师最终还是要在生产中负责运行应用程序。显而易见，这种情况确实不令人满意，并可能给开发小组带来不良影响。

其他资源 “利用 JMX 进行监视、控制和扩展” “BPEL 动手操作简介” Web 服务技术中心

除了 JMX，我认为 J2EE 规范不应包含任何其他用于监视和管理 Java/J2EE 应用程序的功能。 但我还是深深认为 J2EE 实施的供应商应为他们的服务器提供完全集成的工具。 幸运的是，Oracle 以 Oracle 企业管理器的形式提供了一个集成的工具 — 一个已经用于监视和管理 Oracle 数据库的工具。 尽管 Oracle 企业管理器可能还算不上是监视 J2EE 应用程序的完美工具，但它的众多功能使它成为出色起点。 更为出色的是，Oracle 企业管理器现在拥有一个技术娴熟、训练有素的用户群（即 Oracle 数据库管理员，它们已经熟悉了它在生产环境下的使用）。

结论

总的说来，J2EE 一直在非常快速、非常高效地发展着。 作为一项技术，它已经超过了它早年所具有的功能，现在变得更成熟、更可靠。 更多的变化即将开始，这是很正常的 - 您不希望技术发展停滞不前，尤其是当企业使用技术推动其自身的业务革新时。

对于 J2EE 的未来，我期望元数据能够得到更广泛的使用。 开发人员到底为什么要对应用程序模块进行重新编程？难道仅仅是为了改变应用程序的用户界面的观感吗？ 元数据使用在类似示例中比较合适，但通过 J2EE 系列可以将它向各个方向扩展，我完全相信几年后我们的大多数代码将包含充分使用元数据的类。

相关链接 元框架的兴起

实际上，看到 JSR 175（元数据）对下一代 JSR 的影响将是一件有意义的事情。 例如，我们已经看到元数据在 EJB 3.0 中的正面影响，且全新的 JSR 269 是一个可插入的批注处理 API，旨在为我们提供编译时批注处理器的创建规则。

简单地说，J2EE 之所以成功是因为它提供了可以可靠满足企业开发人员需要的必要基础架构。 它将很快受到欢迎，同时 J2EE 还将变得非常成熟。 当您考虑它的成熟、特性和功能（以及 JCP 引导的不断发展时），便会清楚地认识到 J2EE 是一个无与伦比的工具。 J2EE 万岁！

[返回 J2EE 系列主页]