精通J2EE应用程序开发之交叉分析J2EE

　　在不久前的一段时间内，Java 开发人员在准备一个新的企业 Java 开发项目时，事先就知道将要使用的工具。当时，一切都很简单：J2EE 是新的，HTML 浏览器是公认的用户界面标准，而复杂性（至少从推测的角度而言）已成为过去的事情。而如今，事情变得如此复杂。

　　“开发人员面对的选择令人眼花缭乱。”

　　开发人员面对的选择令人眼花缭乱，从“轻型容器”（如 Spring、NanoContainer 或 HiveMind）到“web 框架”（如 WebWork、Tapestry（一个基于 JSF 的 UI，类似于 Oracle 的新应用程序开发框架 (Oracle ADF)）或 Velocity）。这些选择还增加了一系列新的 J2EE 规范，或者说是通过 JAXM、SAAJ、JAX-RPC 或 JAX 对“Web 服务”和相应的新技术术语“面向服务的体系结构”赋予了新的价值（更不用提“WS-*”规范、工具和库了），Java 开发人员可以完成所有工作，这真是一个奇迹。

　　No Fluff Just Stuff 软件论文系列的演讲者 Ben Galbraith 将此现象称作“Java 框架不确定性原则”：“您刚刚选择了一个框架，某个其他框架的新版本便发布了，从而迫使您对选择框架重新分析。”而且这种情况的复杂程度也无以复加了：只需将核心 J2EE 和 J2SE 类混合在一起使用。毕竟，我们被告知 EJB 是 J2EE 的“核心”，并且考虑一个没有 EJB 的企业 Java 项目将是一个愚蠢的想法，这只是昨天的事。究竟泛型如何改变您的 J2EE 编码体验？并且到底是谁让所有 Java 管理扩展成了路障？

　　到底是怎么了？最初明确专注于创建一个由单项优势工具和库构成的平台的行业何以在如此短的时间内变得如此零乱？我们何时需要在传统的“J2EE”工具（如 EJB）与新型“Web 服务”（如 JAXRPC 和 WS-Security）工具之间进行选择？更重要的是，我们现在如何做才能避免 Ben 的 Java 框架不确定性原则而又不违背 Java 首先应遵循的供应商无关原则？