GMCC综合应用管理系技术规范

文件编号：密级：项目ID：总页数：共37页项目名称:综合应用管理系统（IAMS）技术规范版本<V1.0>拟制日期审核日期批准日期声明本文档所有权和解释权归广东移动通信有限责任公司及其下属市公司所有，未经书面许可，不得复制或向第三方公开。ThisdocumentisthepropertyofGMCCanditsbranchesandcanbeneitherreproducednordisclosedtoathirdpartywithoutawrittenauthorization.修订历史记录版本日期AMD修订者说明（A-添加，M-修改，D-删除）

目录1. 文档介绍 51.1 文档目的 51.2 文档范围 51.3 读者对象 51.4 参考文献 51.5 术语与缩写解释 52. 系统概述 72.1 现状 72.2 目标 72.3 差距分析 82.3.1用户需求响应时间的差距 82.3.2系统成本的差距 82.3.3维护质量的差距 82.3.4资源利用率的差距 82.3.5企业应用集成水平的差距 82.4 发展建议 82.5 成功案例 103. 系统总体结构 123.1 系统总体结构 123.2 系统软硬件平台逻辑结构及配置 133.2.1标准型软硬件平台 133.2.2增强型软硬件平台 143.2.3软硬件平台技术特点 153.3 应用系统逻辑设计 163.3.1三层服务应用程序 163.3.2三级分布基础结构 173.3.3部署方案 184. 通用组件的结构与功能 204.1 目录同步组件 204.2 消息通知组件 214.3 集中授权组件 214.4 服务器监控组件 214.5 流程管理组件（可选项） 225. 系统性能要求 235.1 可缩放性 235.2 可用性 245.3 维护性 255.4 安全性 265.5 易管理性 265.5.1异常管理 275.5.2监视 285.5.3配置 285.5.4元数据 305.6 性能 306. 系统外延要求 326.1 与广东移动统一信息平台（门户）的整合要求 326.2 用户管理 326.3 网络环境 337. 系统实施和运维要求 347.1 开发规范 347.2 运行维护 347.2.1应用系统的开发测试 347.2.2应用系统的实施部署 347.2.3系统维护管理 347.2.4系统安全管理 347.2.5数据备份 357.2.6应急处理方案 358. 知识产权及保密要求 37文档介绍文档目的编制本文档主要用来为广东移动各市公司各种管理支撑系统（业务支撑系统除外，下同，应有系统与此同义）提供统一的硬软件平台（以下简称“综合应用管理系统”）和运行于综合应用管理系统之上的各管理支撑系统开发提供指导性规范与建议；协助有需要的各市公司早日构筑符合各自需要的综合应用管理系统；保障开发商规范、统一和高效地整合已有和开发新建应用系统到综合应用管理系统；实现应用系统和综合应用管理系统各基础子系统与省公司统一信息门户的无缝集成。文档范围文档介绍了综合应用管理系统以及各通用组件的总体情况，详细介绍了综合应用管理系统的软硬件结构、软硬件平台上提供各应用系统使用的通用组件的功能和接口、以及和统一信息门户整合的接口规范。在这基础上，给出了运行于综合应用管理系统上应用系统的开发要求和规范，为开发商的系统实现工作提供指导，同时也为平台建设维护者提供原理性指导。读者对象移动公司IT技术人员；移动公司IT系统建设／规划人员；移动公司IT系统维护人员第三方开发商参考文献术语与缩写解释缩写、术语解释IAMSIntegratedApplicationManagementSystem，综合应用管理系统统一信息平台广东移动集门户系统、统一用户管理和EAI一体的平台系统EAI企业应用集成，EnterpriseApplicationIntegrationLDAP轻量级目录访问协议，LightweightDirectoryAccessProtocolAD活动目录，ActiveDirectorySSO单点登录，SingleSignOn系统概述综合应用管理系统是广东移动市公司管理支撑系统集中运行的硬件环境和系统软件环境的统一平台，提供了各支撑系统使用的通用系统模块，主要包括统一用户管理、统一提醒通知、系统监控、基础通信设施等（通用模块将在实践过程中不断积累扩充），并规定了在这个平台上运行的各应用系统的设计实现要求，只要符合技术规范的应用系统都可以方便地接入到平台中。现状随着公司计算机应用水平的不断提高，公司内部各职能部门和生产中心新建的中小规模应用系统正不断增多。这些兴建的应用系统：第一、在技术选型、软件架构、软硬件平台上各不相同，直接造成了系统管理维护上的诸多不便。第二，由于各应用系统需要单独进行技术选型，购置软硬件设备，造成了系统总体成本相当程度的浪费。第三，各应用系统由于没有统一规划，各自建造，导致很多系统模块重复建设，数据重复保存、版本不一，信息无法统一管理共享利用等等。总之，根据公司现有IT资源配置情况，开发周期无法满足开发需求的要求、系统整体价格居高不下、维护工作疲于应付、各个系统相对独立形成信息孤岛。目标为了对市公司中小应用系统进行更好的统一规划、统一建设、统一管理，应建设一个公司级管理支撑系统运行的软硬件平台，选用统一通用的软件体系结构，并形成相应的管理制度和技术规范，指导和规范各公司相关管理支撑系统工作者和开发商的系统建设、运行和维护。此平台的体系架构、系统规模、系统性能自具有良好可扩张性的前提下，满足市公司今后近3年应用系统的发展需求，因此必须结合各公司的实际情况，有计划、分步骤的实施，以求建成一个：用户需求响应快系统成本低维护质量高资源利用率高信息共享程度高的市公司级的管理支撑系统综合开发、测试和应用的综合平台，为应用系统建设管理提供一个良好的基础。差距分析2.3.1用户需求响应时间的差距对于各部门的“短平快”（时间短、价格平、响应快）管理支撑系统开发需求，在现有公司资源配置情况下，除部分小项目可以在规定时间内自主开发外，其它需求几乎无法满足需求者的时限要求，通过建设综合应用管理系统，可以使我们减少技术选型、软硬件平台采购和安装调试等环节，还可有效缩短测试上载时间，进而达到缩短响应时间的目的。2.3.2系统成本的差距综合应用管理系统中将采用适宜的体系结构。综合应用管理系统的引入，使得各应用系统不需单独进行技术选型、软硬件购置、培训和维护，使得应用系统总体成本得到有效控制，在第三方软件和维护成本的降低方面，效果尤其明显。2.3.3维护质量的差距目前各系统使用技术各不相同、物理位置分布公司各处，维护成本非常高。采用综合应用管理系统后，在一定的约束条件下，由于采取的体系结构、软硬件环境等基本相同，从而不仅降低了管理、维护的难度和工作量，而且由于应用平台本身提供了相应的数据备份、数据容错机制，相应提高了系统的可靠性、稳定性和安全性。2.3.4资源利用率的差距离散应用系统使用各自的软硬件设备，不能做到充分利用。通过对综合应用管理系统的体系结构、软硬件平台的认真规划，可以在保证系统的安全性、通用性、可靠性、可扩展性的前提下，大大提高硬件、软件、机架、端口等资源的利用率，以达到集约经营的目的。2.3.5企业应用集成水平的差距如果沿用过去应用系统的开发、管理、维护模式，由于不同应用系统各自采用了不同的软件架构、不同的认证方式、不同的软硬件平台，使将来实施EAI工作变动十分困难。综合应用管理系统将使这些应用系统的移植简便易行。发展建议现阶段，广东移动处于集约发展阶段，各市公司业务扩展速度非常快。为更好地支持这种业务增长，各市公司根据自身地特点提出了很多满足个性化需求应用系统。这些需求没必要也很难由省公司或集团公司统一实现，但不统一规划集中管理，以后集成的难度更大。先规范各市公司的系统建设，把分散在多处的各种管理支撑系统统一到一个平台上面，并不断总结建设经验，是集团公司统一信息化建设进程的一个必要步骤。而各市公司管理支撑系统建设中存在开发周期无法满足开发需求、系统整体价格居高不下、维护工作疲于应付、各个系统相对独立形成信息孤岛等也是急待解决的问题。在这种背景下，经过广泛调研，我们认为建设一个公司级的应用系统综合开发、测试和应用平台（以下简称综合应用管理系统）是加强集中化管理、提高服务水平、降低系统成本、改善系统管理和维护质量的有效途径。现阶段各市公司提出管理支撑系统的需求，总的要求是“短平快”，基本特征是数据库、简单流程、访问量和集中度并不高，这些都可以在综合应用管理系统上得到很好的满足。对业务量较小的、本身不具备建设综合应用管理系统的人力物力的公司，可考虑由应用系统建设在邻近区域中心，由区域中心提供相应的系统平台资源。下图是综合应用管理系统的逻辑结构图：硬件平台硬件平台软件平台通用组件…系统1系统2系统3系统n综合应用管理系统硬件环境采用基于X86的PC服务器，软件环境采用微软windows平台和.Net技术。X86的PC服务器具有很高的性价比，升级扩容方便，通过采用横向扩充技术可以满足未来性能上需要。Windows平台在提供了强大的服务器功能的同时，相对简单易用，这大大降低平台的开发维护成本。.NET技术是综合应用管理系统的核心技术，该软件体系结构：提供强大的平台基础设施。WindowsServer系列，.NETFramework等提供了构建和运行平台系统的基础设施。提供多样的通用组件。一组用于企业内部网络的信息共享服务，如ActiveDirectory(用于用户身份验证)，以及用于文件存储、用户偏好管理、日历管理的服务等.NET服务，为企业应用建设提供了多样的基础通用服务。提供对XMLWebservice技术的全面支持。通过XMLWebservice技术可以方便企业内部各个系统之间进行无缝的连接，各种系统可以互相通信，互相作用，从而实现整个企业的协同运作。通过配合MicrosoftWindowsSystem其他部件，如SQLServer，biztalkServer，CommerceServer，ApplicationCenter等，可以有效较快企业集成的速度，降低企业集成的难度。提供了多种访问方式。用户可以通过各种方式、在各种不同设备上方便地获取自己想要的信息。提供强大的开发工具。VisualStudio.NET等开发工具通过友好的界面大大降低了开发工作的负责性，有效降低了系统开发的人力成本。.NET体系是已经被证明了、适合公司中小规模应用系统的、成熟的软件结构。综合应用管理系统包括生产和测试两部分。生产部分应通过负载均衡技术和集群技术保证平台的可扩展性和健壮性。测试部分在软件环境上完全模拟生产环境进行应用的功能性能测试，以达到保证生产系统的正确性。综合应用管理系统的建设，希望达到以下目标：提供管理支持系统运行的统一硬件环境，具有良好的可扩展性，实现后续应用的快速实施提供管理支持系统运行的统一软件环境，软件架构具有一定先进性，至少可以满足未来至少三年的发展需要提供管理支持系统共享使用的通用组件，各系统可以在此基础上进行信息交互，并减少不必要的重复建设提供管理支持系统建设的管理制度和技术规范，指导不同开发商系统建设，使不同系统在综合应用管理系统上稳定运行随着平台的进一步发展，平台应沿着不断加强通用基础设施的建设方向发展，提供消息服务、安全服务、组织目录服务、归档服务功能，搭建应用底层通用平台，逐步实现企业应用集成。成功案例深圳公司于2002年4月建成的综合应用管理系统，经过先后两次的升级扩容，现已成为一个包含用户管理、单点认证、办公协作、统一信息展现、消息通知、集中授权、系统监控等通用基础设施、其上运行接近20个管理支撑系统的平台系统。深圳公司综合应用管理系统基本上按照上述的4层架构模式搭建的。作为顶层各管理支撑系统共同使用的下面三层的具体结构功能将在后面章节具体描述。对于顶层的各管理支撑系统，平台并没有对其业务进行硬性规定，只要符合技术规范的各种系统都可以方便的接入到平台中，广泛地使用平台提供地各种通用组件。下面简单介绍一下深圳公司综合应用管理系统上管理支撑系统的各种应用：深圳公司综合应用管理系统上运行着文档管理系统、合同/预算/核算管理系统、部门门户网站等建成系统，有等系统正在建设中，还和OA、HR、CS110等系统成功地进行了异构集成，最后通过门户实现集中认证、协同办公和统一信息展现。门户系统：实现了各种信息的集中展现和各应用系统待办待阅工作统一处理的入口，也是各应用系统的一个统一接入点。文档管理系统：负责公司内部文档的科学管理，分目录、按权限实现文档共享。方便用户文档存放、管理、搜索。合同/预算/核算管理系统：实现了“投资立项->合同签订->预算报帐->项目核算”的财务闭环管理。在线考试系统：实现统一管理题库、自动组卷、自动判卷，最终达到对考试、培训、学习的高效管理。服务营销信息广场：支撑营业厅一线管理工作，担负信息共享、申报审批、辅助业务等功能。办公设备管理信息系统：专门针对我公司的所有办公设备从其入库到报废过程中发生的全部信息进行记录和反映、实现流程闭环管理。后勤门户网站：包含车辆调度与管理、物料供应、物业和内勤服务与管理等部分，为员工工作生活提供了有力的保障。休闲特区：包括BBS、电影、音乐等网站，丰富员工的工作生活。……随着公司信息化建设发展，综合应用管理系统的应用范围和规模不断扩大，并形成了一种用户部门提出业务需求，信息技术中心充分利用平台资源，统一规划建设各管理支撑系统的良好局面。系统总体结构本章介绍了综合应用管理系统总体结构以及和统一信息平台的关系，并根据市公司规模给出了不同的综合应用管理系统软硬件配置方案，最后给出了综合应用管理系统上管理支撑系统的设计逻辑，从总体上指导综合应用管理系统以及其上运行的管理支撑系统的建设。系统总体结构下面是综合应用管理系统的系统架构图：综合应用管理系统的系统总体结构可以划分为四部分：硬件平台、软件平台、通用组件以及运行于平台上面的各应用系统。硬件平台：提供了承载系统的服务器以及连接各服务器的网络环境。软件平台：提供了操作系统、数据库、负载均衡（ApplicationCenter）、Internet信息服务、活动目录等系统软件。提供了一个应用程序运行的基础软件环境。通用组件：将综合应用管理系统上一些通用基础的功能封装成一系列功能相对独立的组件，现包括目录同步、消息通知、集中授权、监控等通用功能，并以组件的形式实现。（各子系统详细描述见第4部分“通用组件的结构与功能”）通用组件会随着平台的发展逐步抽象扩充。应用系统：运行于软硬件平台之上，利用综合应用管理系统通用组件设施提供的通用功能，实现用户部门提出的具体业务需求的应用系统。综合应用管理系统四个部分构成了一个整体，但还必须和广东移动统一信息平台进行整合，以实现统一信息展现、单点登录和用户数据管理等。（详见6.1“与广东移动统一信息平台的整合要求”）系统软硬件平台逻辑结构及配置 综合应用管理系统的体系架构、系统规模、系统性能必须能够满足公司今后近3年应用系统的发展需求，因此在建设综合应用管理系统的时候必须结合公司的实际情况，有计划、分步骤的实施。各市公司综合应用管理系统的软硬件平台结构基本一致，但由于各公司应用规模等情况有所区别，所以系统具体的软硬件配置分成增强型和标准型两种。3.2.1标准型软硬件平台软硬件平台逻辑结构图：软硬件配置标准：序号项目描述1WebServer(2台)作为所有应用系统的WebServer，通过ApplicationCenter2000实现各应用系统的负载均衡及系统管理，其中一台为主控；或利用Windows2003Server的NLB（NetworkLoadBalance）功能。最低硬件配置：2.0G*1CPU、1G内存、36G推荐硬件配置：2.8G*2CPU、2G内存、36G*2HD_Raid1软件：WindowsServer2003、ApplicationCenter2000（或利用WindowsServer2003的NLB－NetworkLoadBalance功能替代ApplicationCenter2000，但无推荐）2DBServer(1台)FileServer(1台)作为所有应用系统的数据库服务器及专门放置附件的文件服务器、数据放置于磁盘阵列最低硬件配置：DBServer2.8G*1CPU、1G内存、36GFileServer2.8G*1CPU、1G内存、36G推荐硬件配置：DBServer2.8G*2CPU、2G内存、36G*2HD_Raid1。FileServer2.8G*2CPU、2G内存、36G*2HD_Raid1。软件:WindowsServer2003、SQLServer2000Enterprise3测试WebServer(1台)测试用WebServer硬件:2.0GCPU、512M内存、36G*2HD_Raid1。软件:WindowsServer20034测试DB/FileServer(1台)测试用DBServer和FileServer硬件:2.0GCPU、512M内存、36G*2HD_Raid1。软件:WindowsServer2003、SQLServer20005开发工具VisualStudio.Net2003注：上述配置仅仅是建议，具体部署时应与设备供应商、集成商商议确定，特别是在DB服务器、文件服务器和磁盘阵列方面。3.2.2增强型软硬件平台软硬件平台逻辑结构图：软硬件配置标准：序号项目描述1WebServer(2台)作为所有应用系统的WebServer，通过ApplicationCenter2000实现各应用系统的负载均衡及系统管理，其中一台为主控；或利用WindowsServer2003的NLB（NetworkLoadBalance）功能。最低硬件配置：2.0G*1CPU、1G内存、36G推荐硬件配置：2.8G*2CPU、2G内存、36G*2HD_Raid1软件：WindowsServer2003、ApplicationCenter2000（或利用WindowsServer2003的NLB－NetworkLoadBalance功能替代ApplicationCenter2000，但无推荐）2DBServer(1台)FileServer(1台)作为所有应用系统的数据库服务器及专门放置附件的文件服务器、数据放置于磁盘阵列最低硬件配置：DBServer2.8G*2CPU、2G内存、36GFileServer2.8G*2CPU、2G内存、36G推荐硬件配置：DBServer2.8G*4CPU、4G内存、36G*2HD_Raid1FileServer2.8G*4CPU、4G内存、36G*2HD_Raid1软件:WindowsServer2003Enterprise、SQLServer2000Enterprise3磁盘阵列(1台)作为数据库文件和附件存储空间推荐IBM的FAST600（配置根据现状和发展预测可灵活调整）4辅助应用服务器(1台)作为定时调度的系统服务运行平台最低硬件配置：2.0GCPU、512M内存、36G推荐硬件配置：2.8GCPU、1G内存、36G*2HD_Raid1软件:WindowsServer20035测试WebServer(1台)测试用WebServer硬件:2.0GCPU、1G内存、36G*2HD_Raid1。软件:WindowsServer20036测试DB/FileServer(1台)测试用DBServer和FileServer硬件:2.0GCPU、1G内存、36G*2HD_Raid1。软件:WindowsServer2003、SQLServer2000Enterprise7AD服务器测试用ADServer硬件:2.0GCPU、1G内存、36G*2HD_Raid1。软件:WindowsServer20038开发工具VisualStudio.Net2003注：上述配置仅仅是建议，具体部署时应与设备供应商、集成商商议确定，特别是在DB服务器、文件服务器和磁盘阵列方面。3.2.3软硬件平台技术特点由上面图表可以看出，综合应用管理系统硬件平台基本上是基于X86的PC服务器，软件平台基于微软windows平台和.Net技术。各部分采用的具体技术：web服务器：采用ApplicationCenter做负载均衡，通过横向扩充满足应用和用户增长的需要，同时也提高了系统的健壮性。数据库和文件服务器：采用WindowsServer2003的MSCS集群技术，实现双机热备。增强型配置辅助应用服务器：主要运行系统的后台服务程序；标准型配置可将后台服务程序放到WEBServer上。应用系统逻辑设计在构建综合应用管理系统解决方案时，不仅涉及到开发自定义软件，而且还涉及到将该软件部署到生产服务器环境中。为了以最优方式构造可高效满足解决方案要求的应用程序和技术基础结构，并且将软件结构映射到硬件结构，建议采用以下方案：● 按逻辑分层组织软件应用程序。● 优化逻辑分层方法以提供和使用服务。● 按物理级组织硬件以便扩展。● 优化三级配置中的物理层策略。图13.3.1三层服务应用程序分层应用程序在软件开发世界被广泛应用，这种实现定义了三个层：表示、业务和数据。虽然您可以添加更多层，但是对于综合应用管理系统上运行的管理支撑系统，目前几乎总是按三层结构来设计。图2三层服务应用程序上面所显示的三层服务应用程序基本上是一个松散的三层体系结构。三层分别是：● 表示。表示层提供应用程序的用户界面(UI)。这通常包括Windows窗体（用于智能客户端应用程序）和ASP.NET技术（用于基于浏览器的交互）的使用。● 业务。业务层实现应用程序的业务功能。该层通常由使用一种或多种支持.NET的编程语言实现的大量组件组成。这些组件可能为实现可伸缩的分布式组件解决方案而以Microsoft®.NETEnterpriseServices进行了扩充。● 数据。数据层提供对外部系统（如数据库）的访问。该层涉及到的主要.NET技术是ADO.NET。但是，在这里也经常用到一些.NETXML功能。通用组件除了三个标准层，三层服务应用程序还定义所有层都可以使用的一组通用组件。在综合应用管理系统中，这些服务包括：HR、协同办公、消息通知、集中授权、监控等。3.3.2三级分布基础结构分级分布按一组物理级来组织系统基础结构，以便提供针对特定操作要求和系统资源使用而优化的特定服务器环境。建议按三级组织解决方案服务器：客户端、Web应用程序和数据。客户端级和数据级的功能不言自明；Web应用程序级作为应用程序业务组件以及Web表示组件的宿主。对于具有更严格的安全性和操作要求的解决方案，您可能应该考虑将Web功能移到单独一级上。围绕三个物理级构造应用程序：客户端、应用程序和数据库。图3显示了此三级分布。图3客户端级客户端级与解决方案的用户交互。对于三层服务应用程序，该级将驻留表示层组件。应用程序级应用程序级中的服务器负责驻留应用程序的业务组件，以及Web服务器（在Web应用程序的情况下）。对于三层服务应用程序，该级将驻留业务层组件。数据级数据级中的服务器驻留了解决方案所需要的数据库。对于三层服务应用程序，该级将驻留数据层。3.3.3部署方案基于三层服务应用程序，目前已确定了几种常见的企业应用程序部署规划模型：简单Web应用程序、复杂Web应用程序、扩展企业应用程序以及智能客户端应用程序。现阶段综合应用管理系统采用简单Web应用程序模型。简单Web应用程序简单Web应用程序配置将所有组件部署到一个通用级。此配置（如下图所示）从理解上是复杂程度最低且最简单的配置。随着综合应用管理系统上应用数量和种类的不断增长，简单Web应用程序模型将不能满足应用需要，那时综合应用管理系统结构必须做相应的调整，以适应复杂Web应用程序、扩展企业应用程序以及智能客户端应用程序等部署规划模型。通用组件的结构与功能本章节讲述的组件是供运行于综合应用管理系统之上的管理支撑系统使用的基础设施应用组件，主要包括：目录同步组件、消息通知组件、集中授权组件、服务器监控组件、流程管理组件等。目录同步组件目录同步组件对各市分公司的人员、组织架构、领导分管信息等用户基础数据的管理。目录同步组件的约定前提为各市分公司人员（包括临时人员）通过人力资源管理系统同步到省公司统一信息平台的LDAPServer中。目录同步组件是统一信息平台LDAP用户数据库在各市公司的一个本地数据库副本，为市公司各管理支撑系统提供用户数据缓存区。下图为目录同步组件与其他部分的交互图。注：对于未在人力资源管理系统管辖范围之内的临时人员，在全省LDAPServer中注册，再同步到市公司目录同步组件。目录同步组件包括的模块有：HR同步服务：指各市分公司通过WindowsService的方式从省公司统一信息平台LDAPServer中获取最新的人力资源相关数据和逻辑关系，包括工作类型、职位级别、部门/室/营业厅的分层数据、所有人员相关数据。（具体数据结构参见《统一信息平台应用接入规范》）上述数据将作为综合应用管理系统向其他整合的应用系统提供基础用户数据的基础。领导分管信息定义：提供对组织架构各层（部门/室/厅）的分管领导的WEB界面设置功能，而对应的正职、副职则自动从同步的人力资源数据中获取到。这两方面的数据将作为公司内部的基本行政审批流程的指引数据。HR数据接口：通过WebService接口以二维表格方式向应用系统提供获取组织架构、人员、领导分管信息等数据，以便应用系统可以同步或获取相关数据。消息通知组件消息通知组件主要是在整个平台上提供统一的消息通知接口，减少重复投资，并利用移动公司的优势实现短消息移动办公。主要的模块有：短消息服务：以WindowsService的方式与短消息中心指定端口地址实现收、发短消息的功能，收发的策略要能支持对各个应用系统的短消息进行区分。（接入短信平台可以选择本地网关或省公司企信通平台，但个别业务逻辑需要上行功能。）邮件服务：以WindowsService的方式与指定邮件服务器实现发送邮件的功能。短消息服务接口：以WebService方式提供各个应用系统收、发短消息的接口。邮件服务接口：以WebService方式提供各个应用系统发送邮件的接口。典型应用如A提交请假B审核C批准，当A提交请假后，B收到新的待办工作，同时B收到短消息通知；B收到短消息通知后登录系统进行审核，C收到新的待办工作同时C收到含有概要数据的短消息，提示回复1即可自动审批；C用手机回复1后，应用系统通过短消息服务接口接收到回复的短消息，然后此申请单被自动批准。集中授权组件集中授权组件主要是用来对用户与应用系统之间的访问权限、对WebService接口的访问权限进行管理，并提供相关接口。主要包括的模块：应用系统用户角色管理：各应用系统的角色的应用访问权限在应用系统中设置，此组件可以获取各系统中存在的角色。系统管理员和各应用系统管理员可以在此组件中将用户分配到不同应用系统的各种角色中。用户所属的角色也就定义了用户在系统中拥有访问权限。系统拥有通用角色，即使在各系统中都具备的通用性高的角色，系统管理员设定只要设置用户所属的通用角色，各应用系统将继承用户所属的角色。而对个别用户的角色调整将由应用系统管理员进行操作。对用户有权限访问的应用系统，统一信息平台提供对应用系统的集成单点登录链接。应用系统访问权限接口：为各应用系统提供管理权限的WebService接口，用于提供各应用系统获取用户在某系统所属的角色。WebService访问权限管理：WebService是提供给各应用系统的接口，对其访问权限可以用数字证书方式或帐号限制方式。服务器监控组件服务器监控组件主要是对综合应用管理系统上的各服务器进行监控，监控的主要内容为CPU使用负荷、内存使用负荷、网络流量、磁盘空间等。各市公司可利用CA作为监控工具，也可以考虑采用其它监控工具，如MOM、Tivoli、MAX等，原则上应优先考虑采用已有的监控系统。流程管理组件（可选项）工作流是基于业务规则进行系列动作执行的自动化工作路线。流程管理组件体系分成三个层次：表现层、业务层、系统层，可以在WEB应用的表现层和业务层创建垂直的业务流程。申请表申请表+简单确认逻辑工作流定义业务逻辑内核+工作流引擎表现层业务层系统层客户化工作流逻辑流程管理组件主要由下面几个模块组成：流程引擎：管理和执行工作流流转。负责创建新的工作流，确定流程每一步执行的动作，确定流程每一步的执行人（角色），实现自动化流程的流转。 流程定义工具：定制业务流程，用于绘制、定义业务流程，管理路线、执行动作、活动，设置每个步骤和执行动作的属性，定义流程处理用户等。操作应简便、界面可视直观。 表单设计工具：建立工作流信息表单以存放工作流数据，并绘制展示数据的用户界面。表单设计工具用户界面友好的。 管理工具：核心的工作流管理组件，用于上载修改定义好的工作流和组织结构到系统。系统性能要求应用程序和服务需要以下的运行（非功能性的）要求。这些要求包括应用程序必须达到的可缩放性、可用性、维护性、安全性和易管理性级别。这些要求可能会影响应用程序策略的设计，但它们还会影响应用程序逻辑的设计方法。在某些情况下，很难做到既符合某些运行要求，又符合其他的运行要求。例如，通常降低应用程序的易管理性有助于提高安全性。重要的是，一定要在生命周期早期分清支持运行要求的应用程序功能的轻重缓急，以便从一开始就在应用程序实施中考虑到这些利弊权衡和决策。可缩放性应用程序的可缩放性是指，在增加一个或多个加载因子时，应用程序能否提供一个可接受的总体性能水平。常见的加载因子包括用户数量、应用程序管理的数据量以及事务数量。可以按照吞吐量和响应时间来测量总体性能。吞吐量测量应用程序在给定时间内执行的操作数量；响应时间测量用户或进程发出请求和收到请求结果之间间隔的时间。有很多因素影响吞吐量和响应时间，其中包括硬件性能、物理资源（如内存）、网络延迟（通过网络链路传输数据所花的时间）以及应用程序设计。虽然可以通过增加硬件资源来解决很多性能和可缩放性问题，但如果设计的应用程序不能有效运行，则无论为解决问题投入了多少硬件，应用程序几乎始终具有很差的性能。对于高可缩放性应用程序，请考虑以下设计原则：● 使用异步操作。通过使用异步操作来降低响应时间和吞吐量要求。同步操作要求用户一直等到业务操作完成时为止。通过将业务操作变为异步操作，可以更快地将系统控制交还给用户，并将处理请求放在队列中排队，这样有助于控制吞吐量要求，而不会出现业务组件应付不过来的情况。例如，假定用户在电子商务站点下一个订单。如果订购过程是同步执行的，则用户必须等到已验证信用卡并从供应商订购了物品后，才能开始接收确认。如果异步实施订购过程，则可以在操作完成后通过电子邮件给用户发送确认或失败消息。设计异步应用程序增加了开发人员的工作量（尤其是当他们需要事务逻辑时），但可以大大提高可缩放性。● 在需要数据的地方高速缓存数据。如有可能，应该在需要数据的地方高速缓存数据，这可最大限度地减少对数据存储的远程数据请求的数量。例如，对于前面介绍的电子商务站点，如果将产品数据缓存在Web站点中，而不是每次用户查看产品列表时都从数据库中进行检索，则该站点就会具有高得多的可缩放性级别。● 避免保存多余的状态。如有可能，应该将操作设计为无状态的操作。这样做可防止资源争用，提高数据一致性，并且可以在场中的多个服务器之间分摊请求负载。在某些情况下，需要永久性地保存状态，例如，在HTTP请求中必须存储客户的购物车。在这些方案中，必须谨慎地规划状态永久性和状态释放逻辑。仅当实际需要时，才应该释放状态（例如，当用户要查看其购物车或签出时）。● 避免出现资源争用。有些资源（如数据库连接）是很有限的，而有些资源（如数据库锁定）是独占使用的。应用程序设计应该体现以下原则：应该尽可能缩短保留资源的时间。应该有效地使用数据库连接池，并且应该将操作设计为最后打开竞争最激烈的资源（以便没有在整个操作中保留该资源）。在使用原子事务时，这是尤其正确的。例如，如果很多应用程序部分都使用数据库的订单表，则应该将订单数据插入作为订购过程的最后一步，以免在等待信用卡验证时保持对该表的锁定。● 划分数据、资源和操作。可以使用负载平衡技术（如NetworkLoadBalancing）在服务器场中分摊应用程序负载。这样，就可以采用“扩展”策略，仅通过在场中添加更多的服务器来提高可缩放性。通常，扩展比升级（通过给服务器添加硬件资源）更划算。应该主要通过添加硬件资源来升级数据库，但也可以通过在多个数据库服务器之间划分数据库来扩展数据，使每个服务器仅负责处理一部分数据。在中间层使用动态数据路由逻辑将请求发送到相应的数据库服务器。有关划分SQLServer数据库的详细信息，请参阅MSDN上的“InternetDataCenterReferenceArchitectureGuide”第5章“SQLServerDatabaseDesign”可用性可用性测量应用程序能够按调用者期望的方式响应请求的时间百分比。人们普遍接受以下事实：即使最可靠的应用程序偶尔也会无法使用，但在设计应用程序时，应最大限度地降低出现意外故障的风险。对于业务关键的应用程序，很多企业将目标定在“3个9”或99.9%可用性，要达到这种可靠性级别，必须仔细地进行规划和设计。请考虑应用程序设计的以下高可用性策略：● 避免出现单个故障点。在应用程序设计和部署基础结构中，应该避免仅使用任何单个组件（如果将该组件脱机，就会导致应用程序无法使用）。可通过使用负载平衡管理软件（如MicrosoftApplicationCenter提供的软件）来避免在Web场或应用程序场中出现单个故障点，这种软件从负载平衡的场中删除不响应的服务器，而不会中断其余服务器的操作。应该将业务数据存储在故障转移群集上部署的数据存储（如数据库或队列）中，这样，如果控制数据存储的服务器由于某些原因出现故障，应用程序就会“故障转移”到备用服务器。还应该提供冗余的数据路径，以便提供多个到数据库服务器的物理网络路径，这样，在出现网络电缆故障时，应用程序仍能继续正常工作。为防止应用程序出现硬盘故障，应该采取磁盘冗余措施，如廉价磁盘冗余阵列(RAID)技术。● 使用高速缓存和队列最大限度地降低“相同时间和地点”要求。通过在需要数据的地方高速缓存只读引用数据，不仅可以提供更高的可缩放性，而且它还降低对基本数据存储的依赖性。在数据库无法使用时，应用程序可以继续正常工作，因为数据仍在高速缓存中。类似地，通过将请求放在队列中以插入或更新数据，在基本数据源和服务无法使用时，应用程序仍能处理客户端请求。这样，电子商务企业就可以继续接收订单，即使无法立即将订单数据写入到数据库中，也是如此。● 规划一个有效的备份策略。无论是否采用了高可用性措施，必须确保已制订了一个有效的备份策略，以便最大限度地减少在出现灾难性故障时将系统恢复到正常工作状态所需的时间。● 严格地测试和调试代码。当然，应该始终测试和调试代码，但如果要求提供高可用性，则尤其要确保消除可能使应用程序出现故障或停止响应的任何潜在的死循环、内存泄漏或未处理的异常。维护性就维护性而言，应用程序设计和部署应该体现以下原则：可以方便地维护和修复应用程序。在设计可维护的应用程序时，应考虑以下建议：● 以可预测的方式组织代码。通过在应用程序中使用统一的编码技术，可以简化应用程序的维护工作。应该对命名空间、变量、类和常量名称使用标准化的约定，并使用一致的数组界限和内嵌注释。● 隔离经常变化的数据和行为。将经常变化的逻辑和数据封装到单独的组件中，可以独立于应用程序的其他部分对这些组件进行更新。● 对配置和程序参数使用元数据。通过将应用程序配置数据（如连接字符串和环境变量）存储在外部元数据库（如XML配置文件）中，可以在生产环境中方便地更改这些值，而无需编辑或重新编译应用程序。有关使用元数据（描述数据及其环境的数据）的详细信息，请参阅第3章“安全性、运行管理和通讯策略”中的“设计通讯策略”。● 使用可插入的类型。如果可以使用多种方法来实施某个应用程序逻辑部分，则定义一个接口并让应用程序加载在运行时实施该接口的相应类是非常有用的。这样，就可以在部署应用程序后“插入”实施该接口的其他组件，而无需对它进行修改。可以将完全限定的类型名称存储在配置存储中，并在运行时使用它们实例化对象。在使用这种方法时，必须确保已对配置存储进行相应的保护，以防攻击者强制应用程序使用他或她自己设计的组件。● 接口设计。对组件接口进行设计，使所有公用属性和方法参数具有相同的类型。通过使用相同的类型，可以减少组件及其使用者之间的相关性。安全性在设计应用程序时安全性始终是一个主要的考虑事项，尤其是可以通过Web访问应用程序时。安全性决策在很大程度上取决于安全策略。无论安全策略的具体细节是什么，都应该始终考虑以下建议：● 评估风险。在应用程序设计期间，花一些时间评估每个实施或部署决策所带来的风险。切记，要考虑内部风险以及外部黑客造成的风险。例如，可以使用安全HTTP连接来防止客户信用卡号码在通过Internet传输到站点的过程中被“窃取”，但是，如果随后将信用卡号码以纯文本的形式存储在数据库中，则未经授权的员工就有可能会非法获取该号码。● 应用“最少权限”原则。最少权限原则是一个标准的安全性设计策略，可确保每个用户帐户“有且仅有”执行其必要任务所需的权限级别。例如，如果应用程序需要读取文件中的数据，则应该给它使用的用户帐户分配读取权限，而不是修改或完全控制。不应给帐户分配多余的权限。● 在每个安全区域的边界执行身份验证检查。应该始终在“入口处”执行身份验证。在确定有效的身份之前，不应允许用户进程在给定安全区域中执行任何任务。● 仔细考虑用户上下文在异步业务过程中的作用。切记，在应用程序异步执行业务任务时，用户上下文的意义比同步执行任务要小。应该考虑对异步操作使用“受信任的服务器”模型，而不是使用模拟/委派方法。易管理性企业运行管理策略决定了需要管理的应用程序的特征。应该在应用程序中设计规范，以便公开运行状况监视、服务级别协议(SLA)验证和容量规划所需的关键管理信息。操作管理策略涉及应用程序每时每刻的运行，并涵盖如异常管理、监视、业务监视、元数据、配置和服务位置等问题，如图5.1所示。图5.1操作管理策略的各个方面5.5.1异常管理异常管理包括捕捉和引发异常、设计异常、传递异常信息以及向不同的用户发布异常信息。所有应用程序都应实现某种类型的异常处理来捕捉运行时错误。如果可能，应捕捉并纠正异常。如果无法纠正错误状态，应用程序应为用户显示有用的消息，并出于调试目的提供某种记录或发布异常信息的方法。异常管理功能包括：捕捉和引发异常设计异常类传递异常信息发布异常信息用户界面组件中的异常管理业务进程组件中的异常管理数据访问组件中的异常管理业务实体组件中的异常管理注意：有关在基于.NET的应用程序中处理异常的详细信息，请参见MSDN上的“ExceptionManagement”（异常管理）。有关Microsoft提供的、实现大纲设计的异常管理参考生成块，请参见MSDN上的“ExceptionManagementApplicationBlockfor.NET”（.NET异常管理应用程序块）。5.5.2监视需要规范应用程序，使操作人员可以观察应用程序的运行状况、服务级别协议(SLA)遵从性和伸缩/容量管理。有关如何规范应用程序的详细准则，请参见MSDN上的“Monitoringin.NETDistributedApplicationDesign”（.NET分布式应用程序设计中的监视）。应用程序可以从以下监视类型中获益：运行状况监视：组件运行正常吗？是否有暂时的锁定、挂起、进程退出、被阻塞的队列等？SLA遵从性：业务进程是否在要求的参数内运行？集成的服务是否满足预期要求？应用程序或服务是否满足调用方的性能和运转要求？伸缩管理：是否为组件处理的任务正确设计了用来部署组件的计算机、场或网络？是否能从可用的资源预测性能？业务监视：是否能使业务进程更加高效？是否能更早地做出重要决定？企业高效业务处理的瓶颈是什么？通过监视应用程序或服务的正确部分，可以回答这些不同的问题。并非所有的监视类型任何时候都需要处于活动状态。例如，可以决定在计划应用程序的下一个版本之前监视业务因素。监视功能包括：业务监视用户进程组件中的监视业务进程组件和工作流程中的监视数据访问组件中的监视5.5.3配置应用程序需要配置数据才能在技术上运行。修改策略行为（安全、操作管理和通信）的设置被认为是配置数据。配置数据在用户级、计算机级和应用程序级的.NET配置文件中维护。此处存储的自定义配置可以用任何架构定义，并且可以使用应用程序中的ConfigurationSettings类轻松访问。考虑配置安全敏感性非常重要，例如不要将SQL连接字符串以明文形式存储在XML配置文件中，特别当它们包含SQL凭据时。应该仅限适当的操作员访问安全信息，并且为了增加安全性，可以考虑给信息加上数字签名以确保配置数据未被篡改。配置数据可以存储在许多位置，每个位置都有自己的优点和缺点：应用程序XML配置文件：在此处存储配置数据使应用程序客户端可以离线工作，并且此模型容易实现。对于胖客户端应用程序，此方法可能会提高更改管理成本，因为它要求所有客户端具有相同的配置信息。在服务器环境中，使用ApplicationCenter服务器或MicrosoftActiveDirectory目录服务，或通过复制批文件，可以很容易地推送配置更改。注意重新加载应用程序配置数据需要重新启动AppDomain。不过，如果ASP.NET检测到配置文件中有更改，它会重新启动AppDomain。应用程序配置文件用纯文本格式存储，这可能是不能接受的安全风险。例如，在大多数方案中，不要在应用程序配置文件中存储包含用户名和密码的连接字符串。SQLServer或应用程序数据存储：这是应用程序托管配置数据的常见存储位置，但是对于应用程序元数据而言，甚至还有更多的存储位置。如果在此处存储配置，建议将元数据和业务数据分别保存在不同的SQLServer数据库中。访问数据库通常会影响性能，因此应考虑缓存数据。ActiveDirectory：在组织内部，可以决定将应用程序元数据存储在ActiveDirectory中。这样可使域上的客户端能够使用元数据。还可以使用WindowsACL保护ActiveDirectory中的信息，确保只有授权用户和服务帐户可以访问这些信息。构造函数字符串：如果使用基于EnterpriseServices的组件，可以将配置数据添加到组件的构造函数字符串中。用于特殊情况的其他位置：这些位置包括WindowsRegistry、WindowsLocalSecurityAuthority(LSA)存储和自定义实现。它们用于非常特殊的情况，对于计算机和部署机制有额外的应用程序特权要求。可能也提供版本控制和部署功能的第三方配置管理解决方案。频繁访问配置数据和元数据可能会影响性能，特别是当远程存储数据时。为了防止影响性能，可以在内存中缓存应用程序托管配置数据和元数据。但是，需要确保没有增加安全漏洞，未向错误的应用程序代码公开敏感信息。如果缓存配置数据，最好指定刷新速率和频率，在预设的时间刷新缓存的数据，而不是在相对时间间隔（例如，强迫配置缓存整点刷新，而不是“上次刷新后一小时”）刷新缓存的数据。这有助于操作员在特定的时刻及时了解应用程序所基于的配置数据。表示层中的配置用户进程组件通常需要以下配置设置：到达业务进程组件和数据访问组件的位置信息。资源的连接数据（例如，连接字符串或文件路径），这些资源处理保持长期运行的进程的用户进程数据。服务代理中的配置为使用Web服务、消息队列或其他一些方式连接到外部服务，服务代理需要配置信息。配置架构和数据取决于所访问的具体服务。数据访问组件中的配置数据访问组件通常需要以下信息：它们需要具有将逻辑数据源名称映射到物理连接参数（例如，将“销售”数据库映射到实际的连接字符串）的能力。如果数据访问组件执行动态数据路由，需要有配置数据来表示路由参数（例如，客户区域）、算法（例如，散列算法）和路由目标（例如，数据库的连接字符串）。通常在一个单独的实用程序组件中打包动态数据路由逻辑。5.5.4元数据要使应用程序更容易更改运行时条件，可能需要提供有关应用程序本身的信息。将应用程序设计为在某些特定位置使用元数据，可以使应用程序更容易维护并且能够适应更改，而无须付出很大代价进行再开发或部署。可在以下两个主要时期内在应用程序中使用元数据：设计时：例如，可以使用有关数据库的信息生成代码、存储过程、.NET类、甚至是经常重复的模式的用户界面组件。在开发过程中使用元数据可以节省反应开发时间、减少团队之间的通信需要、集中和“保持”专门的技能，而且可以加强设计、命名和实现标准。这样，生成的组件的行为更容易预测，而且不容易出错，因此可以提高开发人员的工作效率。不过，这种方法要求有专门的知识，还需要额外的开发工作来创建模板和组合模板与元数据的代码。运行时：如果对应用程序中经常更改的地方使用适当的元数据，应用程序可能更容易维护。例如，可以决定从元数据中提取用户界面列表或网格的标头，从而无须在应用程序中对它们进行硬编码。在建立组件之间的关系或处理可预测模式（如验证规则）时，应用程序也可以利用元数据。不过，就性能而言，在运行时使用元数据的开销通常是很大的，因此，应该在应用程序生命周期的早期测试和配置应用程序设计。可以设计组件公开有关它们自身的元数据，但仅当应用程序打算使用这些数据时才应该这样做；否则，元数据可能会成为安全漏洞。在运行时使用元数据时，使用高级技术可以避免性能问题，例如在应用程序正在运行时使用.NET映像类随时生成代码并进行编译。这种设计方法很复杂，由于它所需要的技能和运行时代码编译及元数据存储的安全问题，建议仅在最复杂的情况下使用。在大多数情况下，用.NET脚本可以很容易地实现运行时自定义。有关.NET脚本的更多信息，请参阅MSDN上的“ScriptHappens.NET”如前面“配置”中论述的那样，元数据可以存储在多个位置。对于集中式存储，可以使用SQLServer数据库或ActiveDirectory。如果要沿程序集分布元数据，可以在XML文件中实现此操作，甚至可以自定义.NET属性。性能要获得较好的用户体验和有效地利用硬件，应用程序和服务性能是至关重要的。虽然可以在系统建立后通过优化系统实施和代码来提高性能，但一定要在体系结构和设计阶段就考虑到性能问题。可能要在应用程序原型确定、开发、测试等不同阶段中执行这一过程，以确保达到性能目标或及早调整预期目标：1. 为特定操作定义可测量的性能要求（例如，在一定利用率下的吞吐量和/或延迟，如“在特定的硬件配置下，平均CPU使用率为70%时为50个请求/秒”）。2. 进行性能测试：对系统进行负载测试并搜集配置信息。3. 分析测试结果：应用程序是否达到性能目标？4. 如果应用程序没有达到性能目标，确定应用程序中的瓶颈。（有关用于确定性能瓶颈的工具，请参阅此列表结尾引用的文章。）系统外延要求与广东移动统一信息平台（门户）的整合要求建立新的管理支撑系统时，应与广东移动统一信息平台整合。统一信息平台的整合作用主要包括以下方面：统一用户管理平台：统一信息平台作为统一用户管理平台，管理着全公司最完整的用户信息。它的数据来源是公司人力资源管理系统，因此信息更新及时、唯一。统一信息平台再把用户信息同步给其他应用系统，如综合应用管理系统。向综合应用管理系统的用户信息同步，主要是同步给目录同步组件，可参加本规范第4章“组件的结构与功能”的相关章节。同步接口的详细信息，请参见《广东移动统一信息平台应用接入规范》。统一认证平台：统一信息平台作为统一认证平台，为其他应用系统提供了统一的认证服务。这种认证服务体现为以下两种方式，具体的接口信息请参见《广东移动统一信息平台应用接入规范》。单点登录（SSO）：用户访问统一信息平台后，可以直接访问其他应用系统而不需要再次登录（即实现了单点登录功能），如综合应用管理系统。认证服务：用户登录应用系统时，如综合应用管理系统，不在应用系统本地做认证，而是将认证功能重定向到统一信息平台（调用统一信息平台提供的相应接口，如webservice接口），认证通过后返回确认信息。统一信息展示平台：统一信息平台作为统一的信息展示平台，将多个系统中的关键信息展示在统一的界面上（典型应用如待办工作的统一展示），提高办公效率。为此，统一信息平台提供了相应的接口方式，如webservice接口方式、Portlet封装方式等。具体的接口信息请参见《广东移动统一信息平台应用接入规范》。用户管理按照“人力资源管理系统统一信息平台各应用系统”的顺序规则进行用户信息管理，人力资源系统中的数据架构格式（如工作类型、职位级别等）应能反映到各系统中。数据共享：用户数据依赖人力资源系统LDAPServer目录同步组件各管理支撑系统来实现共享。全省各分公司在使用人力资源系统时管理分公司的人员数据时都与统一信息平台的LDAPServer实现了同步，而各市公司综合应用管理系统上的目录同步组件从LDAPServer上同步本分公司的人员数据作为本地的用户数据，并提供WebService接口给其他应用系统获取本地用户数据。用户认证：用户的认证建议由省公司统一提供，并与单点登录功能结合，以便特殊应用系统可以在统一的认证模式下实现自定义的单点登录。用户命名规范：综合应用管理系统只是同步已生成的用户数据，创建用户由统一信息平台负责，用户命名规范参见省公司统一信息平台相关规范。网络环境根据中国移动集团公司《中国移动网络与信息安全标准NISS》及省公司网络部制定的《网络与信息安全管理体系》要求，综合应用管理系统必须同步进行网络安全建设，并符合有关设备接入要求。综合应用管理系统网络和安全必须纳入企业信息网整体的信息安全防护体系，并按照“谁主管、谁负责”的原则，落实有关责任人员，建立专项系统维护和安全管理制度。本系统所有服务器应运行在MDCN网络上，广东移动和各市公司各种应用系统运行于一个局域网中，省公司和各市公司之间的网络通信速度快、可靠性高。客户端应支持IE5.0以上；网络间的资源访问应该基于80端口，如文件上传下载、WebService等；所有应用系统应采取B/S结构。系统实施和运维要求综合应用管理系统建成后，为应用系统建设运行提供了很好的基础，平台上承载的应用系统一定会越来越多。而这么多应用系统建设一般会涉及到多家开发商，而且系统建设维护人员一般也不止一个。要协调好各方的操作，保证综合应用管理系统能够正常运行，就必须从开发规范、测试上载方法和系统维护管理等方面提出严格的系统实施和运维要求。开发规范由于综合应用管理系统的生产服务器上面会有多个不同开发商开发的应用系统，为了要保证开发商开发的应用能够不对其他系统构成影响，使得各个系统能够在统一的平台上面顺利运行，各个开发商都必须遵从统一的应用系统开发规范。（详见《综合应用管理系统开发规范》）运行维护7.2.1应用系统的开发测试所用应用系统的开发测试，都在测试服务器上完成。测试服务器具有跟生产服务器相同的.netFramework软件环境，以及相关应用系统。因此，在测试服务器上完全可以模拟实际的生产环境，对不同应用系统之间的兼容性等进行测试、对系统的整体性能等进行测试。在开发测试阶段，测试服务器只提供了We