八个步骤开发完整的J2EE解决方案

《八个步骤开发完整的J2EE解决方案》由会员分享，可在线阅读，更多相关《八个步骤开发完整的J2EE解决方案（6页珍藏版）》请在金锄头文库上搜索。

1、八个步骤开发完整的J2EE解决方案J2EE平台由四个关键的部分定义：规范，实现参考，兼容性测试例和蓝图计划(BluePrint )。蓝图描述分布式组件架构的最佳实践和设计指导方 针。本文介绍了基于Rational统一开发过程(Rational Unified Process)和 设计图应用实例的八个步骤的J2EE开发。通过阅读本文，你将更好地懂得许多 重要的J2EE架构方面的主题，并能够将这些知识应用于扩展和修改这个简单的 实例以解决你特定的逻辑问题(September 28 , 2001 )在商业世界里,我们使用J2EE解决商业问题来开发商业软件或给别的 商业项目提供约定服务。 如果一个公司

2、想利用多层架构开发一个电子商务站点， 整个开发生命周期通常包括管理员，架构帅，设计师，程序员，测试者，和数据库专家。为了使各个不同的部分能更有效的协同工作，他们通常需要遵循一定的软件开发流程。 经典的开发流程包括瀑布模型，快速原型开发(RAD和极限编程(XP)。在本文中我们将聚焦于统一开发过程(RUP。RUP提供一种经 过检验的方法来分配任务和责任给不同的角色。其目标是保证我们生产出可预期，可预算，符合我们需求的高质量的软件。我之所以喜欢在J2EE的开发过程中使用RU咄于以下三个原因：首先， RUP以架构为中心的; 它在为大规模开发提交资源之前开发出一个可执行的 架构原型。 其次，RUP是基于

3、迭代并基于架构的。其架构通常包括框架和基础结构，可以反复地加入新的组件来定制的扩充系统的功能，而这些都不会影响到系统的其它部分。最后RUP用行业标准语言一UM床为系统架构和组件 建模。RUP有四个不同的开发阶段：初始阶段，细化阶段， 构造阶段，和交付阶段。本文从技术的观点出发， 着重强调架构的思想， 涵盖了 J2EE开发 所涉及到的八个基本的步骤。1.需求分析需求分析描述了系统应该做什么， 不应该做什么， 在此基 础上开发者和客户可以达成共识。 你可以将功能性的需求如业务概念， 领域术 语，用例和用户界面(UI)形成文档。 非功能性的需求， 例如性能，事务等 可以在辅助性的需求文档中指出。 你

4、可以在纸上或者以HTML勺形式创建高水准 的用户界面， 这取决于你参与项目的深度。图1表示一个典型的电子商务系统中的两个示例性的用例图。 viewOrder用例告诉我们用户通过 Wet#面登录系统， 查看订单歹U表， 点击一 个链接查看购物订单的详细内容。addLineltems用例则告诉我们用户浏览商品 目录，选择自己感兴趣的商品，将它们添加到购物活单中。2面向对象的分析分析员产生如下问题域模型：类，对象和交互。你的分析应该独立于任何技术或实现细节，包含概念上的模型。对象分析理解问题并获得问题域的相关知识。由丁业务过程的变化比信息技术慢得多，你得确保你的域模型不涉及技术细节。上述两个步骤一需

5、求分析和面向对象分析一不是 J2EE规范；它们在许 多面向对象方法论中很常见。图2更为详细地显示了一个宠物商店应用实例的对象分析模型。 它图解了我们可以从需求分析用例图中所能得到的一些主要的 概念。我们将这些概念以对象和他们之间的关系将之模型化。Figure 2. 更高层分析模型：宠物店领域需求分析和对象分析的结果是J2EE架构开发的切入点。为了开发一个 架构，你应当选择纵向联合部分一通常是一个主要部分，例如订单域对象模型作为对象设计， 实现，测试和部署（vertical piece , 一个RUP既念，是 系统的一部分。 起始点是用例图的一个子集，例如图1所示，和图3所示的域分析模型。Ver

6、tical piece的实施结果是一个功能齐全的小的系统，它包括所有层，例如UI层的JSP,中间业务层对象如EJB,还有数据库）。 你可 以将原型系统中的经验应用丁域对象，让它作为对象设计阶段的设计指导方针。Figure 3. 详细对象分析模型：购物单3. 架构规格说明经过了以上两步，业务域中的问题和需求应该很活晰了。现在我们将精力转向技术策略和架构。架构是一个总体设计，它包括系统中一起定义的所有部分：结构，接口和通信机制。我们可以更进一步将架构分为企业级架构和应用级架构。企业级系统架构：企业型架构覆盖了硬件， 软件，网络技术，开发， 测试，产品环境等等。 这是企业的长远投资。 在开发之前，你

7、的评估一下现 有的软硬件设施，如果它们不能很好地支持J2EE可能还得增加一些新的组件或 者升级现有的系统。 你得彻底地对调查硬件环境， 包括电脑，路由器、交换 机和网络的拓扑结构， 它们都有可能对系统的性能和可靠性带来影响。图4显示了一个可能存在的多层网络拓扑结构。Figure 4. 企业级架构：网络拓扑结构图4所示的多层企业级架构有如下主要的组成部分：*客户端的Wetffl览器，它有可能位丁客户端所在组织的 防火墙的后面？* HTTP服务器是面向公众的服务器端?它通常位丁子网之中？* Web容器，包含表示层，可能还有业务逻辑组件？*应用服务器，包含业务逻辑组件？*关系数据库管理系统（RDBM

8、SS数据库，包含数据和数据逻辑？你所用的系统架构取决丁你对丁山，性能，可靠性的要求，当然还得 考虑组织的经济状况.对丁最低端的应用，你可以合理地在仓库里使用二手电 脑，用电话线连接.网上有许多开源的操作系统，Web务器，应用服务器，数 据库管理系统可用.那么这个系统你可能只需要付出几白美元和熬几个通宵而 已.对丁高端客户，例如华尔街上的金融机构，可能要求系统能持续地支持 安全,高吞吐量的事务处理,和不可预知的网络流量.在这种情况下,通常你需 或包含Wet务器和应用服务器的n层架构来配置成集群以提高容错性.同样你也得考虑软件组织,包括Wet务器,安全管理软件,应用服务 器，域名管理服务器，数据库

9、管理系统，和第三方软件组件.如果你还没有购 买应用服务器，选择一个J2EE提供商是整个评估过程中的一个重要方面.不同 的提供商对丁 J2EE的实施区别很大，有些提供商仅仅支持J2EE的旧版本.另外, 有些We垢器和应用容器可能比较超前.与J2EE规范的实施不同的是，许多提 供商可能也同时卖J2EE组件或框架.选择一个提供支持的稳定的J2EEK应商也 很关键.你能购买或开发的系统级常用功能包括:事务？网络化和本地化？集群和对象分布？会话管理？应用性能的衡量和profilling?消息？工作流管理？入口和个性化管理？层与层之间的通信协议？安全和防火墙？ 应用级架构构建丁企业级系统架构之上的应用架构

10、与特定的项目或应用有关.基础组织完成后，架构帅就得考虑特定的应用了 .如果你的企业架构只是部分支持 J2EE的旧版本，你可能得首先升级你的系统.如果你基丁预算或时间的考虑不 能升级你的系统，你就得考虑活楚由丁使用旧版本带来的一些限制.构建可复 用的企业级组建也很重要，在考虑它的可用性之前你就得考虑其可复用性.最 终的目标是满足客户的需求一在某个时间完成项目.架构帅不是设计帅；架构和设计是两个不同的概念.应用架构的范围包 括系统的主要结构，架构设计模式和框架，依赖丁这些你可以添加组件.架构 所关注的是非功能性的，而设计关注的是你将域对象模型转换为技术上的对象 模型所用到的逻辑用例.应用架构是项目

11、结构，特殊的应用.应用架构开发过 程中通常需考虑的部分包括:层之间的功能？模型域对象？可继承的系统保存什么(What legacy system to save)？购买什么样的软件组件？购买什么组件？如何集成第三方组件？图3所示购物单域对象示范了如何对域对象建模.如今的Java技术允许 你进行分布式开发，域对象作为开发者管理的持久化对象位丁 We昭器，应用 服务器包含EJB,关系数据库管理系统存储数据.在宠物商店BluePrint中，我们将订单对象设计为一个实体 Bean, 一个详细的对象，一个数据访问对象，如图5和其后的图6所示.当你看到这些的时 候，你可能就明白了架构的重要性.试问一下在模

12、型分析中一个域对象映射到 那么多对象，如果你改变了设计会发生什么.你可能听说了一些EJB的优点， 也明白不同提供商的实现的性能也是大不相同.一项新技术出现后，在利用其 进行大规模设计之前你需要进行研究并做一些辅助性的工作.你可以将在设计和实现域对象模型的vertical pieces中学到的知识应用于许多其它的域对象的 设计之中.这就是架构开发相关内容.Figure 5.购物单对项涉及模型在J2EE的早期，有些面向对象设计师试图将域对象映射为实体 Bean并通过层传递它们.他们设计出不错的UMLfl，但结果由于不必要的网络 流量导致系统速度非常慢.如果在对象分析后不进行架构开发，缺乏对新技术的

13、完全理解就直接进 入对象设计，几乎总是会导致项目的失败.架构交付由于J2EE架构是一个相对较新的课题，J2EE架构的交付不太好定义. 以宠物商店的应用为例，彳艮难明确什么时候架构开发结束，设计开始.文档开 始于对应用架构所作的高级别的检查，对MVCS计模式的讨论和对架构的总体 理解.低层次的文档适用于源程序.Sun的J2EE企业架构设计证明要求 UMLH 中包括所有可交付部分.然而这些符号只存在于类图，组件图，和一些对象交 互图中.这在现实世界中的J2EE应用中远远不够.为了开始，架构规范和过程 至少需要下面的部分：*系统架构系统，描述已有的硬件，?软件，网络技术和其他组件*应用架构文档，描述

14、应用的主要结构，包括所有架构中所有重要组件 的逻辑试图，用例，可复用的组件？*新组件的设计指导方针，?描述所有涉及指导方针，架构定义，解释 所有定义，描述如果应用替代品时应采用的时序.这些指导方针应当包括所有重要的，基本的，决定性的 部分，使得新的组件设计不会影响现有系统的架构完整性.* 一个用于评估新技术的可运行的架构原型；在开发和部署J2EE应用 中获得经验；创建架构的框架；通过？权衡性能，可测量性，难易度来评估风险；向项目客户提供方案可 行性报告.在解决了一些J2EE问题，获得了更多的经验后，原型就变得不是很重 要了，一些UMLB和一些设计指导方针就足够了 .4. 对象设计设计技术以架构

15、规范作指导，是分析结果的扩充和进一步体现.分 析阶段的域对象模型与技术细节无关，而对象设计则与技术要素有着密切的关 系，包括平台类型，语言，架构开发阶段所选择的提供商.分析阶段可能只关 注目标，但设计阶段就得脚踏实地了 .除非必须保持基本届性和行为，否则不 要轻易让你的设计受到业务对象的影响.以架构设计为指导，详细设计应考虑到所有类的式样，包括实现细节， 详细的接口,操作的伪代码或者解释的文字性描述.说明书要足够详细,包括 模型图，它提供所有必要的编码信息.有些开发工具有自动生成的功能，你可 以根据面向对象图表生成代码骨架.图5和图6分别在较高层次和详细的对象设 计层次上图示了一些域模型.注意由丁存根和骨架对丁设计师和程序员是透明 的因而它们通常不出现在图表中.我将它们包含在图6中用丁阐述EJB基本概 念.IMG upload/forum/20031219172210.jpg/IMGFigure 6.对项涉及模型：订单EJB详细设计在详细的对象设计完成后，你也就完成了域对象的对象关系映射. 这么做的理由是尽管面向对象方法论现在比较先进，但最流行，最成熟的持久化也t还是关系型的.另外在许多案例中客户先期所用的是关系数据库管理系统 最好能保留他们的已有投资.所以将丁对象模型转换为关系模型或数据表是很 重要的.有许多容器管理的持久化工具，但它们还是不能替代好的关系数据库 设计