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

八个步骤开发完整的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用例则告诉我们用户浏览商品目录，选择自己感兴趣的商品，将它们添加到购物清单中。

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的优点, 也明

白不同提供商的实现的性能也是大不相同. 一项新技术出现后, 在利用其进行