步入J2EE架构和过程

<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 摘要 Java2企业版（J2EE）平台由四个关键部分构成：规格说明、参考实现、兼容性测试套件 和蓝图（BluePrint）计划。蓝图描绘了分布式组件架构最好的实践和设计指导方针。本 文基于Rational统一过程和BluePrint示例程序介绍一个八步骤J2EE开发方法学。通过阅 读这篇文章，你可以了解许多重要的J2EE架构的话题，并且能够扩展和修改这个简单的 方法来解决自己特有的业务问题。 在商业世界里，我们使用Java2 企业版（J2EE）解决业务问题、开发商业软件或者提供 转包服务。如果一家公司想使用多层体系结构建造一个电子商务网站，通常在整个开发 生命周期中需要涉及到管理者、架构师，设计人员、编程人员、测试人员和数据库专家 。 为了使不同部门能高效率地工作，他们经常需要一个软件开发过程。一些经典的开发过 程包括瀑布模型、快速应用开发（RAD）和极限编程（XP）。本文我们将集中于一个流行 的软件工程过程，即Rational统一过程（RUP）。RUP提供了一个给角色分配任务和责任 的严格方法。它的目标是保证我们在预期的进度和预算内开发出满足用户需求的高质量 软件。 我在J2EE开发中使用RUP出于以下三个原因。首先，RUP以架构为中心；在将资源分配给 全面开发之前，它先开发一个可执行的架构原型。其次，RUP是迭代并基于构件的。该架 构基线通常包括一个框架或基础设施以便于通过迭代增加构件，在不影响系统其他部分 的前提下定制和扩展一个系统的功能。最后，RUP利用一门工业标准语言--UML，可视化 建模系统的架构和构件。RUP有四个不同的开发阶段：初始、细化、构造和移交。然而， 本文从技术角度覆盖了J2EE开发的八个必要活动，主要集中在系统架构。 1、 需求分析 需求分析描述系统应该做什么或不应该做什么使得开发者和客户可以签署一份原始的商 业合同。可以使用业务概念、领域术语、用例和用户界面（UI）模型形成功能需求文档 。对于非功能需求，如性能和事务，可以在需求文档附件中详细说明。根据参与项目深 度的不同，确定在纸上还是使用HTML建造高层UI模型。 图1 展现了一个典型电子商务系统中的两个用例。查看订单（viewOrder）用例告诉我们 一个用户通过Web界面登陆系统、查看订单列表，点击链接查看特定订单的详细信息。增 加订单项（addLineItem）用例告诉我们浏览产品列表、选择感兴趣的产品并将它们添加 到购买订单中。 图1 订购用例 2、 面向对象分析 分析人员构造问题领域模型：类、对象和交互。分析应该与技术和实现细节无关，并包 含一个理想的模型。对象分析可以帮助理解问题并获得关于问题领域的知识。因为业务 过程的改变比信息技术的改变要慢得多，所以必须要维持一个不含技术细节的纯领域模 型。 这两个步骤--需求分析和面向对象分析--不是J2EE特有的；对许多面向对象方法学来说 ，它们都非常通用。图2 显示了一个宠物店示例程序的高层对象分析模型。它用图例说 明了我们从需求分析用例中识别的主要概念。我们把这些概念建模成对象并标识它们的 关系。 图2 更高层分析模型：宠物店领域 需求和对象分析的结果是为J2EE架构的开发提供切入点。为了开发架构，可以选择一个 纵向联合部分（vertical piece）--经常是关键部分，如订单领域对象模型--进行对象 设计、实现、测试和部署。（纵向联合部分，一个RUP概念，是指系统的一小部分。起始 点是图1所示的用例子集和图3所示的领域分析模型。一个纵向联合部分的实现结果是一 个全功能的微小系统，包括UI层的JSP，中间层业务对象如EJB和后端数据库。）可以将 从原型中获得的经验应用于领域对象并作为对象设计阶段的指导。 图3 详细对象分析：订单 3、 架构规格说明 经过前面两个步骤，业务领域问题和需求应该比较明确了。现在，我们将工作集中在技 术策略和架构上。架构是指所有构件组合定义系统的一个蓝图：结构、接口和通讯机制 。我们可以进一步将架构分为企业级和应用级架构。 企业级系统架构 企业级系统架构包括硬件和软件基础设施、网络布局、开发、测试、生产环境等等。它 反映了一个企业的长期投资。开发前，需要评估已存在的软件和硬件基础设施，如果不 完全支持J2EE的话，增加新构件更新已存在系统。你需要彻底地评估硬件，包括计算机 、路由器、网络转换器和网络布局，因为它们都影响到系统的性能和可靠性。图4 显示 了一个可能的多层网络布局。 图4 企业级架构：网络布局 如图4所示的一个多层企业级架构包括以下几个主要构件： 一个Web浏览器客户端，可能在也可能不在客户端组织的防火墙内 一个HTTP服务器，是一个对公众开放的Web服务器。它通常位于一个称作DMZ的子网内 Web容器主表示层和可能的业务逻辑构件 应用程序容器主业务逻辑构件 关系数据库管理系统（RDBMS）和数据库主数据、数据逻辑 你使用的系统架构类型依赖于安全、性能和可靠性的需求，也依赖于组织的财政状况。 在缺少经验的情况下，也可以适当地从一个修理厂电话订购一台简单地二手计算机。In ternet上有许多开放源代码的操作系统、Web服务器、应用程序服务器和数据库管理系统 。得到这些系统的代价只是几百美元和熬几个通宵。 象许多华尔街金融机构这样的高端客户也许需要一个连续支持安全、高吞吐量交易和不 可预料网络通讯的系统。在这种情况下，为了容错，通常需要将Web服务器和应用程序服 务器集群配置成一个n层架构。 还需要评估软件基础设施，包括Web服务器、安全管理软件、应用程序服务器、域名管理 服务器、数据库管理系统和第三方软件构件。如果还没有购买应用程序服务器，选择一 个J2EE供应商将是评估过程的一个重要方面。应该注意到不同的供应商对J2EE的实现程 度是不同的，一些供应商只支持老的J2EE版本。另外，一些Web容器或应用程序容器可能 比其他的速度要快。除了实现J2EE规范外，许多供应商还出售J2EE基础构件或框架。选 择一个稳定的提供支持的J2EE供应商也非常关键。你可以在系统基础设施层面上购买或 开发的通用功能包括： 事务 国际化和本地化 集群和对象分布 应用程序性能度量和剖析 通讯 工作流管理 入口和个性化管理 层对层通讯协议 安全和防火墙 应用架构 应用架构参考一个特定的项目和规范建立在企业级系统架构的上层。在基础设施完成后 ，架构师研究怎样构造一个特定的应用。如果你的企业级架构仅部分支持老的J2EE版本 ，可以先升级你的系统。如果由于预算或时间关系不能升级，那么必须在更老版本规定 的技术范围内开展工作。虽然构造企业级重用构件非常重要，但是必须首先要能够使用 。这里的最终目标是满足客户的需求--一次一个项目。 架构师不是设计师；架构和设计是完全不同。一个应用架构的范围包括系统的主要结构 、架构设计模式和可以在上面增加构件的框架。架构主要关注的是非功能性方面，而设 计关注应用业务用例将领域对象模型转换成技术对象模型。应用架构是项目的结构，一 个特殊的应用程序。通过应用架构开发，你通常必须要做的应用架构决定包括： 层之间进行功能划分 领域对象建模 要保护的遗留系统 要购买的软件构件 要开发的构件 怎样集成第三方构件 图3的订单领域对象说明了怎样对领域对象进行建模。利用当前的Java技术，可以将领域 对象分布在作为开发者管理持续性对象的Web容器中、应用程序服务器的EJB中或者作为 RDBMS宿主的Java存储过程中。 在宠物店蓝图中，我们将订单对象设计成一个实体bean，一个详细对象和一个数据访问 对象，如图5和后面的图6所示。当你看到这个的时候，你应该意识到架构的重要性。为 什么分析模型中的一个领域对象映射成这么多对象？如果改变设计，会出现什么问题？ 你也许听说过EJB的好处，但是要注意不同供应商的性能是不同的。当一种新技术到来的 时候，你需要在投入全面设计之前进行一些研究。你可以经常地将设计和实现领域对象 模型纵向联合部分的经验应用到其他许多领域对象中。这就是架构开发的内容。 图5 订单对象设计模型 在J2EE的早期，一些面向对象的设计人员试图将领域模型映射成实体bean并通过层传输 。它们包含很好的UML图，但结果是由于不必要的网络通讯使得系统运行很慢。没有架构 开发，没有清楚地理解一种新技术就从对象分析直接转到对象设计往往导致项目失败。 架构可交付产品 由于J2EE架构是一个相对新的话题，对于J2EE架构师的可交付产品还没有很好的定义。 从宠物店示例程序来说，很难区分架构在哪里停止，设计又在哪里开始。文档随应用架 构的高层检查、模型-视图-控制设计模式的讨论和架构总览开始。低层文档在源代码中 。这里没有UML图。Sun的J2EE企业架构师认证的委派部分要求所有产品用UML表示。然而 ，标记只表示类图、构件图和少量对象交互图。这些对真实世界里J2EE应用来说远远不 够。架构规格和过程至少需要下面的东西： 一份描述现存硬件、软件、网络布局和其他构件的系统架构文档 一份描述应用程序主要结构，包括所有重要结构构件、用例构件和遗留构件逻辑视图的 应用架构文档 一份如果有其他选择的情况下，描述所有设计指导和架构决定，解释这些决定并描述可 能结果的新构件设计指导。这些指导应该捕获所有重要的基础决定因素，新构件设计必 须考虑维护系统架构的完整性。 一个正在运转的架构原型，可以评估新技术；获得开发和部署J2EE应用程序的经验；构 造架构框架；度量性能、可伸缩性和易用性来说明风险；还可以向项目承担者证明你的 方法是可行的。 在开发了几个J2EE解决方案得到更多经验之后，原型变得不太重要，少量的UML图和一些 设计指导或许就足够了。