百度广告
在商业世界里， 我们使用J2EE解决商业问题来开发商业软件或给别的商业项目提供约定服务。 如果一个公司想利用多层架构开发一个电子商务站点，整个开发生命周期通常包括管理员， 架构师， 设计师， 程序员， 测试者， 和数据库专家。
为了使各个不同的部分能更有效的协同工作， 他们通常需要遵循一定的软件开发流程。 经典的开发流程包括瀑布模型， 快速原型开发（RAD）和极限编程（XP）。 在中我们将聚焦于统一开发过程（RUP）。 RUP提供一种经过检验的方法来分配任务和责任给不同的角色。 其目标是保证我们生产出可预期， 可预算， 符合我们需求的高质量的软件。
我之所以喜欢在J2EE的开发过程中使用RUP出于以下三个原因： 首先， RUP是以架构为中心的； 它在为大规模开发提交资源之前开发出一个可执行的架构原型。 其次， RUP是基于迭代并基于架构的。 其架构通常包括框架和基础结构， 可以反复地加入新的组件来定制的扩充系统的功能， 而这些都不会影响到系统的其它部分。 最后RUP使用行业标准语言-UML来为系统架构和组件建模。 RUP有四个不同的开发阶段： 初始阶段， 细化阶段， 构造阶段， 和交付阶段。 从技术的观点出发， 着重强调架构的思想， 涵盖了J2EE开发所涉及到的八个基本的步骤。
1.需求分析需求分析描述了系统应该做什么， 不应该做什么， 在此基础上开发者和客户可以达成共识。 你可以将功能性的需求如业务概念， 领域术语， 用例和用户界面（UI）形成文档。 非功能性的需求， 例如性能， 事务等可以在辅助性的需求文档中指出。 你可以在纸上或者以HTML的形式创建高水准的用户界面， 这取决于你参与项目的深度。
图1表示一个典型的电子商务系统中的两个示例性的用例图。 viewOrder用例告诉我们用户通过Web界面登录系统， 查看订单列表， 点击一个链接查看购物订单的详细内容。 addLineItems用例则告诉我们用户浏览商品目录， 选择自己感兴趣的商品， 将它们添加到购物清单中。
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浏览器, 它有可能位于客户端所在组织的防火墙的后面?
* Web容器, 包含表示层, 可能还有业务逻辑组件?
* 关系数据库管理系统(RDBMS)和数据库, 包含数据和数据逻辑?
对于高端客户, 例如华尔街上的金融机构, 可能要求系统能持续地支持安全, 高吞吐量的事务处理, 和不可预知的网络流量. 在这种情况下, 通常你需要由包含Web服务器和应用服务器的n层架构来配置成集群以提高容错性.
事务?
集群和对象分布?
应用性能的衡量和profilling?
工作流管理?
层与层之间的通信协议?
应用级架构
构建于企业级系统架构之上的应用架构与特定的项目或应用有关. 基础组织完成后, 架构师就得考虑特定的应用了. 如果你的企业架构只是部分支持J2EE的旧版本, 你可能得首先升级你的系统. 如果你基于预算或时间的考虑不能升级你的系统, 你就得考虑清楚由于使用旧版本带来的一些限制. 构建可复用的企业级组建也很重要, 在考虑它的可用性之前你就得考虑其可复用性. 最终的目标是满足客户的需求-在某个时间完成项目.
架构师不是设计师; 架构和设计是两个不同的概念. 应用架构的范围包括系统的主要结构, 架构设计模式和框架, 依赖于这些你可以添加组件. 架构所关注的是非功能性的, 而设计关注的是你将域对象模型转换为技术上的对象模型所用到的逻辑用例. 应用架构是项目结构, 特殊的应用. 应用架构开发过程中通常需考虑的部分包括:
模型域对象?
购买什么样的软件组件？
如何集成第三方组件?
图3所示购物单域对象示范了如何对域对象建模. 如今的Java技术允许你进行分布式开发, 域对象作为开发者管理的持久化对象位于Web容器, 应用服务器包含EJB, 关系数据库管理系统存储数据.
Figure 5. 购物单对项涉及模型
在J2EE的早期, 有些面向对象设计师试图将域对象映射为实体Bean并通过层传递它们. 他们设计出不错的UML图, 但结果由于不必要的网络流量导致系统速度非常慢. 如果在对象分析后不进行架构开发, 缺乏对新技术的完全理解就直接进入对象设计，几乎总是会导致项目的失败.
架构交付
由于J2EE架构是一个相对较新的课题, J2EE架构的交付不太好定义. 以宠物商店的应用为例, 很难明确什么时候架构开发结束, 设计开始. 文档开始于对应用架构所作的高级别的检查, 对MVC设计模式的讨论和对架构的总体理解. 低层次的文档适用于源程序. Sun的J2EE企业架构设计证明要求UML图中包括所有可交付部分. 然而这些符号只存在于类图, 组件图, 和一些对象交互图中. 这在现实世界中的J2EE应用中远远不够. 为了开始, 架构规范和过程至少需要下面的部分: 在解决了一些J2EE问题, 获得了更多的经验后, 原型就变得不是很重要了, 一些UML图和一些设计指导方针就足够了. 4. 对象设计 IMG upload/forum/20031219172210.jpg[/IMG] Figure 6. 对项涉及模型: 订单EJB详细设计 在详细的对象设计完成后, 你也就完成了域对象的对象关系映射. 这么做的理由是尽管面向对象方法论现在比较先进, 但最流行, 最成熟的持久化存储还是关系型的. 另外在许多案例中客户先期所用的是关系数据库管理系统, 最好能保留他们的已有投资. 所以将于对象模型转换为关系模型或数据表是很重要的. 有许多容器管理的持久化工具, 但它们还是不能替代好的关系数据库设计. 5.实现
有了好的架构和详细设计后, 实现应该是一个明确的任务。另外，因为我们设计和实现架构原型阶段的纵向联合部分，所以实现阶段应该更没有什么值得惊讶的。在许多组织中，开发者经常过早地到达实现阶段。尤其当管理者盯着开发人员确保在编码，而不是做他们认为在浪费公司时间的其他事情时，这种情况变得更加严重。 6.验证
验证包括测试验证系统按设计要求运行并满足需求。验证过程发生在整个开发生命周期的开发和产品环境中。单元测试、集成测试和用户测试本身就是非常重要的主题。 7.装配和部署
构件装配和解决方案部署在J2EE开发中特别重要。开发和产品环境可能非常不同。如果EJB在系统中，你需要使用供应商特定的工具得到容器自动生成的类，因为，正如我以前指出的，Web和应用程序构件配置对不同的供应商来说是不同的。你也必须考虑要部署的系统是否含有供应商特定代码实现。在可扩展架构中，系统结构应该是稳定的但也应该在不影响整个系统的条件下支持新或老构件的增量部署。 8.运行和维护
在最后阶段，应用程序到了用户手中，你必须给他们提供培训和文档。用户会发现错误并可能要求新特性。你必须适当地改变管理过程来处理这些情况。你不必为了部署一个新构件或取代老构件而关闭一个正在运行的系统。 架构开发过程
知道了必须做出许多架构决定，因此我们必须为架构开发描绘一个过程。对于一个企业来说通常有许多应用项目，它们中的一些可能跨越数年，结果是系统演化包含许多周期。在你的领域里存在着许多跨越多个项目的通用需求。你应该不费力地在它的生命周期或其他项目中使用以前项目周期的可扩展且可重用的架构。为一系列软件应用提供同属结构和行为的通用框架和可重用软件架构是非常需要的。 插入你的业务构件
J2EE技术对每个人都是一样的，但是不同的领域，我们要解决的问题是不同的。一旦建立了一个基本的J2EE框架，必须实现一些用例来说明架构确实可以为你的领域服务。可以通过选用捕获系统关键功能的场景来实现，这些场景经常使用来展现关键的技术风险。从领域分析模型入手，可以象我们在图5和6中那样将领域对象映射成高层和低层设计模型。实现低层设计模型并测试是否真正在工作。如果每件事都按计划运行，那么重新评估风险开始下一个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系统和怎样将它们对接。下一步是软件设计，你可以使用设计指导中规定好的类似方法和过程继续开发。 一步一步 学习使用这些步骤开发J2EE解决方案就象学习跳舞的步骤一样。首先需要自觉并持之以恒地练习基本步骤。但是，一旦你对它们相当熟悉后，应该将它们放在一起并将注意力更多地集中在规模、速度、流和特定上下文中每一步的节奏。但永远不要让一个过程限制了创造性。而应该接受和扩展过程以满足自己特殊需要。记住，最终目的是提供满足客户需求的完整的J2EE解决方案。
* 应用架构文档, 描述应用的主要结构, 包括所有架构中所有重要组件的逻辑试图, 用例, 可复用的组件?
用的时序. 这些指导方针应当包括所有重要的, 基本的, 决定性的部分, 使得新的组件设计不会影响现有
* 一个用于评估新技术的可运行的架构原型; 在开发和部署J2EE应用中获得经验; 创建架构的框架; 通过?
设计技术以架构规范作指导, 是分析结果的扩充和进一步体现. 分析阶段的域对象模型与技术细节无关, 而对象设计则与技术要素有着密切的关系, 包括平台类型, 语言, 架构开发阶段所选择的提供商. 分析阶段可能只关注目标, 但设计阶段就得脚踏实地了. 除非必须保持基本属性和行为, 否则不要轻易让你的设计受到业务对象的影响.
以架构设计为指导, 详细设计应考虑到所有类的式样, 包括实现细节, 详细的接口, 操作的伪代码或者解释的文字性描述. 说明书要足够详细, 包括模型图, 它提供所有必要的编码信息. 有些开发工具有自动生成的功能, 你可以根据面向对象图表生成代码骨架. 图5和图6分别在较高层次和详细的对象设计层次上图示了一些域模型. 注意由于存根和骨架对于设计师和程序员是透明的因而它们通常不出现在图表中. 我将它们包含在图6中用于阐述EJB基本概念.
||| 接受一个参考架构
就我的理解，宠物店架构的精华是模型-视图-控制和命令模式。你可以将这些模式应用到以Web为中心和以EJB为中心的系统中。对于每个领域对象，视图用嵌套的JSP表示。控制器处理相关的业务事件，领域对象封装业务逻辑、事物和安全。我们使用门户servlet作为中心控制器接受和截获所有用户的动作。它将业务事件分发给特定的调用领域对象改变持续状态的领域对象控制器。依靠事件处理结果，控制器选择下一个要展现的视图。下面是我们可以修改并在大多数J2EE应用程序中使用的主要构件：
b、 ModelUpdateListener：获得模型更新事件对象的接口
d、 RequestProcessor：处理所有从MainServlet来的请求。
f、 RequestHandlerMapping：包含请求处理映射规则
h、 EstoreEvent：业务事件
j、 ScreenflowManager：控制屏幕流，选择视图
l、 ShoppingClientControllerEJB：EJB层门户，为EJB客户提供远程服务
n、 StateHandler：EJB层状态处理接口
扩展参考架构
虽然蓝图示例程序是一个好的起点，但应该根据每个项目或领域修改它。设计模式是可重用的微体系结构，可以使用它扩展参考架构。提供了一组有用的J2EE模式目录的蓝图和23个"四人帮"模式都是非常不错的资源。例如，如果想扩展参考架构支持工作流管理，你可以在部署或运行时动态地在中心控制器注册事件处理器。中心控制器会询问每个注册的事件处理器直到一个处理器返回消息表明到了命令链的末端。
编辑推荐：
温馨提示：因考试政策、内容不断变化与调整，长理培训网站提供的以上信息仅供参考，如有异议，请考生以权威部门公布的内容为准！ (责任编辑：长理培训)
点击加载更多评论>>