八个步骤开发完整的J2EE解决方案
摘要
J2EE平台由四个关键的部分定义: 规范, 实现参考, 兼容性测试例和蓝图计划(BluePrint). 蓝图描述分布式组件架构的最佳实践和设计指导方针. 本文介绍了基于Rational统一开发过程(Rational Unified Process)和设计图应用实例的八个步骤的J2EE开发. 通过阅读本文，你将更好地懂得许多重要的J2EE架构方面的主题，并能够将这些知识应用于扩展和修改这个简单的实例以解决你特定的逻辑问题(September 28, 2001)
在商业世界里, 我们使用J2EE解决商业问题来开发商业软件或给别的商业项目提供约定服务. 如果一个公司想利用多层架构开发一个电子商务站点，整个开发生命周期通常包括管理员, 架构师, 设计师, 程序员, 测试者, 和数据库专家. 
为了使各个不同的部分能更有效的协同工作, 他们通常需要遵循一定的软件开发流程. 经典的开发流程包括瀑布模型, 快速原型开发(RAD)和极限编程(XP). 在本文中我们将聚焦于统一开发过程(RUP). RUP提供一种经过检验的方法来分配任务和责任给不同的角色. 其目标是保证我们生产出可预期, 可预算, 符合我们需求的高质量的软件. 
我之所以喜欢在J2EE的开发过程中使用RUP出于以下三个原因: 首先, RUP是以架构为中心的; 它在为大规模开发提交资源之前开发出一个可执行的架构原型. 其次, RUP是基于迭代并基于架构的. 其架构通常包括框架和基础结构, 可以反复地加入新的组件来定制的扩充系统的功能, 而这些都不会影响到系统的其它部分. 最后RUP使用行业标准语言—UML来为系统架构和组件建模. RUP有四个不同的开发阶段: 初始阶段, 细化阶段, 构造阶段, 和交付阶段. 本文从技术的观点出发, 着重强调架构
的思想, 涵盖了J2EE开发所涉及到的八个基本的步骤.
1. 需求分析
需求分析描述了系统应该做什么, 不应该做什么, 在此基础上开发者和客户可以达成共识. 你可以将功能性的需求如业务概念, 领域术语, 用例和用户界面(UI)形成文档. 非功能性的需求, 例如性能, 事务等可以在辅助性的需求文档中指出. 你可以在纸上或者以HTML的形式创建高水准的用户界面, 这取决于你参与项目的深度.
图1表示一个典型的电子商务系统中的两个示例性的用例图. viewOrder用例告诉我们用户通过Web界面登录系统, 查看订单列表, 点击一个链接查看购物订单的详细内容. addLineItems用例则告诉我们用户浏览商品目录, 选择自己感兴趣的商品, 将它们添加到购物清单中.

图1. 购物单用例图
2 面向对象的分析
分析员产生如下问题域模型: 类, 对象和交互. 你的分析应该独立于任何技术或实现细节, 包含概念上的模型.对象分析理解问题并获得问题域的相关知识. 由于业务过程的变化比信息技术慢得多, 你得确保你的域模型不涉及技术细节. 
上述两个步骤—需求分析和面向对象分析—不是J2EE规范; 它们在许多面向对象方法论中很常见. 图2更为详细地显示了一个宠物商店应用实例的对象分析模型. 它图解了我们可以从需求分析用例图中所能得到的一些主要的概念. 我们将这些概念以对象和他们之间的关系将之模型化.

Figure 2. 更高层分析模型: 宠物店领域
需求分析和对象分析的结果是J2EE架构开发的切入点. 为了开发一个架构, 你应当选择纵向联合部分—通常是一个主要部分, 例如订单域对象模型—作为对象设计, 实现, 测试和部署(vertical piece, 一个RUP概念, 是系统的一部分. 起始点是用例图的一个子集, 例如图1所示, 和图3所示的域分析模型. Vertical piece的实施结果是一个功能齐全的小的系统, 它包括所有层, 例如UI层的JSP, 中间业务层对象如EJB, 还有数据库). 你可以将原型系统中的经验应用于域对象, 让它作为对象设计阶段的设计指导方针.

Figure 3. 详细对象分析模型: 购物单
3．架构规格说明
经过了以上两步, 业务域中的问题和需求应该很清晰了. 现在我们将精力转向技术策略和架构. 架构是一个总体设计, 它包括系统中一起定义的所有部分: 结构, 接口和通信机制. 我们可以更进一步将架构分为企业级架构和应用级架构.
企业级系统架构:
企业型架构覆盖了硬件, 软件, 网络技术, 开发, 测试, 产品环境等等. 这是企业的长远投资. 在开发之前, 你的评估一下现有的软硬件设施, 如果它们不能很好地支持J2EE可能还得增加一些新的组件或者升级现有的系统. 你得彻底地对调查硬件环境, 包括电脑, 路由器, 交换机和网络的拓扑结构, 它们都有可能对系统的性能和可靠性带来影响. 图4显示了一个可能存在的多层网络拓扑结构.

Figure 4. 企业级架构: 网络拓扑结构
图4所示的多层企业级架构有如下主要的组成部分:
 * 客户端的Web浏览器, 它有可能位于客户端所在组织的防火墙的后面
 * HTTP服务器是面向公众的服务器端. 它通常位于子网之中
 * Web容器, 包含表示层, 可能还有业务逻辑组件.
 * 应用服务器, 包含业务逻辑组件.
 * 关系数据库管理系统(RDBMS)和数据库, 包含数据和数据逻辑.
你所用的系统架构取决于你对于安全, 性能, 可靠性的要求, 当然还得考虑组织的经济状况. 对于最低端的应用, 你可以合理地在仓库里使用二手电脑, 用电话线连接. 网上有许多开源的操作系统, Web服务器, 应用服务器, 数据库管理系统可用. 那么这个系统你可能只需要付出几百美元和熬几个通宵而已. 
对于高端客户, 例如华尔街上的金融机构, 可能要求系统能持续地支持安全, 高吞吐量的事务处理, 和不可预知的网络流量. 在这种情况下, 通常你需要由包含Web服务器和应用服务器的n层架构来配置成集群以提高容错性. 
同样你也得考虑软件组织, 包括Web服务器, 安全管理软件, 应用服务器, 域名管理服务器, 数据库管理系统, 和第三方软件组件. 如果你还没有购买应用服务器, 选择一个J2EE提供商是整个评估过程中的一个重要方面. 不同的提供商对于J2EE的实施区别很大, 有些提供商仅仅支持J2EE的旧版本. 另外, 有些Web容器和应用容器可能比较超前. 与J2EE规范的实施不同的是, 许多提供商可能也同时卖J2EE组件或框架. 选择一个提供支持的稳定的J2EE供应商也很关键. 你能购买或开发的系统级常用功能包括:
 ���务
 网络化和本地化
 集群和对象分布
 会话管理
 应用性能的衡量和profilling
 消息
 工作流管理
 入口和个性化管理
 层与层之间的通信协议
 安全和防火墙
应用级架构
构建于企业级系统架构之上的应用架构与特定的项目或应用有关. 基础组织完成后, 架构师就得考虑特定的应用了. 如果你的企业架构只是部分支持J2EE的旧版本, 你可能得首先升级你的系统. 如果你基于预算或时间的考虑不能升级你的系统, 你就得考虑清楚由于使用旧版本带来的一些限制. 构建可复用的企业级组建也很重要, 在考虑它的可用性之前你就得考虑其可复用性. 最终的目标是满足客户的需求—在某个时间完成项目.
架构师不是设计师; 架构和设计是两个不同的概念. 应用架构的范围包括系统的主要结构, 架构设计模式和框架, 依赖于这些你可以添加组件. 架构所关注的是非功能性的, 而设计关注的是你将域对象模型转换为技术上的对象模型所用到的逻辑用例. 应用架构是项目结构, 特殊的应用. 应用架构开发过程中通常需考虑的部分包括:
 层之间的功能
 模型域对象
 可继承的系统保存什么(What legacy system to save)
 购买什么样的软件组件
 购买什么组件
 如何集成第三方组件
图3所示购物单域对象示范了如何对域对象建模. 如今的Java技术允许你进行分布式开发, 域对象作为开发者管理的持久化对象位于Web容器, 应用服务器包含EJB, 关系数据库管理系统存储数据. 
在宠物商店BluePrint中, 我们将订单对象设计为一个实体Bean, 一个详细的对象, 一个数据访问对象, 如图5和其后的图6所示. 当你看到这些的时候, 你可能就明白了架构的重要性. 试问一下在模型分析中一个域对象映射到那么多对象, 如果你改变了设计会发生什么. 你可能听说了一些EJB的优点, 也明白不同提供商的实现的性能也是大不相同. 一项新技术出现后, 在利用其进行大规模设计之前你需要进行研究并做一些辅助性的工作. 你可以将在设计和实现域对象模型的vertical pieces中学到的知识应用于许多其它的域对象的设计之中. 这就是架构开发相关内容.

Figure 5. 购物单对项涉及模型
在J2EE的早期, 有些面向对象设计师试图将域对象映射为实体Bean并通过层传递它们. 他们设计出不错的UML图, 但结果由于不必要的网络流量导致系统速度非常慢.
如果在对象分析后不进行架构开发, 缺乏对新技术的完全理解就直接进入对象设计，几乎总是会导致项目的失败.
架构交付
由于J2EE架构是一个相对较新的课题, J2EE架构的交付不太好定义. 以宠物商店的应用为例, 很难明确什么时候架构开发结束, 设计开始. 文档开始于对应用架构所作的高级别的检查, 对MVC设计模式的讨论和对架构的总体理解. 低层次的文档适用于源程序. Sun的J2EE企业架构设计证明要求UML图中包括所有可交付部分. 然而这些符号只存在于类图, 组件图, 和一些对象交互图中. 这在现实世界中的J2EE应用中远远不够. 为了开始, 架构规范和过程至少需要下面的部分:
* 系统架构系统, 描述已有的硬件, 软件, 网络技术和其他组件
* 应用架构文档, 描述应用的主要结构, 包括所有架构中所有重要组件的逻辑试图, 用例, 可复用的组件
* 新组件的设计指导方针, 描述所有涉及指导方针, 架构定义, 解释所有定义, 描述如果应用替代品时应采
用的时序. 这些指导方针应当包括所有重要的, 基本的, 决定性的部分, 使得新的组件设计不会影响现有
系统的架构完整性.
* 一个用于评估新技术的可运行的架构原型; 在开发和部署J2EE应用中获得经验; 创建架构的框架; 通过
权衡性能, 可测量性, 难易度来评估风险; 向项目客户提供方案可行性报告.
在解决了一些J2EE问题, 获得了更多的经验后, 原型就变得不是很重要了, 一些UML图和一些设计指导方针就足够了.
4. 对象设计
设计技术以架构规范作指导, 是分析结果的扩充和进一步体现. 分析阶段的域对象模型与技术细节无关, 而对象设计则与技术要素有着密切的关系, 包括平台类型, 语言, 架构开发阶段所选择的提供商. 分析阶段可能只关注目标, 但设计阶段就得脚踏实地了. 除非必须保持基本属性和行为, 否则不要轻易让你的设计受到业务对象的影响.
以架构设计为指导, 详细设计应考虑到所有类的式样, 包括实现细节, 详细的接口, 操作的伪代码或者解释的文字性描述. 说明书要足够详细, 包括模型图, 它提供所有必要的编码信息. 有些开发工具有自动生成的功能, 你可以根据面向对象图表生成代码骨架. 图5和图6分别在较高层次和详细的对象设计层次上图示了一些域模型. 注意由于存根和骨架对于设计师和程序员是透明的因而它们通常不出现在图表中. 我将它们包含在图6中用于阐述EJB基本概念. 

Figure 6. 对项涉及模型: 订单EJB详细设计
在详细的对象设计完成后, 你也就完成了域对象的对象关系映射. 这么做的理由是尽管面向对象方法论现在比较先进, 但最流行, 最成熟的持久化存储还是关系型的. 另外在许多案例中客户先期所用的是关系数据库管理系统, 最好能保留他们的已有投资. 所以将于对象模型转换为关系模型或数据表是很重要的. 有许多容器管理的持久化工具, 但它们还是不能替代好的关系数据库设计. 
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框架，必须实现一些用例来说明架构确实可以为你的领域服务。可以通过选用捕获系统关键功能的场景来实现，这些场景经常使用来展现关键的技术风险。从领域分析模型入手，可以象我们在图5和6中那样将领域对象映射成高层和低层设计模型。实现低层设计模型并测试是否真正在工作。如果每件事都按计划运行，那么重新评估风险开始下一个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系统和怎样将它们对接。下一步是软件设计，你可以使用设计指导中规定好的类似方法和过程继续开发。 
一步一步 
我们使用一个过程来将一个复杂问题分解为较小的几个问题，这使得我们可以更容易的理解和解决它们。在本文中，我们将J2EE开发分解为八个步骤，主要集中在架构和设计。我已经阐述了重要的架构并为架构决定提供了一个过程。我也讨论了J2EE架构师的角色和可交付产品。 
学习使用这些步骤开发J2EE解决方案就象学习跳舞的步骤一样。首先需要自觉并持之以恒地练习基本步骤。但是，一旦你对它们相当熟悉后，应该将它们放在一起并将注意力更多地集中在规模、速度、流和特定上下文中每一步的节奏。但永远不要让一个过程限制了创造性。而应该接受和扩展过程以满足自己特殊需要。记住，最终目的是提供满足客户需求的完整的J2EE解决方案。