标 题: 步入J2EE架构和过程 发信站: BBS 水木清华站 (Fri Apr 26 16:02:08 2002)
本文转自赛迪网开发者 developer.ccidnet.com
摘要 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图和一些 设计指导或许就足够了。 4、 对象设计 在架构规范的指导下，设计从技术上扩展和修改了分析结果。虽然分析阶段的领域对象 建模应该与技术细节无关，但是对象设计完全依赖于技术因素，包括平台、语言的类型 和架构开发阶段选择的供应商。分析时，抬头望着星星，但在设计阶段，则要脚踏实地 。理论上，为了维持业务对象的基本属性和行为，除非绝对必要，不应该破坏它们。 在架构结果的指导下，详细设计工作应该说明所有类的规格，包括必须实现的属性、它 们的详细接口和伪代码或操作的纯文本描述。规格说明应该足够详细使得和模型图结合 时，它可以提供所有必须的编码信息。在许多自动化软件生产过程中，我们可以从面向 对象图生成代码框架。图5和6 说明了对一些领域对象的高层和详细设计对象。注意桩（ stub）和框架（skeleton）在图中经常是不可见的，因为它们对设计人员和编程员来说 是透明的。我将它们包括在图6中以说明EJB的基础部分。 图6 对象设计模型：订单EJB详细设计 在完成了详细对象设计后，还需要完成领域对象的对象-关系映射。原因是虽然面向对象 方法学现在非常流行，但是大多数流行且成熟的持续性存储却是关系型的。另外，在许 多情况下，客户的IT基础设施已经反映了对商业RDBMS供应商的投资和偏爱。所以，将领 域对象转换成关系模型或数据库表是非常重要的。虽然有许多容器管理的持续性工具， 但它们不能取代好的关系数据库设计。 5、 实现 在良好的架构和详细设计条件下，实现应该是一个明确的任务。另外，因为我们设计和 实现架构原型阶段的纵向联合部分，所以实现阶段应该更没有什么值得惊讶的。在许多 组织中，开发者经常过早地到达实现阶段。尤其当管理者盯着开发人员确保在编码，而 不是做他们认为在浪费公司时间的其他事情时，这种情况变得更加严重。 结果，不再花数小时或数天绘出UML草图，而是通常在发费数周或数月编码的同时测试自 己的想法。由于在这种情况下，所有地架构决定和设计都是在编码阶段做出来的，所以 经常过了数月后才发现开发的方向出错了。 6、 验证 验证包括测试验证系统按设计要求运行并满足需求。验证过程发生在整个开发生命周期 的开发和产品环境中。单元测试、集成测试和用户测试本身就是非常重要的主题。 7、 装配和部署 构件装配和解决方案部署在J2EE开发中特别重要。开发和产品环境可能非常不同。如果 EJB在系统中，你需要使用供应商特定的工具得到容器自动生成的类，因为，正如我以前 指出的，Web和应用程序构件配置对不同的供应商来说是不同的。你也必须考虑要部署的 系统是否含有供应商特定代码实现。在可扩展架构中，系统结构应该是稳定的但也应该 在不影响整个系统的条件下支持新或老构件的增量部署。 8、 运行和维护 在最后阶段，应用程序到了用户手中，你必须给他们提供培训和文档。用户会发现错误 并可能要求新特性。你必须适当地改变管理过程来处理这些情况。你不必为了部署一个 新构件或取代老构件而关闭一个正在运行的系统。 架构开发过程 知道了必须做出许多架构决定，因此我们必须为架构开发描绘一个过程。对于一个企业 来说通常有许多应用项目，它们中的一些可能跨越数年，结果是系统演化包含许多周期 。在你的领域里存在着许多跨越多个项目的通用需求。你应该不费力地在它的生命周期 或其他项目中使用以前项目周期的可扩展且可重用的架构。为一系列软件应用提供同属 结构和行为的通用框架和可重用软件架构是非常需要的。 如果是第一个J2EE项目，架构必须做原型、测试、度量、分析并在迭代中进行推敲。蓝 图提供了许多好的设计指导和实践，宠物店示例程序可以作为一个很好的参考架构。最 有效地快速、高质量发布好的解决方案的方法是接受和扩展蓝图参考架构并插入你自己 的业务构件。你最后要做的就是改造车轮。 接受一个参考架构 就我的理解，宠物店架构的精华是模型-视图-控制和命令模式。你可以将这些模式应用 到以Web为中心和以EJB为中心的系统中。对于每个领域对象，视图用嵌套的JSP表示。控 制器处理相关的业务事件，领域对象封装业务逻辑、事物和安全。我们使用门户servle t作为中心控制器接受和截获所有用户的动作。它将业务事件分发给特定的调用领域对象 改变持续状态的领域对象控制器。依靠事件处理结果，控制器选择下一个要展现的视图 。下面是我们可以修改并在大多数J2EE应用程序中使用的主要构件： a、 MainServlet：门户构件，Web容器和框架之间的接口 b、 ModelUpdateListener：获得模型更新事件对象的接口 c、 ModelUpdateNotifier：当更新模型事件发生时通知侦听器 d、 RequestProcessor：处理所有从MainServlet来的请求。 e、 RequestHandler：即插即用请求处理构件接口 f、 RequestHandlerMapping：包含请求处理映射规则 g、 RequestToEventTranslator：中心请求处理器根据请求处理映射规则代理即插即用 请求处理构件的请求。将http请求转换为业务事件 h、 EstoreEvent：业务事件 i、 ShoppingClientControllerWebImpl：代理EJB层门户控制器 j、 ScreenflowManager：控制屏幕流，选择视图 k、 ModelUpdateManager：EJB层模型更新管理器，通知什么模型由于事件发生了改变 l、 ShoppingClientControllerEJB：EJB层门户，为EJB客户提供远程服务 m、 StateMachine：中心事件处理器，根据状态处理映射规则代理即插即用处理构件的 事件处理 n、 StateHandler：EJB层状态处理接口 o、 StateHandlerMapping：包含状态处理映射规则 扩展参考架构 虽然蓝图示例程序是一个好的起点，但应该根据每个项目或领域修改它。设计模式是可 重用的微体系结构，可以使用它扩展参考架构。提供了一组有用的J2EE模式目录的蓝图 和23个”四人帮”模式都是非常不错的资源。例如，如果想扩展参考架构支持工作流管理 ，你可以在部署或运行时动态地在中心控制器注册事件处理器。中心控制器会询问每个 注册的事件处理器直到一个处理器返回消息表明到了命令链的末端。 插入你的业务构件 J2EE技术对每个人都是一样的，但是不同的领域，我们要解决的问题是不同的。一旦建 立了一个基本的J2EE框架，必须实现一些用例来说明架构确实可以为你的领域服务。可 以通过选用捕获系统关键功能的场景来实现，这些场景经常使用来展现关键的技术风险 。从领域分析模型入手，可以象我们在图5和6中那样将领域对象映射成高层和低层设计 模型。实现低层设计模型并测试是否真正在工作。如果每件事都按计划运行，那么重新 评估风险开始下一个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。 经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系 统和怎样将它们对接。下一步是软件设计，你可以使用设计指导中规定好的类似方法和 过程继续开发。 一步一步 我们使用一个过程来将一个复杂问题分解为较小的几个问题，这使得我们可以更容易的 理解和解决它们。在本文中，我们将J2EE开发分解为八个步骤，主要集中在架构和设计 。我已经阐述了重要的架构并为架构决定提供了一个过程。我也讨论了J2EE架构师的角 色和可交付产品。 学习使用这些步骤开发J2EE解决方案就象学习跳舞的步骤一样。首先需要自觉并持之以 恒地练习基本步骤。但是，一旦你对它们相当熟悉后，应该将它们放在一起并将注意力 更多地集中在规模、速度、流和特定上下文中每一步的节奏。但永远不要让一个过程限 制了创造性。而应该接受和扩展过程以满足自己特殊需要。记住，最终目的是提供满足 客户需求的完整的J2EE解决方案。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/227305.html原文链接：https://javaforall.cn
