《GMCC综合应用管理系技术规范.docx》由会员分享，可在线阅读，更多相关《GMCC综合应用管理系技术规范.docx（36页珍藏版）》请在三一办公上搜索。
1、 市公司综合应用管理系统技术规范文件编号：密级：项目ID：总页数：共 37 页项目名称:综合应用管理系统（IAMS）技术规范 版本 拟制日期审核日期批准日期声 明本文档所有权和解释权归广东移动通信有限责任公司及其下属市公司所有，未经书面许可，不得复制或向第三方公开。This document is the property of GMCC and its branches and can be neither reproduced nor disclosed to a third party without a written authorization.修订历史记录版本日期AMD修订者说明（
2、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三层服务应用程
3、序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 应用系统的开发测
4、试347.2.2 应用系统的实施部署347.2.3 系统维护管理347.2.4 系统安全管理347.2.5 数据备份357.2.6 应急处理方案358.知识产权及保密要求371. 文档介绍1.1 文档目的编制本文档主要用来为广东移动各市公司各种管理支撑系统（业务支撑系统除外，下同，应有系统与此同义）提供统一的硬软件平台（以下简称“综合应用管理系统”）和运行于综合应用管理系统之上的各管理支撑系统开发提供指导性规范与建议；协助有需要的各市公司早日构筑符合各自需要的综合应用管理系统；保障开发商规范、统一和高效地整合已有和开发新建应用系统到综合应用管理系统；实现应用系统和综合应用管理系统各基础子系统与
5、省公司统一信息门户的无缝集成。1.2 文档范围文档介绍了综合应用管理系统以及各通用组件的总体情况，详细介绍了综合应用管理系统的软硬件结构、软硬件平台上提供各应用系统使用的通用组件的功能和接口、以及和统一信息门户整合的接口规范。在这基础上，给出了运行于综合应用管理系统上应用系统的开发要求和规范，为开发商的系统实现工作提供指导，同时也为平台建设维护者提供原理性指导。1.3 读者对象 移动公司IT技术人员； 移动公司IT系统建设规划人员； 移动公司IT系统维护人员 第三方开发商1.4 参考文献1.5 术语与缩写解释缩写、术语解 释IAMSIntegrated Application Manageme
6、nt System，综合应用管理系统统一信息平台广东移动集门户系统、统一用户管理和EAI一体的平台系统EAI企业应用集成，Enterprise Application IntegrationLDAP轻量级目录访问协议，Lightweight Directory Access ProtocolAD活动目录，Active DirectorySSO单点登录，Single Sign On2. 系统概述综合应用管理系统是广东移动市公司管理支撑系统集中运行的硬件环境和系统软件环境的统一平台，提供了各支撑系统使用的通用系统模块，主要包括统一用户管理、统一提醒通知、系统监控、基础通信设施等（通用模块将在实践过
7、程中不断积累扩充），并规定了在这个平台上运行的各应用系统的设计实现要求，只要符合技术规范的应用系统都可以方便地接入到平台中。2.1 现状随着公司计算机应用水平的不断提高，公司内部各职能部门和生产中心新建的中小规模应用系统正不断增多。这些兴建的应用系统：第一、在技术选型、软件架构、软硬件平台上各不相同，直接造成了系统管理维护上的诸多不便。第二，由于各应用系统需要单独进行技术选型，购置软硬件设备，造成了系统总体成本相当程度的浪费。第三，各应用系统由于没有统一规划，各自建造，导致很多系统模块重复建设，数据重复保存、版本不一，信息无法统一管理共享利用等等。总之，根据公司现有IT资源配置情况，开发周期无
8、法满足开发需求的要求、系统整体价格居高不下、维护工作疲于应付、各个系统相对独立形成信息孤岛。2.2 目标为了对市公司中小应用系统进行更好的统一规划、统一建设、统一管理，应建设一个公司级管理支撑系统运行的软硬件平台，选用统一通用的软件体系结构，并形成相应的管理制度和技术规范，指导和规范各公司相关管理支撑系统工作者和开发商的系统建设、运行和维护。此平台的体系架构、系统规模、系统性能自具有良好可扩张性的前提下，满足市公司今后近3年应用系统的发展需求，因此必须结合各公司的实际情况，有计划、分步骤的实施，以求建成一个： 用户需求响应快 系统成本低 维护质量高 资源利用率高 信息共享程度高的市公司级的管理
9、支撑系统综合开发、测试和应用的综合平台，为应用系统建设管理提供一个良好的基础。2.3 差距分析2.3.1 用户需求响应时间的差距对于各部门的“短平快”（时间短、价格平、响应快）管理支撑系统开发需求，在现有公司资源配置情况下，除部分小项目可以在规定时间内自主开发外，其它需求几乎无法满足需求者的时限要求，通过建设综合应用管理系统，可以使我们减少技术选型、软硬件平台采购和安装调试等环节，还可有效缩短测试上载时间，进而达到缩短响应时间的目的。2.3.2系统成本的差距综合应用管理系统中将采用适宜的体系结构。综合应用管理系统的引入，使得各应用系统不需单独进行技术选型、软硬件购置、培训和维护，使得应用系统总
10、体成本得到有效控制，在第三方软件和维护成本的降低方面，效果尤其明显。2.3.3 维护质量的差距目前各系统使用技术各不相同、物理位置分布公司各处，维护成本非常高。采用综合应用管理系统后，在一定的约束条件下，由于采取的体系结构、软硬件环境等基本相同，从而不仅降低了管理、维护的难度和工作量，而且由于应用平台本身提供了相应的数据备份、数据容错机制，相应提高了系统的可靠性、稳定性和安全性。2.3.4 资源利用率的差距离散应用系统使用各自的软硬件设备，不能做到充分利用。通过对综合应用管理系统的体系结构、软硬件平台的认真规划，可以在保证系统的安全性、通用性、可靠性、可扩展性的前提下，大大提高硬件、软件、机架
11、、端口等资源的利用率，以达到集约经营的目的。2.3.5企业应用集成水平的差距如果沿用过去应用系统的开发、管理、维护模式，由于不同应用系统各自采用了不同的软件架构、不同的认证方式、不同的软硬件平台，使将来实施EAI工作变动十分困难。综合应用管理系统将使这些应用系统的移植简便易行。2.4 发展建议现阶段，广东移动处于集约发展阶段，各市公司业务扩展速度非常快。为更好地支持这种业务增长，各市公司根据自身地特点提出了很多满足个性化需求应用系统。这些需求没必要也很难由省公司或集团公司统一实现，但不统一规划集中管理，以后集成的难度更大。先规范各市公司的系统建设，把分散在多处的各种管理支撑系统统一到一个平台上
12、面，并不断总结建设经验，是集团公司统一信息化建设进程的一个必要步骤。而各市公司管理支撑系统建设中存在开发周期无法满足开发需求、系统整体价格居高不下、维护工作疲于应付、各个系统相对独立形成信息孤岛等也是急待解决的问题。在这种背景下，经过广泛调研，我们认为建设一个公司级的应用系统综合开发、测试和应用平台（以下简称综合应用管理系统）是加强集中化管理、提高服务水平、降低系统成本、改善系统管理和维护质量的有效途径。现阶段各市公司提出管理支撑系统的需求，总的要求是“短平快”，基本特征是数据库、简单流程、访问量和集中度并不高，这些都可以在综合应用管理系统上得到很好的满足。对业务量较小的、本身不具备建设综合应
13、用管理系统的人力物力的公司，可考虑由应用系统建设在邻近区域中心，由区域中心提供相应的系统平台资源。下图是综合应用管理系统的逻辑结构图：硬 件 平 台软 件 平 台通 用 组 件系统1系统2系统3系统n综合应用管理系统硬件环境采用基于X86的PC服务器，软件环境采用微软windows平台和.Net技术。X86的PC服务器具有很高的性价比，升级扩容方便，通过采用横向扩充技术可以满足未来性能上需要。Windows平台在提供了强大的服务器功能的同时，相对简单易用，这大大降低平台的开发维护成本。.NET技术是综合应用管理系统的核心技术，该软件体系结构： 1、 提供强大的平台基础设施。Windows Se
14、rver系列，.NET Framework等提供了构建和运行平台系统的基础设施。2、 提供多样的通用组件。一组用于企业内部网络的信息共享服务，如Active Directory (用于用户身份验证)，以及用于文件存储、用户偏好管理、日历管理的服务等.NET服务，为企业应用建设提供了多样的基础通用服务。3、 提供对XML Web service技术的全面支持。通过XML Web service技术可以方便企业内部各个系统之间进行无缝的连接，各种系统可以互相通信，互相作用，从而实现整个企业的协同运作。4、 通过配合Microsoft Windows System其他部件，如SQL Server，b
15、iztalk Server，Commerce Server，Application Center等，可以有效较快企业集成的速度，降低企业集成的难度。5、 提供了多种访问方式。用户可以通过各种方式、在各种不同设备上方便地获取自己想要的信息。6、 提供强大的开发工具。Visual Studio.NET等开发工具通过友好的界面大大降低了开发工作的负责性，有效降低了系统开发的人力成本。.NET体系是已经被证明了、适合公司中小规模应用系统的、成熟的软件结构。综合应用管理系统包括生产和测试两部分。生产部分应通过负载均衡技术和集群技术保证平台的可扩展性和健壮性。测试部分在软件环境上完全模拟生产环境进行应用的
16、功能性能测试，以达到保证生产系统的正确性。综合应用管理系统的建设，希望达到以下目标：1、 提供管理支持系统运行的统一硬件环境，具有良好的可扩展性，实现后续应用的快速实施2、 提供管理支持系统运行的统一软件环境，软件架构具有一定先进性，至少可以满足未来至少三年的发展需要3、 提供管理支持系统共享使用的通用组件，各系统可以在此基础上进行信息交互，并减少不必要的重复建设4、 提供管理支持系统建设的管理制度和技术规范，指导不同开发商系统建设，使不同系统在综合应用管理系统上稳定运行随着平台的进一步发展，平台应沿着不断加强通用基础设施的建设方向发展，提供消息服务、安全服务、组织目录服务、归档服务功能，搭建
17、应用底层通用平台，逐步实现企业应用集成。2.5 成功案例深圳公司于2002年4月建成的综合应用管理系统，经过先后两次的升级扩容，现已成为一个包含用户管理、单点认证、办公协作、统一信息展现、消息通知、集中授权、系统监控等通用基础设施、其上运行接近20个管理支撑系统的平台系统。深圳公司综合应用管理系统基本上按照上述的4层架构模式搭建的。作为顶层各管理支撑系统共同使用的下面三层的具体结构功能将在后面章节具体描述。对于顶层的各管理支撑系统，平台并没有对其业务进行硬性规定，只要符合技术规范的各种系统都可以方便的接入到平台中，广泛地使用平台提供地各种通用组件。下面简单介绍一下深圳公司综合应用管理系统上管理
18、支撑系统的各种应用：深圳公司综合应用管理系统上运行着文档管理系统、合同/预算/核算管理系统、部门门户网站等建成系统，有等系统正在建设中，还和OA、HR、CS110等系统成功地进行了异构集成，最后通过门户实现集中认证、协同办公和统一信息展现。门户系统：实现了各种信息的集中展现和各应用系统待办待阅工作统一处理的入口，也是各应用系统的一个统一接入点。文档管理系统：负责公司内部文档的科学管理，分目录、按权限实现文档共享。方便用户文档存放、管理、搜索。合同/预算/核算管理系统：实现了“投资立项-合同签订-预算报帐-项目核算”的财务闭环管理。在线考试系统：实现统一管理题库、自动组卷、自动判卷，最终达到对考
19、试、培训、学习的高效管理。服务营销信息广场：支撑营业厅一线管理工作，担负信息共享、申报审批、辅助业务等功能。办公设备管理信息系统：专门针对我公司的所有办公设备从其入库到报废过程中发生的全部信息进行记录和反映、实现流程闭环管理。后勤门户网站：包含车辆调度与管理、物料供应、物业和内勤服务与管理等部分，为员工工作生活提供了有力的保障。休闲特区：包括BBS、电影、音乐等网站，丰富员工的工作生活。随着公司信息化建设发展，综合应用管理系统的应用范围和规模不断扩大，并形成了一种用户部门提出业务需求，信息技术中心充分利用平台资源，统一规划建设各管理支撑系统的良好局面。3. 系统总体结构本章介绍了综合应用管理系
20、统总体结构以及和统一信息平台的关系，并根据市公司规模给出了不同的综合应用管理系统软硬件配置方案，最后给出了综合应用管理系统上管理支撑系统的设计逻辑，从总体上指导综合应用管理系统以及其上运行的管理支撑系统的建设。3.1 系统总体结构下面是综合应用管理系统的系统架构图：综合应用管理系统的系统总体结构可以划分为四部分：硬件平台、软件平台、通用组件以及运行于平台上面的各应用系统。 硬件平台：提供了承载系统的服务器以及连接各服务器的网络环境。 软件平台：提供了操作系统、数据库、负载均衡（Application Center）、Internet信息服务、活动目录等系统软件。提供了一个应用程序运行的基础软件
21、环境。 通用组件：将综合应用管理系统上一些通用基础的功能封装成一系列功能相对独立的组件，现包括目录同步、消息通知、集中授权、监控等通用功能，并以组件的形式实现。（各子系统详细描述见第4部分“通用组件的结构与功能”）通用组件会随着平台的发展逐步抽象扩充。 应用系统：运行于软硬件平台之上，利用综合应用管理系统通用组件设施提供的通用功能，实现用户部门提出的具体业务需求的应用系统。综合应用管理系统四个部分构成了一个整体，但还必须和广东移动统一信息平台进行整合，以实现统一信息展现、单点登录和用户数据管理等。（详见6.1“与广东移动统一信息平台的整合要求”）3.2 系统软硬件平台逻辑结构及配置综合应用管理
22、系统的体系架构、系统规模、系统性能必须能够满足公司今后近3年应用系统的发展需求，因此在建设综合应用管理系统的时候必须结合公司的实际情况，有计划、分步骤的实施。各市公司综合应用管理系统的软硬件平台结构基本一致，但由于各公司应用规模等情况有所区别，所以系统具体的软硬件配置分成增强型和标准型两种。3.2.1标准型软硬件平台软硬件平台逻辑结构图：软硬件配置标准：序号项目描述1Web Server(2台) 作为所有应用系统的Web Server，通过Application Center 2000实现各应用系统的负载均衡及系统管理，其中一台为主控；或利用Windows 2003 Server的NLB（Ne
23、twork Load Balance）功能。最低硬件配置：2.0G*1CPU、1G内存、36G推荐硬件配置：2.8G*2CPU、2G内存、36G*2HD_Raid1软件： Windows Server 2003、Application Center 2000（或利用Windows Server 2003的NLBNetwork Load Balance功能替代Application Center 2000，但无推荐）2DB Server(1台)File Server (1台)作为所有应用系统的数据库服务器及专门放置附件的文件服务器、数据放置于磁盘阵列最低硬件配置：DB Server 2.8G*1
24、CPU、1G内存、36GFile Server 2.8G* 1CPU、1G内存、36G推荐硬件配置：DB Server 2.8G*2CPU、2G内存、36G*2HD_Raid1。File Server 2.8G* 2CPU、2G内存、36G*2HD_Raid1。软件: Windows Server 2003、SQL Server 2000 Enterprise3测试Web Server(1台)测试用Web Server硬件: 2.0G CPU、512M内存、36G*2HD_Raid1。软件: Windows Server 20034测试DB/File Server (1台)测试用DB Serv
25、er 和 File Server硬件: 2.0G CPU、512M内存、36G*2HD_Raid1。软件: Windows Server 2003、SQL Server 20005开发工具Visual Studio .Net 2003注：上述配置仅仅是建议，具体部署时应与设备供应商、集成商商议确定，特别是在DB服务器、文件服务器和磁盘阵列方面。3.2.2增强型软硬件平台软硬件平台逻辑结构图：软硬件配置标准：序号项目描述1Web Server(2台) 作为所有应用系统的Web Server，通过Application Center 2000实现各应用系统的负载均衡及系统管理，其中一台为主控；或利
26、用Windows Server 2003的NLB（Network Load Balance）功能。最低硬件配置：2.0G*1CPU、1G内存、36G推荐硬件配置：2.8G*2CPU、2G内存、36G*2HD_Raid1软件： Windows Server 2003、Application Center 2000（或利用Windows Server 2003的NLBNetwork Load Balance功能替代Application Center 2000，但无推荐）2DB Server(1台)File Server (1台)作为所有应用系统的数据库服务器及专门放置附件的文件服务器、数据放置于
27、磁盘阵列最低硬件配置： DB Server 2.8G*2CPU、2G内存、36GFile Server 2.8G*2CPU、2G内存、36G推荐硬件配置：DB Server 2.8G*4CPU、4G内存、36G*2HD_Raid1File Server 2.8G*4CPU、4G内存、36G*2HD_Raid1软件: Windows Server 2003 Enterprise、SQL Server 2000 Enterprise3磁盘阵列(1台)作为数据库文件和附件存储空间推荐IBM的FAST600（配置根据现状和发展预测可灵活调整）4辅助应用服务器(1台)作为定时调度的系统服务运行平台最低硬
28、件配置：2.0G CPU、512M内存、36G推荐硬件配置：2.8G CPU、1G内存、36G*2HD_Raid1软件: Windows Server 20035测试Web Server(1台)测试用Web Server硬件: 2.0G CPU、1G内存、36G*2HD_Raid1。软件: Windows Server 20036 测试DB/File Server (1台)测试用DB Server 和 File Server硬件: 2.0G CPU、1G内存、36G*2HD_Raid1。软件: Windows Server 2003、SQL Server 2000 Enterprise7AD服
29、务器测试用AD Server硬件: 2.0G CPU、1G内存、36G*2HD_Raid1。软件: Windows Server 20038开发工具Visual Studio .Net 2003注：上述配置仅仅是建议，具体部署时应与设备供应商、集成商商议确定，特别是在DB服务器、文件服务器和磁盘阵列方面。3.2.3软硬件平台技术特点由上面图表可以看出，综合应用管理系统硬件平台基本上是基于X86的PC服务器，软件平台基于微软windows平台和.Net技术。各部分采用的具体技术： web服务器：采用Application Center做负载均衡，通过横向扩充满足应用和用户增长的需要，同时也提高了
30、系统的健壮性。 数据库和文件服务器：采用Windows Server 2003的MSCS集群技术，实现双机热备。 增强型配置辅助应用服务器：主要运行系统的后台服务程序；标准型配置可将后台服务程序放到WEB Server上。3.3 应用系统逻辑设计在构建综合应用管理系统解决方案时，不仅涉及到开发自定义软件，而且还涉及到将该软件部署到生产服务器环境中。为了以最优方式构造可高效满足解决方案要求的应用程序和技术基础结构，并且将软件结构映射到硬件结构，建议采用以下方案：按逻辑分层组织软件应用程序。优化逻辑分层方法以提供和使用服务。按物理级组织硬件以便扩展。优化三级配置中的物理层策略。 endlistop
31、tionalpictureimg图 13.3.1三层服务应用程序分层应用程序在软件开发世界被广泛应用，这种实现定义了三个层：表示、业务和数据。虽然您可以添加更多层，但是对于综合应用管理系统上运行的管理支撑系统，目前几乎总是按三层结构来设计。pictureimg图 2 三层服务应用程序上面所显示的三层服务应用程序 基本上是一个松散的三层体系结构。三层分别是：list表示。表示层提供应用程序的用户界面 (UI)。这通常包括 Windows 窗体（用于智能客户端应用程序）和 ASP.NET 技术（用于基于浏览器的交互）的使用。业务。业务层实现应用程序的业务功能。该层通常由使用一种或多种支持 .NET
32、 的编程语言实现的大量组件组成。这些组件可能为实现可伸缩的分布式组件解决方案而以 Microsoft .NET Enterprise Services 进行了扩充。数据。数据层提供对外部系统（如数据库）的访问。该层涉及到的主要 .NET 技术是 ADO.NET。但是，在这里也经常用到一些 .NET XML 功能。 endlisthead3head3 endlisthead3head2通用组件除了三个标准层，三层服务应用程序 还定义所有层都可以使用的一组通用组件。在综合应用管理系统中，这些服务包括：HR、协同办公、消息通知、集中授权、监控等。3.3.2三级分布基础结构分级分布按一组物理级来组织系
33、统基础结构，以便提供针对特定操作要求和系统资源使用而优化的特定服务器环境。建议按三级组织解决方案服务器：客户端、Web 应用程序和数据。客户端级和数据级的功能不言自明；Web 应用程序级作为应用程序业务组件以及 Web 表示组件的宿主。对于具有更严格的安全性和操作要求的解决方案，您可能应该考虑将 Web 功能移到单独一级上。围绕三个物理级构造应用程序：客户端、应用程序和数据库。图 3 显示了此三级分布。pictureimg图 3head2客户端级客户端级与解决方案的用户交互。对于三层服务应用程序，该级将驻留表示层组件。 head3head2应用程序级应用程序级中的服务器负责驻留应用程序的业务组
34、件，以及 Web 服务器（在 Web 应用程序的情况下）。对于三层服务应用程序，该级将驻留业务层组件。head3head2数据级数据级中的服务器驻留了解决方案所需要的数据库。对于三层服务应用程序，该级将驻留数据层。3.3.3部署方案基于三层服务应用程序，目前已确定了几种常见的企业应用程序部署规划模型：简单 Web 应用程序、复杂 Web 应用程序、扩展企业应用程序以及智能客户端应用程序。现阶段综合应用管理系统采用简单 Web 应用程序模型。简单 Web 应用程序简单 Web 应用程序配置将所有组件部署到一个通用级。此配置（如下图所示）从理解上是复杂程度最低且最简单的配置。 pictureimg
35、随着综合应用管理系统上应用数量和种类的不断增长，简单Web应用程序模型将不能满足应用需要，那时综合应用管理系统结构必须做相应的调整，以适应复杂 Web 应用程序、扩展企业应用程序以及智能客户端应用程序等部署规划模型。head24. 通用组件的结构与功能本章节讲述的组件是供运行于综合应用管理系统之上的管理支撑系统使用的基础设施应用组件，主要包括：目录同步组件、消息通知组件、集中授权组件、服务器监控组件、流程管理组件等。4.1 目录同步组件目录同步组件对各市分公司的人员、组织架构、领导分管信息等用户基础数据的管理。目录同步组件的约定前提为各市分公司人员（包括临时人员）通过人力资源管理系统同步到省公
36、司统一信息平台的LDAP Server中。目录同步组件是统一信息平台LDAP用户数据库在各市公司的一个本地数据库副本，为市公司各管理支撑系统提供用户数据缓存区。下图为目录同步组件与其他部分的交互图。注：对于未在人力资源管理系统管辖范围之内的临时人员，在全省LDAP Server中注册，再同步到市公司目录同步组件。目录同步组件包括的模块有：v HR同步服务：指各市分公司通过Windows Service的方式从省公司统一信息平台LDAP Server中获取最新的人力资源相关数据和逻辑关系，包括工作类型、职位级别、部门/室/营业厅的分层数据、所有人员相关数据。（具体数据结构参见统一信息平台应用接入
37、规范）上述数据将作为综合应用管理系统向其他整合的应用系统提供基础用户数据的基础。v 领导分管信息定义：提供对组织架构各层（部门/室/厅）的分管领导的WEB界面设置功能，而对应的正职、副职则自动从同步的人力资源数据中获取到。这两方面的数据将作为公司内部的基本行政审批流程的指引数据。v HR数据接口：通过Web Service接口以二维表格方式向应用系统提供获取组织架构、人员、领导分管信息等数据，以便应用系统可以同步或获取相关数据。4.2 消息通知组件消息通知组件主要是在整个平台上提供统一的消息通知接口，减少重复投资，并利用移动公司的优势实现短消息移动办公。主要的模块有：v 短消息服务：以Wind
38、ows Service的方式与短消息中心指定端口地址实现收、发短消息的功能，收发的策略要能支持对各个应用系统的短消息进行区分。（接入短信平台可以选择本地网关或省公司企信通平台，但个别业务逻辑需要上行功能。）v 邮件服务：以Windows Service的方式与指定邮件服务器实现发送邮件的功能。v 短消息服务接口：以Web Service方式提供各个应用系统收、发短消息的接口。v 邮件服务接口：以Web Service方式提供各个应用系统发送邮件的接口。典型应用如A提交请假B审核C批准，当A提交请假后，B收到新的待办工作，同时B收到短消息通知；B收到短消息通知后登录系统进行审核，C收到新的待办工
39、作同时C收到含有概要数据的短消息，提示回复1即可自动审批；C用手机回复1后，应用系统通过短消息服务接口接收到回复的短消息，然后此申请单被自动批准。4.3 集中授权组件集中授权组件主要是用来对用户与应用系统之间的访问权限、对Web Service接口的访问权限进行管理，并提供相关接口。主要包括的模块：v 应用系统用户角色管理：各应用系统的角色的应用访问权限在应用系统中设置，此组件可以获取各系统中存在的角色。系统管理员和各应用系统管理员可以在此组件中将用户分配到不同应用系统的各种角色中。用户所属的角色也就定义了用户在系统中拥有访问权限。系统拥有通用角色，即使在各系统中都具备的通用性高的角色，系统管
40、理员设定只要设置用户所属的通用角色，各应用系统将继承用户所属的角色。而对个别用户的角色调整将由应用系统管理员进行操作。v 对用户有权限访问的应用系统，统一信息平台提供对应用系统的集成单点登录链接。v 应用系统访问权限接口：为各应用系统提供管理权限的Web Service接口，用于提供各应用系统获取用户在某系统所属的角色。v Web Service访问权限管理：Web Service是提供给各应用系统的接口，对其访问权限可以用数字证书方式或帐号限制方式。4.4 服务器监控组件服务器监控组件主要是对综合应用管理系统上的各服务器进行监控，监控的主要内容为CPU使用负荷、内存使用负荷、网络流量、磁盘空
41、间等。各市公司可利用CA作为监控工具，也可以考虑采用其它监控工具，如MOM、Tivoli、MAX等，原则上应优先考虑采用已有的监控系统。4.5 流程管理组件（可选项）工作流是基于业务规则进行系列动作执行的自动化工作路线。流程管理组件体系分成三个层次：表现层、业务层、系统层，可以在WEB应用的表现层和业务层创建垂直的业务流程。申请表+ 简单确认逻辑工作流定义业务逻辑内核 + 工作流引擎表现层业务层系统层客户化工作流逻辑流程管理组件主要由下面几个模块组成：v 流程引擎：管理和执行工作流流转。负责创建新的工作流，确定流程每一步执行的动作，确定流程每一步的执行人（角色），实现自动化流程的流转。v 流程
42、定义工具：定制业务流程，用于绘制、定义业务流程，管理路线、执行动作、活动，设置每个步骤和执行动作的属性，定义流程处理用户等。操作应简便、界面可视直观。v 表单设计工具：建立工作流信息表单以存放工作流数据，并绘制展示数据的用户界面。表单设计工具用户界面友好的。v 管理工具：核心的工作流管理组件，用于上载修改定义好的工作流和组织结构到系统。5. 系统性能要求应用程序和服务需要以下的运行（非功能性的）要求。这些要求包括应用程序必须达到的可缩放性、可用性、维护性、安全性和易管理性级别。这些要求可能会影响应用程序策略的设计，但它们还会影响应用程序逻辑的设计方法。在某些情况下，很难做到既符合某些运行要求，
43、又符合其他的运行要求。例如，通常降低应用程序的易管理性有助于提高安全性。重要的是，一定要在生命周期早期分清支持运行要求的应用程序功能的轻重缓急，以便从一开始就在应用程序实施中考虑到这些利弊权衡和决策。5.1 可缩放性应用程序的可缩放性是指，在增加一个或多个加载因子时，应用程序能否提供一个可接受的总体性能水平。常见的加载因子包括用户数量、应用程序管理的数据量以及事务数量。可以按照吞吐量和响应时间来测量总体性能。吞吐量测量应用程序在给定时间内执行的操作数量；响应时间测量用户或进程发出请求和收到请求结果之间间隔的时间。有很多因素影响吞吐量和响应时间，其中包括硬件性能、物理资源（如内存）、网络延迟（通
44、过网络链路传输数据所花的时间）以及应用程序设计。虽然可以通过增加硬件资源来解决很多性能和可缩放性问题，但如果设计的应用程序不能有效运行，则无论为解决问题投入了多少硬件，应用程序几乎始终具有很差的性能。对于高可缩放性应用程序，请考虑以下设计原则：使用异步操作。通过使用异步操作来降低响应时间和吞吐量要求。同步操作要求用户一直等到业务操作完成时为止。通过将业务操作变为异步操作，可以更快地将系统控制交还给用户，并将处理请求放在队列中排队，这样有助于控制吞吐量要求，而不会出现业务组件应付不过来的情况。例如，假定用户在电子商务站点下一个订单。如果订购过程是同步执行的，则用户必须等到已验证信用卡并从供应商订
45、购了物品后，才能开始接收确认。如果异步实施订购过程，则可以在操作完成后通过电子邮件给用户发送确认或失败消息。设计异步应用程序增加了开发人员的工作量（尤其是当他们需要事务逻辑时），但可以大大提高可缩放性。在需要数据的地方高速缓存数据。如有可能，应该在需要数据的地方高速缓存数据，这可最大限度地减少对数据存储的远程数据请求的数量。例如，对于前面介绍的电子商务站点，如果将产品数据缓存在 Web 站点中，而不是每次用户查看产品列表时都从数据库中进行检索，则该站点就会具有高得多的可缩放性级别。避免保存多余的状态。如有可能，应该将操作设计为无状态的操作。这样做可防止资源争用，提高数据一致性，并且可以在场中的多个服务器之间分摊请求负载。在某些情况下，需要永久性地保存状态，例如，在 HTTP 请求中必须存储客户的购物车。在这些方案中，必须谨慎地规划状态永久性和状态释放逻辑。仅当实际需要时，才应该释放状态（例如，当用户要查看其购物车或签出时）。避免出现资源争用。有些资源（如数据库连接）是很有限的，而有些资源（如数据库锁定）是独占使用的。应用程序设计应该体现以下原则：应该尽可能缩短保留资源的时间。应
