网络化和本地化?
集群和对象分布?
会话管理?
应用性能的衡量和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图和一些设计指导方针就足够了.
更多内容请看PCdog.com--数字化校园网解决方案专题
