分类：
2008-10-16 19:51:27
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供应商也很关键. 你能购买或开发的系统级常用功能包括:
[1]
