J2EE架构和过程

0

J2EE架构和过程
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模型。
在一个典型电子商务系统中的两个用例。查看订单（viewOrder）用例告诉我们 一个用户通过Web界面登陆系统、查看订单列表，点击链接查看特定订单的详细信息。增加订单项（addLineItem）用例告诉我们浏览产品列表、选择 感兴趣的产品并将它们添加到购买订单中。
2、面向对象分析分析人员构造问题领域模型：类、对象和交互。分析应该与技术和实现细节无关，并包 含一个理想的模型。对象分析可以帮助理解问题并获得关于问题领域的知识。因为业务过程的改变比信息技术的改变要慢得多，所以必须要维持一个不含技术细节的 纯领域模型。这两个步骤--需求分析和面向对象分析--不是J2EE特有的；对许多面向对象方法学来说，它们都非常通用。
一个宠物店示例程 序的高层对象分析模型。它用图例说明了我们从需求分析用例中识别的主要概念。我们把这些概念建模成对象并标识它们的关系。为了开发架构，可以选择一个纵向 联合部分（verticalpiece）--经常是关键部分，如订单领域对象模型--进行对象设计、实现、测试和部署。（纵向联合部分，一个RUP概念， 是指系统的一小部分。起始点是图1所示的用例子集和图3所示的领域分析模型。一个纵向联合部分的实现结果是一个全功能的微小系统，包括UI层的JSP，中 间层业务对象如EJB和后端数据库。）可以将从原型中获得的经验应用于领域对象并作为对象设计阶段的指导。
3、架构规格说明经过前面两个步 骤，业务领域问题和需求应该比较明确了。现在，我们将工作集中在技术策略和架构上。架构是指所有构件组合定义系统的一个蓝图：结构、接口和通讯机制。我们 可以进一步将架构分为企业级和应用级架构。企业级系统架构企业级系统架构包括硬件和软件基础设施、网络布局、开发、测试、生产环境等等。它反映了一个企业 的长期投资。开发前，需要评估已存在的软件和硬件基础设施，如果不完全支持J2EE的话，增加新构件更新已存在系统。你需要彻底地评估硬件，包括计算机、 路由器、网络转换器和网络布局，因为它们都影响到系统的性能和可靠性。
4企业级架构：一个多层企业级架构包括以下几个主要构件：一个Web 浏览器客户端，可能在也可能不在客户端组织的防火墙内一个HTTP服务器，是一个对公众开放的Web服务器。它通常位于一个称作DMZ的子网内Web容器 主表示层和可能的业务逻辑构件应用程序容器主业务逻辑构件关系数据库管理系统（RDBMS）和数据库主数据、数据逻辑你使用的系统架构类型依赖于安全、性 能和可靠性的需求，也依赖于组织的财政状况。在缺少经验的情况下，也可以适当地从一个修理厂电话订购一台简单地二手计算机。
Internet 上有许多开放源代码的操作系统、Web服务器、应用程序服务器和数据库管理系统。得到这些系统的代价只是几百美元和熬几个通宵。象许多华尔街金融机构这样 的高端客户也许需要一个连续支持安全、高吞吐量交易和不可预料网络通讯的系统。在这种情况下，为了容错，通常需要将Web服务器和应用程序服务器集群配置 成一个n层架构。还需要评估软件基础设施，包括Web服务器、安全管理软件、应用程序服务器、域名管理服务器、数据库管理系统和第三方软件构件。如果还没 有购买应用程序服务器，选择一个J2EE供应商将是评估过程的一个重要方面。应该注意到不同的供应商对J2EE的实现程度是不同的，一些供应商只支持老的 J2EE版本。
另外，一些Web容器或应用程序容器可能比其他的速度要快。除了实现J2EE规范外，许多供应商还出售J2EE基础构件或框 架。选择一个稳定的提供支持的J2EE供应商也非常关键。你可以在系统基础设施层面上购买或开发的通用功能包括：事务国际化和本地化集群和对象分布应用程 序性能度量和剖析通讯工作流管理入口和个性化管理层对层通讯协议安全和防火墙应用架构应用架构参考一个特定的项目和规范建立在企业级系统架构的上层。在基 础设施完成后，架构师研究怎样构造一个特定的应用。如果你的企业级架构仅部分支持老的J2EE版本，可以先升级你的系统。如果由于预算或时间关系不能升 级，那么必须在更老版本规定的技术范围内开展工作。虽然构造企业级重用构件非常重要，但是必须首先要能够使用。这里的最终目标是满足客户的需求--一次一 个项目。
架构师不是设计师；架构和设计是完全不同。一个应用架构的范围包括系统的主要结构、架构设计模式和可以在上面增加构件的框架。架构 主要关注的是非功能性方面，而设计关注应用业务用例将领域对象模型转换成技术对象模型。应用架构是项目的结构，一个特殊的应用程序。通过应用架构开发，你 通常必须要做的应用架构决定包括：层之间进行功能划分领域对象建模要保护的遗留系统要购买的软件构件要开发的构件怎样集成第三方构件图3的订单领域对象说 明了怎样对领域对象进行建模。利用当前的Java技术，可以将领域对象分布在作为开发者管理持续性对象的Web容器中、应用程序服务器的EJB中或者作为 RDBMS宿主的Java存储过程中。在宠物店蓝图中，我们将订单对象设计成一个实体bean，一个详细对象和一个数据访问对象，如图5和后面的图6所 示。当你看到这个的时候，你应该意识到架构的重要性。为什么分析模型中的一个领域对象映射成这么多对象？如果改变设计，会出现什么问题？你也许听说过 EJB的好处，但是要注意不同供应商的性能是不同的。当一种新技术到来的时候，你需要在投入全面设计之前进行一些研究。你可以经常地将设计和实现领域对象 模型纵向联合部分的经验应用到其他许多领域对象中。这就是架构开发的内容。
对象设计在架构规范的指导下，设计从技术上扩展和修改了分析结 果。虽然分析阶段的领域对象建模应该与技术细节无关，但是对象设计完全依赖于技术因素，包括平台、语言的类型和架构开发阶段选择的供应商。分析时，抬头望 着星星，但在设计阶段，则要脚踏实地。理论上，为了维持业务对象的基本属性和行为，除非绝对必要，不应该破坏它们。在架构结果的指导下，详细设计工作应该 说明所有类的规格，包括必须实现的属性、它们的详细接口和伪代码或操作的纯文本描述。规格说明应该足够详细使得和模型图结合时，它可以提供所有必须的编码 信息。在许多自动化软件生产过程中，我们可以从面向对象图生成代码框架。注意桩（stub）和框架（skeleton）在图中经常是不可见的，因为它们对 设计人员和编程员来说是透明的。
对象设计模型：订单EJB详细设计在完成了详细对象设计后，还需要完成 领域对象的对象-关系映射。原因是虽然面向对象方法学现在非常流行，但是大多数流行且成熟的持续性存储却是关系型的。另外，在许多情况下，客户的IT基础 设施已经反映了对商业RDBMS供应商的投资和偏爱。所以，将领域对象转换成关系模型或数据库表是非常重要的。虽然有许多容器管理的持续性工具，但它们不 能取代好的关系数据库设计。
5、实现在良好的架构和详细设计条件下，实现应该是一个明确的任务。另外，因 为我们设计和实现架构原型阶段的纵向联合部分，所以实现阶段应该更没有什么值得惊讶的。在许多组织中，开发者经常过早地到达实现阶段。尤其当管理者盯着开 发人员确保在编码，而不是做他们认为在浪费公司时间的其他事情时，这种情况变得更加严重。结果，不再花数小时或数天绘出UML草图，而是通常在发费数周或 数月编码的同时测试自己的想法。由于在这种情况下，所有地架构决定和设计都是在编码阶段做出来的，所以经常过了数月后才发现开发的方向出错了。
6、验证验证包括测试验证系统按设计要求运行并满足需求。验证过程发生在整个开发生命周期的开发和产品环境中。单元测试、集成测试和用户测试本身就是非常重要的主题。
7、 装配和部署构件装配和解决方案部署在J2EE开发中特别重要。开发和产品环境可能非常不同。如果EJB在系统中，你需要使用供应商特定的工具得到容器自动 生成的类，因为，正如我以前指出的，Web和应用程序构件配置对不同的供应商来说是不同的。你也必须考虑要部署的系统是否含有供应商特定代码实现。在可扩 展架构中，系统结构应该是稳定的但也应该在不影响整个系统的条件下支持新或老构件的增量部署。
8、运行和维护在最后阶段，应用程序到了用户 手中，你必须给他们提供培训和文档。用户会发现错误并可能要求新特性。你必须适当地改变管理过程来处理这些情况。你不必为了部署一个新构件或取代老构件而 关闭一个正在运行的系统。架构开发过程知道了必须做出许多架构决定，因此我们必须为架构开发描绘一个过程。对于一个企业来说通常有许多应用项目，它们中的 一些可能跨越数年，结果是系统演化包含许多周期。在你的领域里存在着许多跨越多个项目的通用需求。你应该不费力地在它的生命周期或其他项目中使用以前项目 周期的可扩展且可重用的架构。为一系列软件应用提供同属结构和行为的通用框架和可重用软件架构是非常需要的。
如果是第一个J2EE项目，架 构必须做原型、测试、度量、分析并在迭代中进行推敲。蓝图提供了许多好的设计指导和实践，宠物店示例程序可以作为一个很好的参考架构。最有效地快速、高质 量发布好的解决方案的方法是接受和扩展蓝图参考架构并插入你自己的业务构件。你最后要做的就是改造车轮。接受一个参考架构就我的理解，宠物店架构的精华是 模型-视图-控制和命令模式。你可以将这些模式应用到以Web为中心和以EJB为中心的系统中。对于每个领域对象，视图用嵌套的JSP表示。控制器处理相 关的业务事件，领域对象封装业务逻辑、事物和安全。我们使用门户servlet作为中心控制器接受和截获所有用户的动作。它将业务事件分发给特定的调用领 域对象改变持续状态的领域对象控制器。依靠事件处理结果，控制器选择下一个要展现的视图。
下面是我们可以修改并在大多数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框架，必 须实现一些用例来说明架构确实可以为你的领域服务。可以通过选用捕获系统关键功能的场景来实现，这些场景经常使用来展现关键的技术风险。
从 领域分析模型入手，可以将领域对象映射成高层和低层设计模型。实现低层设计模型并测试是否真正在工作。如果每件事都按计划运行，那么重新评估风险开始下一 个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系统和怎样 将它们对接。
下一步是软件设计，你可以使用设计指导中规定好的类似方法和过程继续开发。一步一步我们使用一个过程来将一个复杂问题分解为较 小的几个问题，这使得我们可以更容易的理解和解决它们。在本文中，我们将J2EE开发分解为八个步骤，主要集中在架构和设计。我已经阐述了重要的架构并为 架构决定提供了一个过程。我也讨论了J2EE架构师的角色和可交付产品。学习使用这些步骤开发J2EE解决方案就象学习跳舞的步骤一样。首先需要自觉并持 之以恒地练习基本步骤。但是，一旦你对它们相当熟悉后，应该将它们放在一起并将注意力更多地集中在规模、速度、流和特定上下文中每一步的节奏。但永远不要 让一个过程限制了创造性。而应该接受和扩展过程以满足自己特殊需要。记住，最终目的是提供满足客户需求的完整的J2EE解决方案。

pnHrELL4.doc (38.5 KB, 下载次数: 2 )

0