精通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 首先应遵循的供应商无关原则？

　　此问题主要在于了解最能满足需要的技术，而最好的方法是首先了解应用程序的需要。了解应用程序的需要后，即可清楚地界定应选用的相应技术。

　　本文将简要概述最先进的 J2EE、与其相关的技术以及 Java 开发人员当今面临的某些体系结构挑战。

　　我们如今要走向何处？

　　很多不同类型的 Java 程序在“企业 Java”的名义下趋于变得臃肿，在深入讨论前，这也许有助于将它们与其他类型的 Java 应用程序区分开。如果我们从传统的“3 层”方法开始（即将表示、业务逻辑和数据访问划分为三个一致的设计层次），则我们实际上可以确定五种“企业”Java 应用程序：烟囱、宝石、聚合器、集成器和企业应用程序。

　　“我们实际上可以确定五种“企业”Java 应用程序：烟囱、宝石、聚合器、集成器和企业应用程序”。

　　烟囱烟囱应用程序（也称作“竖井”）可能是开发人员最容易接受的应用程序，这是因为它是一种我们一再开发的应用程序：它是传统的“单数据库、单 UI”应用程序，就绝对数量而言，它是当前构建最广的一种 IT 应用程序。它通常是根据某个部门经理或副经理的需要（即寻找某个特定工具或应用程序来收集、操作和显示某种当前未收集、操作和显示的数据）而开始创建的，为此将组建一个团队（规模通常不超过三到四个人，往往只有一个人）来收集需求、建立用例、构建数据库、对业务逻辑进行编码、将其部署到选择作为此应用程序的生产服务器的机器并不断地监视它。

　　当然，此名称得自您在白板上绘制的三个框（表示系统的逻辑层 — 表示层、业务逻辑层和数据访问层）所形成的图像 — 它们构成了一条垂直线，不由使人想起将燃烧木头的火炉中产生的烟排出到房间外面的旧式“烟囱”。（顺便说一下，对于将该术语用作贬义术语的用户而言，请记住，您在一生中将使用的许多最重要的系统（如 ATM 机、主要船运公司场地上的包裹定位器等）都是烟囱系统。

　　有一点可能比较令人吃惊的是，J2EE 软件套件并不能完全满足构建简单烟囱系统的开发人员的需要。当只需要一个表示层，且只有一个资源用于存储和检索数据时，J2EE 套件（尤其是 EJB）就显得“碍事”了。更诱人的方法是考虑轻型框架，因为它们并不那么专注于部署描述符，并且就 JNDI、JMS 之类而言也没什么不便的。它只是通过 web 浏览器进行的基本请求/响应通信，通常构建在类似 Struts 或相似的 MVC 样式 web 框架中，并与一组核心的传统 Java 对象（有时与单个机器上运行的表示层和业务逻辑层（而非数据库本身））进行通信。（您可能奇怪此处为什么没有使用术语“数据库”。原因很简单，虽然大多数项目使用数据库（而且还是关系数据库）存储数据，但数据存储通常是原有系统、商业软件程序包或形如 CICS 大型机、SAP 或 BizTalk 的“中介”技术。使用更一般的术语“资源”有助于强调这样一个看法：后端实现确实与本讨论无关。）

　　烟囱应用程序的另一个优势是它们通常是“独立的” — 也就是说不涉及其他应用程序。几乎不需要遵守任何已建立的安全、可靠性或管理标准，这是因为此应用程序所确立的所有内容都将成为标准（至少对此应用程序而言是这样，这正是此范围的关键所在）。开发人员经常利用此事实来构建正好适合于此应用程序的基础架构，从而消除了通常针对企业 Java 应用程序的指责：它们太复杂了，以至于无法使用和维护。

　　尽管人们希望如此，但 J2EE 的设计并非是针对烟囱应用程序的 — 当然，一个基于 J2EE 的应用程序可以构建此类应用程序（并且有上千个示例可以作为此事实的证据），事实上有点像用牛刀杀鸡。基于 J2EE 的应用程序实施了一定程度的层划分，但有时这种划分对于解决手头的问题显得有些矫枉过正，如传统的“10 用户”烟囱系统。当然，问题是 10 用户烟囱系统通常有一种另人不悦的趋势，即转变为其他四个版本中的某个版本，这样将使事情变得很糟。就像某位哲学家说的那样“没有哪个人是孤立的”，我们也可以很轻松和准确地说“没有哪个系统是孤立的”。至少在短期内是这样。（当然，如果系统无法完成其预期的目标，那它就无法与任何其他系统集成，并且可能停产，但我们将假设那不是预期的目标。）

　　珠宝 我们并不是说这是 IT 环境的成功和骄傲或五种应用程序样式中“最好”的一个，但珠宝样式的应用程序是结合了多个表示层的应用程序（因此，它的名称--“珠宝”表示有很多面可供查看）。但请注意，给定表示层可能根本不是供用户查看的；公司当前经常探讨的一个层是其基于 Web 服务的应用程序前端，它并非为人使用而设。尽管如此，该 Web 服务仍表示一个表示层，这是因为它从根本上执行同一操作：获取输入并从其下面的核心业务逻辑层中提供输出。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有