中小学智慧校园软件解决方案技术白皮书V2.0

中小学智慧校园软件解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 技术白皮书V2.0 智慧校园软件解决方案 白 皮 书 1 目录 1. 总体框架................................................................................................................... 3 2. 技术路线................................................................................................................... 4 2.1. 编程语言 ........................................................................................................ 5 2.2. 面向对象的组件技术....................................................................................... 5 2.3. 应用程序的开发与运行结构 ............................................................................ 5 2.4. 动态网页生成技术 .......................................................................................... 6 3. 信息 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 和规范系统 ................................................................................................. 6 4. 基础支撑平台............................................................................................................ 8 4.1. 统一身份认证系统 .......................................................................................... 8 4.1.1. 设计要点.............................................................................................. 8 4.1.2. 系统框架.............................................................................................. 9 4.1.3. 统一授权管理..................................................................................... 16 4.1.4. 单点登录服务..................................................................................... 25 4.1.5. 系统部署说明..................................................................................... 38 4.1.6. 平台可靠性和扩展性 .......................................................................... 40 4.2. 统一信息门户平台 ........................................................................................ 40 4.2.1. 设计要点............................................................................................ 40 4.2.2. 平台框架............................................................................................ 41 4.2.3. 门户运行环境..................................................................................... 41 4.2.4. 平台主要功能..................................................................................... 42 4.2.5. 平台部署及性能说明 .......................................................................... 45 4.2.6. 平台可靠性和扩展性说明 ................................................................... 47 4.2.7. 平台安全性考虑 ................................................................................. 47 4.3. 数据中心平台 ............................................................................................... 48 4.3.1. 技术路线............................................................................................ 50 4.3.2. 设计要点............................................................................................ 50 4.3.3. 平台框架............................................................................................ 52 4.3.4. 应用集成与数据集成 .......................................................................... 53 4.3.5. 数据交换机制..................................................................................... 55 4.3.6. 平台部署及性能说明 .......................................................................... 59 2 1. 总体框架 亿阳信通智慧校园总体框架如图所示: 该框架以“师生”为核心，围绕智慧校园的资源、管理和服务三要素，依托数据中心及应用支撑平台，重点建设校园资源中心、校园管理中心、校园服务中心应用系统，形成数字化的教学环境、科研环境和生活环境。 3 2. 技术路线 智慧校园应用系统应采用成熟先进的技术规范，设计上尽量减少各子系统间的相互依赖性(包括软件对平台、软件对数据、软件对软件、平台对平台等)，某个子系统的减少、增加和变更，不影响其它子系统和整体，从而最大限度地保护既有投资，减少系统的维护量和再投入。在应用系统整体化、模块化和规模化的同时，保证应用系统在技术上、经济上的可持续发展。 亿阳信通智慧校园软件系统遵循如下技术路线: 1、 采用“跨平台”的编程语言。 2、 采用独立于开发环境的面向对象的组件技术，如EJBs (Enterprise Java Beans)，整个系统的主要“应用逻辑”由组件构成，系统架构提供了良好的 伸缩性，使系统能够轻易地组合与拆分各功能模块。 3、 应用软件平台的开发及运行架构采用三层结构，即 Web服务器、应用服务器 和数据库服务器，在不影响系统其它部分的情况下，保证了应用服务器与其 它应用有效和无缝的整合，同时支持大规模的并发用户访问。 4、 采用模版(Template) 技术生成动态网页，为用户提供基于角色和权限的内 容和数据服务。 4 架构实现采用Java语言和EJBs技术，在数据交换上支持XML，使系统功能最优化，同时将系统内部的相互依赖性减至最低。 2.1. 编程语言 遵循J2EE (Java 2 Enterprise Edition)规范 ，采用Java语言和服务器端Java技术(包括EJBs、 Servlet、JNDI、 JDBC和RMI等)开发系统。Java作为Web应用的事实标准，其独立于操作系统和服务器的“跨平台性”，使其“一次编写，到处运行”，是WEB软件系统最适合的编程语言。相对于嵌入HTML、受限于用户端显示、编程能力有限的脚本语言，Java能力完整，可以开发具有强大“业务逻辑”的大型应用系统。 2.2. 面向对象的组件技术 软件编程由依赖于特定单机，到依赖于操作系统，已发展到今天面向对象的组件技术。面向对象的组件技术是一种完全独立于硬件和操作系统的开发环境，着重于应用程序“业务对象”的可重复使用组件，利用这些组件，可以像搭积木一样的建立分布式应用系统。面向对象的组件技术在异构、分布环境下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系统;另一方面， 组件大大加快了软件开发的速度，降低了软件开发和再开发的成本。 2.3. 应用程序的开发与运行结构 开发及运行结构基于三层架构，即Web服务器、应用服务器和数据库服务器。运用这种架构可以: (1)将“业务逻辑”从Web服务器中分出，在应用服务器中用独立和完整的编程语言而不是“脚本语言”开发应用程序，同时使系统支持任何HTML的显示工具; (2)应用服务器可以作为数据库访问请求的“缓冲区”，可以重新安排、管理数据库访问。通过Java Servlets引擎的多线程处理，能够极大地提高系统响应性能和数据库访问效率; 5 (3)应用服务器可以作为与其它应用程序集成的结合点，在不影响系统其它部分的情况下与其它应用有效、无缝集成。 2.4. 动态网页生成技术 信息发布采用基于模版的动态网页生成技术。用户界面的版面和显示效果由预先制作的模版实现，并支持任何标准化的HTML工具，嵌入模版的Java程序根据用户的角色和权限提取相应的内容和数据，配合模版自动合成针对用户的个性化的动态网页。 3. 信息标准和规范系统 信息标准是智慧校园建设的重心，是学校各信息系统进行数据采集、处理、交换、传输的前提，也是构建新应用需要遵循的标准。 亿阳信通按以下原则建设智慧校园的信息标准: , 唯一性:标准采用树形体系结构，唯一的项、唯一的路径、唯一的编码。 , 规范性:充分参照国家相关最新标准、教育部《教育管理信息化标准》、 北京市教委相关标准和各区县教委相关标准。 , 适用性:标准的制定充分考虑学校的实际情况，以应用为目标。 , 兼容性:对标准实行版本化的维护管理。高版本兼容低版本。同一个版本， 维护其不同内容的一致性。学校校内标准兼容教育部及其它管理部门的标 准，方便数据上报。 , 可管理性:系统提供数据标准集、数据代码集、自定义代码集、数据代码 映射等提供B/S架构的可视化管理工具，具备初始化、新增、删除、修改等 维护功能，支持分类检索、输出、数据展示等浏览功能。 , 可扩展性:支持标准的增加和变更，具有维护记录和回溯功能，并且对应 用该标准的业务系统透明。所有历史版本可查询，可比较差异。 管理信息标准的体系结构包括以下几个方面:一组相关数据元的集合，对数据元属性的规范描述(又称之为元数据标准化)，属性包含了数据项名称、中文简称、类型、长度、可选性、取值范围等。为了确保数据录入规范、便于查找和 6 统计，每个管理子集都对应着相应的标准代码，代码分国家标准、行业标准和学校标准。 系统遵循国家教育管理信息系统互操作规范，能够与北京市教委制定的小学应用互操作框架(简称CIF)无缝对接，实现各业务系统间规范的数据共享。 CIF实现规范也定义了基于XML标准的CIF数据模型，支持小学数据对象在应用系统间的共享。 “教师”和“学生”是智慧校园系统涉及的两大数据对象，业务数据实体主要由这两大对象映射产生。通过“教师”对象产生的数据实体主要有 教案 中职数学基础模块教案 下载北师大版¥1.2次方程的根与系数的关系的教案关于坚持的教案初中数学教案下载电子教案下载 、作业、教学成绩、教学 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 等一系列和教师教育教学活动相关的数据;通过“学生”对象产生的数据实体主要有考试成绩、课堂表现、获奖、毕业去向等一系列和学生学习成长相关的数据。这些数据存储在智慧校园的数据中心，通过综合统计分析，又产生大量的衍生数据，如教师分布情况、学生分布情况、考试成绩综合统计分析等，这些数据可以为学校的管理层提供微观和宏观的决策支持，使领导能够直观的了解各个部门乃至整个学校的运行状况。具体数据模型框架如下图所示: 7 4. 基础支撑平台 4.1. 统一身份认证系统 应用系统如果采用各自独立的身份认证机制，用户就要记忆不同系统中的账号/密码。为方便师生使用，解决多应用带来的多账号问题，需要建立统一的身份管理平台，用户在平台上登录一次就可以访问所有具有权限的应用。 统一身份认证以IDM/IM(身份认证管理)为基础提供安全的用户身份管理功能，并配合Access Manager 基于代理架构的访问控制，提供Web应用的单点登录和Web应用保护。IDM/IM都集成了Directory Server(LDAP)目录服务器来存储统一身份库信息。统一身份认证实现的功能如下: 1.建立统一的集中身份库——统一身份数据中心，对各应用系统的所有用户 管理，同时根据各个业务应用系统的认证方式的不同提供灵活提供集中和统一的 的认证机制; 2.在集中身份库的基础上，在满足数字校园管理平台信息系统内部业务流程规则的前提下，通过身份管理技术实现身份库与各个业务应用系统(门户、OA、教学、教务等系统)用户身份信息的自动同步处理功能; 3.在集中身份库的基础上，提供单点登录(SSO)功能，用户只需要通过一次身份认证就可以访问具有权限的所有资源。 集中身份库与门户系统的统一可以为整个平台提供集中的管理、安全机制，实现整体的统一。 4.1.1. 设计要点 , 支持用户数据的集成，适应中小学用户数据分散管理的现状 , 支持用户数据存储模式，适应中小学教职工多重身份的现状 , 支持多种认证方式，确保异构业务系统能够集成，让用户获得完整的 单点登录体验 , 满足不同用户或系统的认证安全需求 , 保证身份认证平台的高可靠性和高性能 8 前三个需求是身份认证平台发挥作用的基础，而随着应用集成的力度和广度的加大，后两个将是身份认证平台必须妥善处理的问题。 校园应用功能多样、结构复杂，各应用系统的权限管理基本上采用分级授权的方式。身份认证平台可以采用统一的权限模型，供各应用系统使用，相应的权限数据既可集中管理也可分布式管理。从实践结果看，集中权限控制的效益并不明显，建议不强求集中控制，由各应用系统设计开发时按需选择。 4.1.2. 系统框架 身份认证平台主要包括以下三方面功能: , LDAP目录服务，支持海量用户数据的存储和管理 , 高性能SSO(单点登录)身份认证服务 , 开放的认证集成方式，支持不同开发语言和不同应用服务器平台的业务 系统 4.1.2.1. 统一身份管理架构 学校的各种应用系统通常都有自己独立的用户管理、用户认证和授权机 制，导致系统间互不兼容;学校的组织机构也不断变化，用户来源日趋复 杂，角色多样化和角色变化等问题不断出现。各方因素交织在一起形成了一 个庞大的矩阵，为统一的身份管理带来了困难。如图: 9 针对上述问题，建立一个统一的，基于业界标准(如LDAP，XML，Web Service，J2EE等)的，灵活、开放、可扩展性的身份管理框架是最终的解决方案。一个好的身份管理解决方案将复杂的身份管理问题变得简单、实用。身份认证平台核心结构如下图所示: 身份认证平台管理用户在各个应用系统中的用户信息的对应关系，并根据 10 这一关系管理用户在各个应用系统中的生命周期，如添加、删除、修改等。身份认证平台的身份同步工具可以自动发现某个应用系统中用户信息的变化并通过一定规则，保持和其它应用中的用户信息同步。 身份认证平台的核心包括用户信息创建和中止的审批流程，该流程由管理员预先定义，可以修改。 当用户帐户的申请被批准后，用户帐户将根据预先定义的规则在中央主目录服务器中创建，并通过资源适配器在各个该用户可以使用的应用系统中产生帐户信息。用户帐号的中止也是同样原理。 身份认证平台具有口令管理功能，支持口令策略管理和口令历史记录，支持用户身份审计和用户帐户风险分析，支持用户身份管理系统运行的监测、评估。 4.1.2.2. 用户数据模型 身份认证平台中的数据模型包括: 1. 用户帐号:学生、教职员工、合作伙伴、供应商等帐户信息; 2. 资源:身份认证平台所管理的身份数据源和应用系统，如学生数据中心、教职工数据中心、电子邮件、一卡通、综合网络管理系统以及上网认证系统、VPN系统等，以及其它基于用户属性更改的应用; 3. 资源组:按一定顺序组织的资源，身份认证平台将根据这一顺序在应用系统中创建和删除用户信息; 4. 组织:管理一组用户、资源和其它对象的逻辑容器; 5. 角色:用户的工作角色，代表其职能性质，据此在资源中设置用户的属性; 6. 管理帐户:具有管理员权限，可以进行分级管理; 7. 能力:拥有哪些权限，如口令管理员只能管理用户的口令。 下图为数据模型图: 11 身份认证平台: 1. 管理用户访问一个或多个资源的权限; 2. 管理用户在这些资源上的帐户数据; 3. 赋予用户一个或多个角色，设置用户访问各种资源的权限; 4. 管理组织，决定用户帐户由谁和怎样被管理。 用户数据是动态的，依赖于用户的角色、资源和资源组。根据角色(可以是多角色)赋予的资源的数量和类型，需要不同的信息表示，也决定着创建用户时的信息数量。 身份认证平台有虚拟用户的概念，主要作用是映射用户到多个资源，可以将一个用户在多个应用系统中的全部帐户信息作为一个实体来管理。 12 4.1.2.3. 用户数据管理 身份认证系统需要提供多样化的用户数据管理方案。用户数据采集可以根据学校现状，采用以下方式: 1、集成管理着权威用户数据的业务系统，依赖该系统进行用户数据管理 2、通过数据集成平台双向同步用户数据 3、通过身份认证平台的用户管理程序管理用户数据 4.1.2.4. 身份数据集成 统一身份认证系统集成用户身份数据的过程，是通过数据交换平台从学校的各个业务系统中自动抽取用户身份数据，并加以归纳和整理，最终充实用户身份信息库。 4.1.2.5. 自动发现和动态同步 身份认证平台可以自动发现所管理资源中用户信息的更改，并根据规则将其同步到其它资源中去。 4.1.2.6. 帐号和口令管理 身份认证平台提供了统一的WEB管理界面，可以方便地管理帐号和口令。帐号管理功能包括: 1. 用户自注册功能:用户使用公共的帐号/口令登录系统，然后自行注册一个 账号/口令。 2. 帐号新建功能:外来人员如需临时帐号，可以由管理员手工生成访问身 份，这个访问身份通常是帐号/口令，也可通过多因子认证或数字证书实 现。这些临时帐号需要有效期限制，在“临时”的这段时间内有效，过期 则失效;对于可转为正式帐号的“临时帐号”，可自动转换。 3. 帐号注销功能:在一定条件下，实现用户帐号的注销。用户帐号注销后，所 有的用户权限失效。 13 4. 帐号冻结功能:暂时中止用户的访问权限，在用户需要开通时可以重新恢 复，这样用户可以继续使用原来的帐号。 口令管理包括: 1. 自助式口令重置和同步 2. 通过Web浏览器或者IVR(Interactive Voice Response，交互语音应答系统) 系统来实现 3. 自动口令策略执行 4. 口令历史信息存储 5. 口令过期通知等等。 为满足用户个性化设置的需求，减轻管理员密码维护的压力，平台提供个人密码找回和别名登录功能，并开放给所有用户。 个人密码遗忘后，用户可以在门户认证界面上使用密码找回功能，问题回答正确后，可以重新设置密码; 用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否重复，别名设置成功后，用户可以使用别名进行登录。 4.1.2.7. 分级管理 平台提供扁平的用户权限模型，提供分级管理功能。 应用模式 , 系统缺省建立四大类身份:领导、教职工、学生、校友; , 各应用系统按需建立自己的权限组或属性信息，也可复用其它系统已 经建立的权限数据; , 权限模型支持分级授权，支持按组织架构、系统范围、用户属性等将 权限管理工作分派给多名管理员;由于本功能在实际使用中容易导致 管理混乱，一般建议只按照系统范围(如人事系统、学生系统等)来分 级授权。 , 用户数据采集时，自动根据用户的属性和来源为其设置相应的身份。 14 4.1.2.8. 批量维护工具 满足管理员日常数据维护的需要，提供: , 批量导入用户数据、组织数据 , 批量修改和删除人员属性信息 , 高级查询功能 , 系统服务的注册和注销 , 在不同的人员容器间移动人员数据 应用模式: , 教职工用户数据通过人事系统数据访问接口或用户数据表导入; , 管理员定期使用该工具完成教职工用户数据的导入; , 学生毕业转为校友后，管理员通过该工具将毕业生批量转入; , 系统运行准备阶段，管理员通过该工具完成批量用户密码初始化。 4.1.2.9. 与典型应用系统的集成 身份认证平台的资源适配器采用服务器端的J2EE适配器，部署在身份认证服务端，即J2EE应用服务器上，然后根据所管资源的通讯协议和资源互通。对于大部分应用系统，无须在资源(即应用)一方安装任何代理。这样既对应用系统无影响，又避免了维护代理的工作。 4.1.2.9.1. 与LDAP目录服务器的集成 身份认证平台和LDAP目录服务器的集成，如Sun Java System Directory Server是通过JNDI资源适配器完成的，在资源方无须代理。 4.1.2.9.2. 与采用LDAP目录服务的应用系统集成 同上。身份认证平台通过其LDAP目录服务资源适配器和这些应用系统集成。 15 4.1.2.9.3. 与关系型数据库应用系统的集成 如果应用系统的用户数据存储在关系型数据库中，应用系统和统一身份认证系统集成后，统一身份认证平台替代了应用系统的身份认证功能，该数据库中的用户信息将主要用于应用系统自身的授权和策略管理。 身份认证平台主要集成关系型数据库中的用户信息表、权限信息表以及用户/权限对应关系表等，在身份认证平台上建立针对应用的数据库资源，并制定相应的用户信息映射和同步关系，通过该资源将相应用户信息创建到数据库中。身份认证平台和关系型数据库的集成是通过身份认证平台提供的JDBC(Java Data Base Connectivity，Java数据库连接)资源适配器完成的，并在资源方无须安装任何代理。 4.1.2.9.4. 资源适配器的开发 身份认证平台为创建定制化的资源适配器提供了工具和文档支持。 开发工具包包括: 1. 指南性文档资料:功能定义、README文件等 2. Javadoc:提供身份认证平台的API信息 3. Jar文件:用于编译、连接 4. 样本源代码等。 4.1.3. 统一授权管理 策略与权限管理模块是多用户应用系统不可或缺的。通常，策略与权限管理模块以应用专有的方式实现，系统的策略模型、策略存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种方式的缺点是显而易见的:由于策略模块与应用逻辑之间的紧耦合使得策略模块很难进行扩展与维护;策略模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。 为了克服专有方式的缺点，统一用户管理与认证平台在基础设施层提供了增强的策略服务，提供标准、通用、灵活和可扩展的策略模型，支持策略的定义、存贮、配置与判定，并与用户管理和服务管理紧密集成。 16 4.1.3.1. 统一授权平台的架构 统一授权平台的架构如下图所示。图中以灰色表示的组件是应用相关的部分，需要进行定制设计与开发;其余组件均由统一授权平台提供。 总体而言，策略与权限管理模块的架构基于PDP/PEP模型。PDP代表策略判定点(Policy Decision Point)，是策略的提供者;PEP代表策略执行点(Policy Enforcement Point)，是策略的使用者。该架构中，统一授权管理提供PDP服务，包括策略的定义、存贮、配置与判定，这些服务通过策略判定API与策略管理API向外部应用提供;PEP是应用中根据策略判定结果执行应用逻辑的部分。PDP与PEP之间可以通过Java/C++ API或XML/HTTP通信。 由于统一授权管理提供的策略判定结果是原始结果，为了进一步简化应用中的策略执行逻辑，引入应用策略判定接口，对统一授权管理的策略判定接口进行封装，对原始策略判定结果作进一步加工与处理。 统一授权管理支持通过策略主体SPI(服务提供者接口)、策略条件SPI、策略推荐SPI与资源名称SPI进行扩展。策略的存贮结构通过LDAP中的对象类与属性类型加以定义;策略存贮在目录服务器中。 17 4.1.3.2. 策略模型 统一授权管理的策略服务建立在通用、灵活和可扩展的模型上。正是该策略模型使其能在基础设施层以一种应用无关的方式提供强大的策略服务。一般而言，作为访问控制规则的策略描述了“谁在何种情况下针对指定服务对何种资源可执行怎样的操作”。在这里，“谁”是策略的主体;“情况”是策略适用的条件;“服务”是策略的上下文，“资源”与“操作”都是与该服务相关的;“资源”是策略的对象;“执行怎样的操作”可以表示为一系列“动作”及与之对应的“值”。基于单点登录系统的策略模型提供了充分的表达能力，允许准确描述如上的通用策略。 统一授权管理的策略采用XML来描述。为简明起见，在此以半形式化的方式描述策略模型如下: 常规策略 ::= 主体集 + 条件集 + 规则集 主体集 ::= {主体} 条件集 ::= {条件} 规则集 ::= {规则} 主体 ::= Access Manager 角色集| LDAP 组集| LDAP角色集| LDAP用户集|LDAP组织集 条件 ::= 认证级别|认证方式|客户IP |时间 规则 ::= 服务 + 资源名称 + 动作类型-值对集 资源名称 ::= 字符串 动作类型-值对集 ::= {动作类型-值对} 动作类型-值对 ::= 动作类型 + 值 备注: 1、统一授权管理的策略包括推荐策略与常规策略。由于推荐策略只是将策略推荐给对等组织或子组织进行判定，而不涉及策略的具体判定，因此此处不对推荐策略进行详细描述。 2、统一授权管理提供的主体插件SPI、条件插件SPI和资源名称插件SPI允许扩展主体、条件与资源名的表达能力，上述描述中主体、条件与资源名称只是由系统提供的标准实现。 18 4.1.3.3. 策略编程接口 应用系统访问身份认证平台可以使用Java API接口，也可以使用XML/HTTP接口。如果是远程访问，则Java API接口本身也是对XML/HTTP接口的一种封装。 远程客户端调用策略验证接口时的处理流程如下: (1) 应用系统调用Java API请求策略验证; (2) Java API根据策略验证请求生成一个XML策略验证请求; (3) Java API将XML策略验证请求通过HTTP协议发送给系统的Policy服务:%protocol://%host:%port/amserver/policyservice (4) 系统处理策略验证XML请求，并创建一个策略决策XML文档作为应答返回给客户端; (5) 客户端Java API接收并解释策略决策XML文档; (6) 应用系统通过Java API获取策略决策信息。 从上述流程可知，策略验证的结果是以策略决策的形式表现的。如果使用XML/HTTP接口，则策略决策是一个XML文档;如果使用Java API接口，则策略决策是一个Java对象。 策略决策中包括一组动作决策，动作决策是关于某个具体动作的决策，其中包括: (1)动作的值:与该动作相关的决策的值; (2)有效时间(TTL):决策值在多久时间内有效; (3)建议:该动作决策的描述信息。 动作的值可以是布尔类型的，表示是与否、允许或禁止等两值类型的动作决策;动作的值也可以是复杂类型的，如字符串、数值等，可以用来表示动作的程度、范围等决策概念，诸如邮箱配额、折扣率等。 可能有许多策略适用于一次策略请求，不同的策略可能相互冲突。比如，用户拥有的角色允许他访问某个URL，而用户所属的组禁止他访问某个URL;再比如，用户拥有的一个角色给予他20M的邮箱配额，而用户拥有的另一个角色给予他10M的邮箱配额。这种不同策略同时适用，而且决策值不同的情况称为冲突。冲突的策略决策必须消解之后才能用于权限控制。系统是这样消解策 19 略决策冲突的: (1) 如果动作值的类型是布尔类型，则所有策略的决策值在执行AND操作之后返回，返回的值是单值。也就是说，只要有一个策略的动作决策是false，则动作的决策值就为false; (2) 如果动作值的类型是复杂类型，则所有策略的决策值全部返回给应用系统，由应用系统对决策值进行进一步的冲突消解。 策略的管理包括创建、删除和修改策略。用户可以通过系统的WEB控制台界面或命令行界面管理策略。如果在应用系统中需要对策略进行管理，可以使用系统的策略管理API。 4.1.3.4. 应用策略的设计 一个应用系统是建立在多种平台服务之上的，并且向用户提供多种用户服务;而一个平台服务也应该为多个应用系统使用。因此应用系统与服务之间是多对多的关系。 由于服务是应用的组成元素，因此，授权应该是针对服务的资源而不是应用的资源来进行的。不同的服务具有不同的资源和动作类型，因此，不同的服务有不同的策略模板，该模板称为策略方案(Policy Schema)。服务与策略方案之间的对应关系应该是一对一关系。配置策略、验证策略是通过指定服务来指定策略方案的。 一条具体策略规定了一组主体在一组条件下的一组访问控制规则。每条规则中均指明了一个服务、属于该服务的资源以及一组动作与值对。每个策略方案也可以被多条策略使用。因此，策略与策略方案之间的对应关系应该是多对多关系。 由于服务与策略方案之间是一一对应的，因此，定义策略方案是在定义服务的同时进行的。只有当服务定义之后，才能定义与该服务相关的具体策略。 从身份认证平台服务管理的角度，服务是一组定义在一个公共名字下通过身份认证平台管理的属性的集合。身份认证平台将服务作为一组属性进行管理，而并不关心这些属性的具体涵义。服务的属性集合是通过一个XML文件加以定义的。 20 身份认证平台提供了大量的平台服务，这些服务本身也是通过系统的服务管理功能加以管理的，因此，这些平台服务也有对应的XML定义文件，并且服务的选项也是通过服务的属性加以管理的。 为了使服务能够针对不同的用户、角色或组织等身份实体进行定制和个性化，身份认证平台将服务的属性分为以下五种类型。不同类型的属性具有不同的作用域、继承性、用途。 类型 作用域 继承性 用途 全局 整个统一授权系统 不可继承 服务的全局配置 组织 应用于组织 不可继承 服务的组织级配置 动态 应用于角色、用户 可继承 服务的动态配置，配置给角色的属性自动为 所有具有该角色的用户拥有，配置给组织的 属性自动为所有该组织下的用户拥有。 策略 与服务授权相关的配置 N/A N/A 用户 只应用于用户 不可继承 服务针对于每个用户的个性化配置。用户类 型的属性只对个别用户有意义。 4.1.3.5. 角色与用户组管理 角色是和用户组的概念相似的目录服务器对象管理机制。一个组有其成员;一个角色也有其成员。 在身份认证平台中，用户角色的权限是通过为其设定ACI(Access Control Infromation)来控制的。访问控制指令可以控制对整个目录、目录子树、目录中特写条目(包括定义配置任务的条目)或特定条目属性信息的访问权。可以设置特定用户、所有属于特定组或角色的用户或所有目录用户的权限。还可以定义对特定位置(例如IP地址或DNS名称)的访问权。 与条目属性一样，访问控制指令存储在目录中。ACI属性是一种操作性属性，可用于目录的各个条目，而不管是否为该条目的对象类所定义。接收到客户端的LDAP请求时，目录服务器使用该属性来允许或拒绝访问。如果有特别请求，则在ldap search操作中返回ACI属性。 在平台中可以定义特定的角色，并利用ACI来控制其访问权限。这样做可以满足一些特殊需求。 利用组织内创建用户时可以拥有默认角色的机制，可以为不同的组织创建不同的默认角色，这样新建的用户就自然拥有了这些角色所拥有的属性和服务 21 以及相应的权限。 组代表了具有相同功能、属性或者兴趣爱好的用户的集合。一般来说，组没有自己的特权。组可以定义在组织机构下，也可以定义在别的受管组(Managed Group)内作为子组。 身份认证平台提供了组的分级管理的能力。虽然组的成员缺省来自于整个用户树，但是对于权限有限的组管理员来说，当他管理一个预订组的时候，他只能把他自己能管理的用户添加到新创建的预订组中。在这里已经部分实现了用户组的分级管理。 在业务系统一级授权上，我们提供了全局权限组用于人员的初始化授权。这些组按照用户基本身份建立(比如学生组、教职工组)，作用域为整个组织树，在人员的初始时可以按照身份加入这些全局组，从而实现人员权限的初始化。 4.1.3.6. 权限语义集成 当身份认证平台的策略服务不能满足业务系统授权要求时，我们提供了一种针对业务系统开放的完全自由的权限语义集成机制。权限语义描述了用户的具体应用权限，权限语义的具体描述和解析由业务系统负责。业务系统可以通过API来获取这些语义，解析后授予用户相应的权限。 4.1.3.7. 用户数据采集 功能描述 针对学校用户管理分散进行的特点，提供从权威数据源采集用户数据，并实时更新目录服务器中的用户数据，提供: , 数据源采集点和采集周期定义 , 数据源变化跟踪和自动采集 应用模式 建立从公共数据库平台相关的共享数据集采集，在学生和教职工用户数据变更(包括新增、删除、修改)后，采集模块自动同步更新统一认证用户数据 22 库。 用户数据通常分散在不同的应用系统中。常见的情况是:人事系统管理人事信息;办公系统管理与日常工作有关的信息;用户的认证信息如用户ID和密码在各个系统中一般不同，由各个系统分散管理;用户的基本属性，如姓名等信息往往在各个系统中都存在。不同应用系统不但管理不同类型的用户数据，而且也提供不同类型的数据存储与访问方式。传统的业务系统一般使用关系数据库存放用户数据，如管理信息系统;互联网应用系统一般使用LDAP存放用户数据，如电子邮件系统。不同类型的数据存储方式具有不同的数据存储格式，也提供不同的数据访问接口。用户数据的分散存储与管理使得共享用户数据成为复杂而低效的任务。 建立统一用户管理数据库的目的是为用户信息的管理与使用提供统一的入口。统一用户管理数据库在物理上与其它应用数据源独立，在数据上与其它应用数据源保持同步。用户管理数据库变更后同步到LDAP目录数据库。 4.1.3.8. 用户数据发布 功能描述 为了保持各业务系统中用户数据的完整性和统一性，向各集成业务系统提供用户身份数据。 应用模式 , 对目前已有系统提供用户数据更新变更同步 , 提供用户信息的浏览、排序、查询等管理功能 , 由于中小学用户数据分散管理，在权威数据源变更后，其他系统都可 通过统一用户管理数据库同步数据变更，保持数据的完整与一致 4.1.3.9. 批量维护工具 功能描述 满足管理员日常维护数据的需要，提供: , 导入用户数据和组织数据 23 , 批量修改和删除人员属性信息 , 高级查询功能 , 服务注册与注销 , 在不同的人员容器间移动人员数据 应用模式 , 教职工用户数据由人事系统提供数据访问接口或用户数据表 , 管理员定期使用该工具完成教职工用户数据导入 , 在学生毕业转为校友后，管理员通过该工具将毕业生批量转入 , 系统运行准备阶段，管理员通过该工具完成用户密码的批量初始化 4.1.3.10. 个人自助服务 功能描述 为了满足用户个性化设置并减轻管理员的维护工作量，平台提供个人密码找回、别名登录功能。 应用模式 , 该功能开放给所用用户; , 用户遗忘个性化设置的密码后，可以在门户认证界面上进入密码找回 功能，预设问题回答正确后，可以自主重置密码; , 用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名 是否重复，别名设置成功后，用户可以通过别名进行登录。 4.1.3.11. 权限模型 功能描述 为了适应中小学用户多重身份和组织结构易变的特点，同时最大限度的保证用户认证效率，平台提供扁平的用户权限模型。 应用模式 , 系统将缺省建立四大类身份:教职工、学生、领导、校友; , 各应用系统按需建立自定义的权限组或属性信息，也可复用其他系统 24 已经建立的相关权限数据; , 权限模型支持分级授权，方便按组织架构、系统范围、用户属性等特 征将权限管理工作逐级分派给多名管理员;该功能在实际使用中容易 导致管理混乱，一般建议只按照系统范围(如人事系统、学生系统等 等)来分级授权。 , 用户数据采集时，自动根据用户的属性和来源为用户设置相应的身 份。 4.1.3.12. 认证集成 功能描述 满足学校业务系统多元化特点，提供: , 支持基于认证接口、认证代理和LDAP认证的多种认证集成模式 , 支持密码认证 , 支持与标准的主流Radius服务器集成 , 预留CA认证扩展接口 , 预留SmartCard、JavaCard认证扩展接口 , 预留与网络接入认证设备用户认证模块的集成接口，实现与网络接入 认证设备的认证集成 应用模式 , 业务系统全部采用基于认证接口的认证集成方式; , 用户统一采用基于密码认证的登录方式。 4.1.4. 单点登录服务 单点登录(Single Sign On，SSO)通常定义为指用户只需经过一次认证就可以访问所有拥有访问权限的应用系统。单点登录能够提高用户的工作效率，减少身份认证过程中的人为错误，也减轻了用户在密码管理上的负担，从而使系统更安全、更易用。身份认证平台提供了单点登录解决方案，用户只需通过系统的认证，并且具有足够的权限，就可以访问所有由身份认证平台管理的应用系统。统一认证服务是单点登录支持的基础，没有统一认证，就没有真正的单点 25 登录。 校园网通常运行多个应用系统，为学校领导、各部门及教生提供多种服务，这样就带来了一个突出的问题，用户面对多个系统时要记忆、输入帐号/口令等信息，不仅烦琐，而且容易丢失口令，一旦口令泄漏会造成不可估量的损失。 单点登录系统的建设目标是要解决各应用系统用户名和口令不统一的问题，期望提供一套方便、安全的口令认证方法，让用户只要一个用户名和口令就可以使用网络上他有权使用的所有业务系统。 4.1.4.1. 设计要点 单点登录系统设计的要点如下: , 遵循LA(Liberty Alliance，联合互信)的ID-FF V1.2规范。 , 支持SAML(Security Assertion Markup Language)安全性断言标记语言 规范。 , 支持多种多级登录认证机制，如用户/密码、动态口令等。 , 支持系统的认证过程支持加密的认证方式。 , 系统支持基于用户UID和密码的身份认证。 SHA等加密算法。 , 提供用户密码加密功能，支持SSHA、CRYPT、 , 通过TLS(Transport Layer Security，传输层安全协议)或SSL(Secure Sockets Layer，安全套接层协议)为信息传输提供保密性和完整性保护。 , 支持X.509协议，可以对数字证书、公共密钥、数字签名进行存储和管 理。 , 支持跨域的单点登录功能。 4.1.4.2. 系统原理与体系结构 单点登录系统的根本原理是保持用户的会话(session)状态。用户经过一次认证就可建立单点登录会话，每个单点登录会话对应于一个令牌(token)，用户访问应用系统时向应用系统传递单点登录令牌，应用系统能够根据令牌识别 26 用户的认证状态，从而使一次认证能够被多个应用系统认可，避免了重复认证。 我们采用Sun Java System Access Manager(简称AM)作为单点登录的底层技术平台。 根据上述原理，AM对单点登录提供SDK级别的支持，其中包括单点登录令牌的创建与验证。以WEB应用的单点登录为例:用户通过AM的认证页面进行认证，认证通过之后，平台为该用户创建一个单点登录令牌，并将该令牌的ID通过cookie返回至用户浏览器;当用户访问WEB应用系统时，单点登录令牌ID自动通过cookie传递至WEB应用系统，WEB应用系统可以通过单点登录令牌ID还原单点登录令牌，并向Access Manager验证单点登录令牌是否有效。如果有效，则应用系统可以从单点登录令牌获取用户身份信息，而不再需要用户进行再次认证。对于C/S结构的应用，单点登录过程是类似的，只是单点登录令牌ID的传递方式不同。 上述单点登录SDK的体系结构如下图所示: SSO令牌验证WEB浏览器Java应用程序SSOTokenIDSSOTokenID HTTP(s)HTTP(s) WEB服务器SSOTokenManager 认证服务定制服务SSO属性获取 验证/创建SSO令牌创建SSO令牌获取SSO属性 验证SSO令牌 验证SSO令牌验证SSO令牌SSOTokenSSOProviderSSOToken 如前所述，单点登录是通过单点登录会话实现的，通过单点登录会话保持用户在整个平台的认证状态。 在对用户进行身份验证之前，AM的会话服务先产生令牌，令牌包含一个随机生成的会话标志并且会作为这次会话的最终标志。令牌一旦生成，AM会将它插入一个Cookie，并且颁发给用户的浏览器。与此同时，AM会根据用户 27 所使用的验证方式，提示不同的登录界面，验证方式可预先为组织、角色或单个用户进行配置。当用户接收到登录界面时，同时也获得一个会话令牌，用户会键入用户名和密码，登录资料被提交给适当的验证服务器(如LDAP、RADIUS等)，一旦用户通过了身份验证，AM会从cookie中提取用户的令牌，并且将其状态设置为有效的，接着将用户重新定向到所要访问的URL。 单点登录会话具有如下图所示的生命周期: 无效 认证成功 有效 超时 登出 销毁 如图所示，单点登录会话的初始状态是无效，表示单点登录会话虽然已经创建并被分配给用户，但用户尚未通过有效认证。无效的单点登录会话也通过一个单点登录会话令牌身份，并存储在用户浏览器的cookie中。当用户认证成功之后，单点登录会话变为有效状态。该单点登录会话仍以同一个单点登录会话令牌身份，用户浏览器中的cookie不变，只是服务器维护的会话状态变为有效。单点登录会话可以因为以下原因而销毁: 1. 客户端空闲时间达到最大空闲时间; 2. 会话时间达到最大会话有效时间; 3. 由于用户登出而显式销毁会话; 会话销毁之后，客户端cookie中保存的单点登录会话令牌身份仍然存在，只是与该令牌相关的会话信息已经在AM中删除。 上述单点登录会话的生命期由AM进行管理，会话的生命期特性可以通过配置选项进行定制。在AM中，与单点登录会话相关的属性是通过“会话”服 28 务(session service)进行管理的，这些可配置属性均为动态类型的属性，可以针对组织、角色和服务配置，并可被继承。会话的可配置属性如下表所示: 单点登录会话属性 说明 最长会话时间(分钟) 单点登录会话有效的最长时间，超过该时间，用户必须重新登 录创建新的单点登录会话。 最长空闲时间(分钟) 当用户没有任何动作时，单点登录会话有效的最长时间，超过 该时间，则会话失效，用户必须重新登录创建新的单点登录会 话。 最长高速缓存时间(分钟) 单点登录会话信息在客户端高速缓存中保存的最长时间，超过 该时间，则客户端必须访问服务器以刷新缓存中的会话信息。 通过AM的Web控制台可以管理单点登录会话。在Web控制台的“当前会话”页面显示了当前所有有效的单点登录会话的状态，管理员能够有选择性地终止单点登录会话。 4.1.4.3. 认证方式设计 单点登录系统采用认证方式与登录方式分层的设计，可平滑扩展多种登录方式，如用户名口令、证书、智能卡等，支持多级登录认证机制。 为防止暴力破解，提供附加图像码的方式增加安全性。 4.1.4.3.1. 用户认证方式 认证方式 单点登录系统提供了多种内置的登录方式。 1、LDAP认证方式 单点登录系统提供的缺省认证方式。使用LDAP认证方式，用户名与口令存储在指定的LDAP目录中。当一个用户登录时，提供的用户名与口令若与该LDAP目录中指定子树中某一个用户记录的用户名与口令相同，则认证成功，登录者具有LDAP目录中该用户记录对应的身份。 2、自注册认证方式 允许用户在认证时选择“新建用户”，并输入用户名与口令，建立自已的用户帐号。随后就可以像LDAP认证方式一样使用用户名与口令登录系统。自注册用户的资料也存放在LDAP中，但可以为自注册用户指定不同于用户的存 29 放位置。 3、数字证书认证方式 使用X509v3数字证书，只要客户端可以提供X509v3数字证书，系统允许其登录。可以配置用户的个人数字证书必须和目录服务器中存储的证书相同，并与证书回收列表(CRL)比较以确保个人证书是有效的。 4、RADIUS认证方式 系统利用外部的拨号认证系统作为本身的认证机制，如果用户通过了外部拨号认证系统的认证，系统则认为此用户认证通过。 5、UNIX认证 系统利用所安装UNIX环境的认证系统作为本身的认证机制，如果用户通过了UNIX认证系统的认证，系统则认为此用户认证通过。 6、Microsoft Windows 域认证 系统使用Windows 域认证系统作为本身的认证机制，如果用户通过了它的认证，则认为此用户认证通过。 7、SafeWord认证 系统可使用Secure Computing的SafeWord或SafeWord Premier认证服务器。单点登录系统作为SafeWord服务器的客户端，SafeWord服务器可以安装在单点登录系统的同一台机器上，也可以安装在另外的系统中。 8、RSA SecureID认证 9、多因子认证 除了上述内置的认证方式之外，平台也提供了服务提供者接口来开发定制的认证方式。 认证方式个性化 不同的认证方式具有不同的安全性、易用性和部署成本，因此，针对不同的用户群与不同的应用范围需要对认证方式进行个性化。在单点登录系统中，可以根据角色、用户、服务指定不同的认证方式，也可以在认证时直接指定认证模块。对于不同组织、角色和服务，可以配置个性化的认证选项。 认证选项按照不同的认证方式通过单点登录系统的服务加以组织。单点登录系统为每种内置的认证方式定义了一个服务，并定义了一个核心认证服务， 30 用于组织所有认证方式的公有属性。以下分述核心认证服务与支持的配置选项以及常用认证服务的配置选项。 核心认证服务支持的配置选项分为全局选项与组织选项。全局选项在整个单点登录系统范围内适用，组织选项在组织级别进行配置，只对一个组织有效。 4.1.4.3.2. 用户认证界面 用户认证界面是单点登录系统与最终用户的接口，它负责向用户显示登录表单，搜集用户认证信息，并传回服务器端;服务器端通过调用平台的认证API进行认证，并为通过认证的用户创建单点登录系统的单点登录会话。单点登录系统提供了基于WEB的用户认证界面，该用户认证界面是由单点登录系统动态生成的，提供了平台中所有认证模块的用户界面。 单点登录系统的用户认证界面是基于JATO(J2EE Assisted Take-Off)WEB应用框架创建的，它通过JSP和XML为用户提供图形化界面的交互方式。对用户认证界面的常见客户化工作包括对认证界面上的文字信息和图片进行客户化，以及对用户认证界面进行本地化。 认证界面是基于一组JSP模板和XML文件动态生成的。JSP模板定义了认证页面的布局，XML文件是认证模块的配置资源文件。缺省JSP模板和XML文件均位于位于IS_Root/SUNWam/web-apps/services/config/auth/default目录下。这些文件均可修改，使得不同的组织、子组织、地区、服务/应用、客户端类型具有不同的认证界面。 4.1.4.4. 认证接口设计 单点登录系统提供了公共的认证服务架构，对外提供多种认证接口，以及认证服务的扩展接口。基于统一的认证服务的应用系统间可以实现单点登录。 4.1.4.4.1. 认证服务架构 单点登录系统提供的认证服务是基于JAAS(Java认证与授权服务)框架的。 31 JAAS是Java 2平台标准版(J2SETM) 1.4规范的组成部分，它提供认证与授权服务的应用编程接口与服务提供者接口，但单点登录系统只使用了JAAS的认证接口。应用开发人员不直接使用JAAS，而是使用单点登录系统的认证应用编程接口。 单点登录系统提供Java和XML/HTTP两种应用认证接口。Java认证接口可以在本地或远程调用。在本地调用Java编程接口直接与JAAS认证API交互，在远程调用Java编程接口则实际通过XML/HTTP与认证平台的认证服务交互。XML/HTTP认证接口提供了与语言和平台无关的方式对认证服务进行远程访问。 单点登录系统的认证模块是以插件的方式实现的，多种认证模块通过JAAS服务提供者接口与单点登录系统相连。这种基于插件的认证模块实现方式使得单点登录系统能够支持已经广泛应用的各种标准认证方式，也支持客户自行定制的认证方式。 下图显示了单点登录系统认证服务的架构。 32 4.1.4.4.2. 应用认证接口 单点登录系统仅为应用程序提供两种类型的认证编程接口。对基于Java的应用系统(包括基于JSP的WEB应用系统和基于Java的应用程序)可以使用Java编程接口;对于非Java的应用系统，可以使用XML/HTTP编程接口或C/C++编程接口。 如果仅使用SUN Access Manager API接口，存在诸多限制: 1、操作系统限制:C/C++接口目前只能稳定运行在Solaris系统中，其他主流的UNIX/Linux系统不支持 2、XML解析复杂:对于非Java和C/C++开发的系统集成来说，集成应用 33 需要编写了解复杂的XML结构，编写XML解析程序 3、集成系统开发工作量大:集成系统采用API模式集成时不但要完成SUN API复杂的过程配置，还需要进行通讯多线程的处理，在双机环境下还需要大量的编程支持动态切换 4、平台升级困难:直接采用SUN API集成，每个集成应用都与底层平台紧密耦合，当平台升级时，需要每个应用重新进行修改，无法保证整个系统的平滑升级。 为了解决这些问题，我们采用ICE(Internet Communications Engine)中间件平台自主开发各类认证接口。ICE是一种面向对象的中间件平台，采用了一种用于使对象接口与其实现相分离的基础性抽象机制，为构建面向对象的客户,服务器应用提供了工具、API 和库支持。在客户机与服务器之间建立合约，描述应用所使用的各种类型及对象接口。这种描述与实现语言无关，所以编写客户所用的语言无需与编写服务器所用的语言相同，很适合中小学的多语言集成环境。 其架构图如下: ICE认证接口是架设在集成应用和身份认证平台之间的中间件，支持大多数的主流Unix/Linux平台与MS Windows平台，集成应用系统开发人员无需面对复杂的XML解析，只需要一个对象(类)就可以完成所有认证相关操作，ICE认证接口API是线程安全的，开发人员无需额外的付出就可以获得高效的多线程功能。在架构上ICE接口的存在使得各个集成应用和统一身份平台是非紧密耦合，在代码层统一身份平台的对外接口升级变化将不会影响到各个集成应用，增加了整个系统的稳定和扩展性。同时ICE也支持统一身份认证平台的双机热备模式，能够动态进行切换，集成应用无需付出额外工作考虑平台状态问题。ICE认证接口增加了系统监控功能，通过配置，可以在系统出现问题时发邮 34 件通知系统管理员。 我们的架构为应用开发者提供诸多重要优势: 面向对象的语义 ICE“在线路上”完全保留了面向对象范型。所有的操作调用都使用迟后绑定，所以操作的实现的选定，是根据对象在运行时的(而不是静态的)实际类型决定的。 支持同步和异步的消息传递 ICE 提供了同步和异步的操作调用和分派，通过ICEStorm 提供了发布,订阅消息传递机制。这样，可以根据应用的需要来选择通信模型，而不必把应用硬塞进某种模型里。 支持多个接口 通过facets，对象可以提供多个不相关的接口，同时又跨越这些接口、保持单一的对象标识。这提供了极大的灵活性，特别是在应用发生演化，但又需要与更老的、已经部署的客户端保持兼容时。 机器无关性 客户机及服务器与底层的机器架构屏蔽开来。对于应用代码而言，像字节序和填充这样的问题都隐藏了起来。 语言无关性 客户和服务器可以分别部署，所用语言也可以不同。 客户和服务器所用的Slice 定义建立两者之间的接口合约，这样的定义也是它们唯一需要达成一致的标准。 实现无关性 客户不知道服务器是怎样实现其对象的。这意味着，在客户部署之后，服务器的实现可以改变，例如，它可以使用不同的持久机制，甚至不同的程序设计语言。 操作系统无关性 ICE API 完全是可移植的，所以同样的源码能够在Windows 和UNIX上编译和运行。 线程支持 35 ICE 运行时环境完全是线程化的，其API 是线程安全的。作为应用开发者，除了在访问共享数据时进行同步，无需为开发线程化的高性能客户和服务器付出额外努力。 传输机制无关性 ICE 目前采用了TCP/IP 和UDP 作为传输协议。客户和服务器代码都不需要了解底层的传输机制，可以通过一个配置参数选择所需的传输机制。 位置和服务器透明性 ICE 运行时环境会负责定位对象，并管理底层的传输机制，比如打开和关闭连接。客户与服务器之间的交互显得像是无连接的。如果在客户调用操作时，服务器没有运行，你可以通过ICE Pack 让它们随需启动。服务器可以迁移到不同的物理地址，而不会使客户持有的代理失效，而客户完全不知道对象实现是怎样分布在多个服务器进程上的。 安全性 通过SSL 强加密，可以使客户和服务器完全安全地进行通信，这样，应用可以使用不安全的网络安全地进行通信。你可以使用Glacier穿过防火墙，实现安全的请求转发，并且完全支持回调。 内建的持久机制 使用Freeze，创建持久的对象实现变成了一件微不足道的事情。ICE提供了对高性能数据库Berkeley DB 的内建支持。 认证头 目前我们已经实现了对JSP、ASP、PHP、Java、C、C#、VB等多种语言的接口，并可方便的扩展对Python、Ruby、C++等语言的支持。集成应用系统的环境包含IBM WebSphere、Domino、Tomcat、Apache等主流服务器。 提供适用主流开发语言的认证接口，包括Java接口、PHP接口、COM接口，该集成模式只要求各系统简单修改认证部分，就可以具备以下功能: , 校验当前用户是否是统一身份认证平台合法用户。 , 如果用户身份不合法则跳转到登录页面。 , 如果用户身份合法则无需登录，直接访问集成应用。 , 将用户属性信息传递给集成应用。 36 代理认证 对于中小学中不易改造的应用系统，可以引入代理集成机制，被集成的应用系统无需更改即可实现单点登陆功能。 代理认证是嵌入到目标系统中的程序，可以在不改动原有应用代码的前提下实现如下功能: , 校验当前用户是否是统一身份认证平台合法用户，并判断是否有权访 问请求的应用; , 如果用户身份不合法则跳转到登录页面; , 如果无权进入此应用则出现拒绝进入的页面; , 如果用户身份合法则无需登录，直接访问集成应用; , 将用户属性信息传递给集成应用。 LDAP认证 对于中小学中高并发认证型应用的集成需求，比如选课系统，我们针对这种类型系统的特点开发了LDAP的接口，支持标准的LDAP V3协议，能够满足短时间内上万人次的认证，并具有高稳定性。目前LDAP接口支持JAVA/C/PHP/.Net等开发环境。实现如下功能: , 校验用户名/密码; , 获取用户属性信息。 4.1.4.5. 跨域单点登录和联合互信 采用联合互信(Liberty Alliance)的Federation SSO标准实现跨域的SSO。 我们前面所描述的单次登录解决方案，都是建立在同一个厂商提供的解决方案的基础上，例如AM实现跨系统的单次登录。但是，在现有的学校中，有可能会有来自于不同厂商的网络身份管理方案;另外，学校也不可避免地需要和学校外的应用系统交互，此时，跨不同厂商的应用系统间的单次登录就会成为一个问题。 许多身份与策略服务，包括身份认证、单点登录和用户自定义，都是联合互信项目正在举行的标准化行动的主题。其目的是产生联合身份系统。联合身份系统确保合适的方面而不是一个中心机构来对重要个人信息的使用进行管理 37 和分配。联合互信项目是一个商业联盟，其组建目的是提供和支持一个因特网身份解决方案，以一种开放、联合的方式，实现单点登录。联合互信有三大目标: , 允许个人用户和机构保证个人信息的安全。 , 使用多家提供者的分散认证和开放授权，提供通用、开放的单点登录 标准。 , 为横跨所有网络设备的网络身份提供一个开放标准。 联合身份实现了联合商务的开发，这还可以让企业为学校或最终用户带来更多的方便、选择，并让他们更好地控制自己的身份。另外，联合身份模型允许学校或用户管理自己的数据。例如，某用户在学校的UID为109886，而在网络招聘系统中的UID为120821363。学校的网络身份管理系统采用我们的单点登录系统，网络招聘系统采用的是另外厂商的方案，当在这两个系统中实现SSO时，如果对方同AM一样，符合联合互信的SAML规范，跨系统的SSO就可以实现。 单点登录系统遵循Liberty Alliance Phase 2 和SAML1.1 规范。它对这些标准的支持帮助创建了一个既简便易用又与现有系统兼容的联合框架及验证共享机制。 4.1.5. 系统部署说明 身份认证平台支持双机或多机运行模式，一方面能够保证系统的可靠性，另一方面也能够保持良好的扩展能力，支持如下图的部署架构: 38 根据实际测试情况，身份认证平台的处理能力主要取决于处理器数量和内存数量，系统完全可以满足20万用户的数据存储要求(20万*0.5M/用户=100G存储容量)，并可以保持较高的处理性能，平均延时小于1秒，完全能够保证同时有超过5000(5000*1M/用户=5G内存容量)的用户同时在线使用。 建议采用以下系统安全措施提高系统安全性: 安全分类 安全措施 支持身份认证平台管理员账号和操作系统分离 主机安全 支持Unix、Linux等安全性高的操作系统 传输安全 支持HTTPS的加密传输机制 身份认证平台为各接入系统开设不同的访问用户 可以设置数据同步服务对权威数据源的访问账号的读写权限 建立对用户的登录和注销行为的系统日志，可以跟踪非法用户的入侵和合法访问安全 用户的非法攻击 系统只使用以下端口:系统管理端口58080，LDAP访问端口389，认证服务 器端口20000 所有用户口令采用高安全不可逆加密存储 存储安全 所有涉及到对其他数据库访问的账号配置采用加密存储 支持用户数据在线备份，和系统快速恢复 安全管理 企业安全管理考核细则加油站安全管理机构环境和安全管理程序安全管理考核细则外来器械及植入物管理 支持用户口令强制定期变更 39 4.1.6. 平台可靠性和扩展性 为确保系统7*24小时运行，可采用双机运行模式，一台服务器停止运行后，另外一台服务器能够不间断自动切换，不影响业务系统的正常运行。 同时在硬件层通过RAID1保证所存储用户身份数据的可靠性，并在系统管理上支持用户身份数据的在线备份和备份数据的定期远程上传，保证在硬件层故障时，管理员可以快速进行系统整体恢复。平台的数据存储可以根据实际数据量通过扩充主机磁盘容量的方式进行扩展。 4.2. 统一信息门户平台 统一信息门户平台(Portal)，就是将各种应用系统、数据资源和互联网资源集成到一个信息管理平台之上，它把分立系统的不同功能有效地组织起来，为各类用户提供一个统一的信息服务入口，并提供高可配置的功能，提供WEB网站页面风格、布局、内容等方面的定制工具。 4.2.1. 设计要点 智慧校园涉及教务、人事等多个业务系统，每个业务系统都会提供用户不同的信息服务，而且在各系统中也存在多个应用子系统，每个子系统也都会提供不同的服务界面。为提高易用性和一致性，需要在校内建立统一的信息服务门户平台，通过该平台重点解决以下几方面的问题: 统一信息门户平台重点解决以下几方面的问题: (1)提供符合师生使用习惯的高效、可靠的平台; 2)提供符合通用标准的、可持续升级的框架; ( (3)提供各种WEB应用系统与门户系统集成的手段，完成不同应用系统的界面集成; (4)提供安全的凭证登录手段，用于实现对外部系统和内部无法改造系统访问时的单点登录; (5)提供满足用户个性化使用需求的界面自定义功能; (6)提供门户应用开发框架、工具的支持，解决学校一些非系统级应用的 40 快速实现要求。 4.2.2. 平台框架 信息门户平台架构如下: 从功能上来看信息门户平台有六大部分组成: , 门户基础框架，提供标准的运行和开发框架 , 应用集成插件，用于满足校内外各类WEB应用的界面集成需求 , 内容管理模块，提供统一的内容采编、审核和发布管理 , 个人服务模块，用于满足师生用户个人资料管理的服务需求 , 公共服务模块，用于满足面向公众的信息互动和共享需求 , 协作服务模块，用于满足人员之间、业务之间协同工作的需求 4.2.3. 门户运行环境 提供符合Portlet1.0规范的门户运行支撑框架; 提供标准的Portlet开发接口，支持门户应用的快速开发; 提供频道、栏目、页面、内容的管理功能，用于管理员创建不同主题的缺省网站; 需提供个性化定制界面功能，支持管理员对界面的配置，在界面中修改布 41 局、样式、栏目和栏目的位置，同时支持个人用户自主管理自己的缺省界面; 提供对Portlet应用的在线部署，在不影响已有应用运行的情况下加载新应用，或对已有应用进行更新和卸载; 提供分类Cache监控管理功能，管理员可以有针对性的监控Cache使用状况; 提供单点登录服务，集成统一身份认证及权限管理平台; 提供信息门户备份和恢复的功能，保障系统的可靠运行; 提供日志、审计、监控、统计分析功能。 4.2.4. 平台主要功能 4.2.4.1. 应用管理模块 信息门户平台提供了完善的应用管理工作，包括应用注册、应用信息管理和应用负载管理。 应用注册:在门户内注册新的应用。应用只有在门户注册后，用户才能够通过门户访问;门户支持portlet应用系统在信息门户的注册和管理，供用户使用。 应用信息管理:管理应用系统的相关信息，如管理员、有效期等。 应用负载管理:信息门户基于应用服务器集群环境实现负载均衡管理，可部署多个平台实例，支持大规模用户访问。 系统监控:监控系统访问信息，提供系统日志，方便管理员有效量化管理。 4.2.4.2. 应用集成套件 URL资源管理插件，提供对URL资源类和资源明细的维护和授权，基于所维护的URL资源管理，可以灵活定义不同的URL资源显示栏目，用于支持不同应用系统的菜单级集成; , IFrame集成插件，支持嵌入其它系统的页面，用于实现和其他网站界面的 无缝集成，并可以控制集成后栏目的表现形式; 42 , WebClipping集成插件，可以对应用服务器访问到的页面进行区域裁剪，裁 剪后的内容作为门户的栏目进行统一管理; , URL集成插件，支持服务器级的高效集成，包括对网站或其他门户栏目的 集成; , RSS集成插件，支持自动从其它符合RSS(Really Simple Syndication，简易 信息聚合)规范的网站或门户采集到需要的数据，并定义相应的展现方式; , 凭证登录插件，支持用户实现对外部网站或内网不能实现身份集成网站的 单点登录功能; , JSP编辑器插件，对数据库查询进行安全封装，支持在线JSP编辑，供开发 人员和管理员快速开发一些数据库查询发布应用。 4.2.4.3. 个性化Web桌面 , 提供栏目管理功能，支持管理员增加新的栏目，修改或删除已有栏目，同 时提供栏目分组管理功能用于方便管理员对栏目的管理; , 提供栏目授权功能，支持管理员实现按栏目授权给用户组或用户的功能; , 提供内容页管理功能，用于管理员创建不同主题的内容页，同时支持二级 内容页的定义; , 提供页面风格扩展功能，支持管理员灵活扩展用户可选择的页面风格; , 提供最终用户个性化定制功能，最终用户可以自主选择页面风格，并自主 定义自己的内容页; , 提供站内搜索服务，支持最终用户可以通过关键字和内容进行搜索。 4.2.4.4. 内容管理子系统 , 内容分类设置，提供内容类的内容属性、显示风格设置，并支持分级管 理，由分级管理员完成子类的管理; , 审批流程定义，提供管理员根据不同内容分类定义审批流程，以满足不同 类型内容的不同审批权限和审批级别; , 内容编辑功能，提供所见即所得的编辑方式，支持在线编辑、本地编辑和 43 引用链接三种，满足不同场景下的内容快速录入需要; , 内容审批功能，提供审批人员待审批内容列表，对于每项审批内容可以直 接修改，也可以使用批注，以提高审批效率; , 内容发布功能，对于通过审批的内容，发布负责人可以设置发布的有效 期，支持预发布和实时发布; , 内容归档功能，根据所发布内容的特征，由系统自动进行归档存储，并对 所归档内容提供查询和统计; , 可与学校主页有机整合，共享新闻、通知、公告等网站信息; , 支持整合学校各部门的二级门户网站，构建独立门户。 4.2.4.5. 个人服务子系统 , 个人记事本，为用户提供网络记事服务。并提供查询、搜索功能; , 个人文件夹，根据个人权限分配网络空间，用于上传、下载、检索个人电 子资料，并可以按文件或目录授权给好友或指定用户共享;建议学生每人 分配200M空间，教师可以分配1G空间; , 个人相册管理，提供相片数据的上传、维护，提供图片按比例在线浏览， 同时用户可以按相片文件或目录授权给好友或指定用户共享; , 新闻浏览器，提供RSS新闻浏览服务，自动收取各新闻网站的RSS新闻内 容; , 个人收藏夹，提供给普通用户使用，用户可以在网上管理可用的网络书签 资源; , 个人主页(博客)，提供给每个用户一个个人主页空间，用户可以发表文 章、评论、标签等Web内容。 4.2.4.6. 公共服务子系统 , 公共信息服务，提供校内公告通知、网上调查，天气预报、出行查询等; , 网上投票，提供网上投票定义、按用户组授权功能，调查表格可按需扩 展，并提供图形化统计和分析功能，用于收集特定群体对特定问题的看 44 法，可按权限发布详细投票信息; , 图文广告，提供多种表现形式的广告管理，用于基于门户发布各类广告信 息; , 公告管理，提供管理员和授权人员依据通用的模式维护公告列表和公告内 容，同时提供按列表的批量公告发布和单条目的公告发布。 4.2.4.7. 协作服务子系统 , 日程管理，提供用户行程日历，在日历上实时标识每日工作安排，同时提 供对外服务接口，实现和其他业务系统行程安排整合; , 待办事宜，为登录用户提供待办任务提醒和管理，提高网上工作协作能 力; , 网络留言，通过该服务实现网络留言和答复功能，解决个人不在线时的工 作协作。 4.2.5. 平台部署及性能说明 信息门户平台部署在标准J2EE应用服务器之上，支持在单台服务器上的垂直扩展、在多台服务器的上水平扩展，垂直扩展可以提高系统运行的可靠性，水平扩展可以线性提高性能，如下图所示部署架构: 45 基于上述结构，系统在以下测试环境中的性能情况如下: 测试环境 环境 说明 网络环境 在实验室局域网内，网络带宽100M 服务器 :2CPU 主频3.2G Xeon、2G RAM 硬件环境 客户端1:2CPU 主频为1.6G Xeon、4G RAM 客户端2:1CPU 主频为2G P4、512M RAM 服务器操作系统为:RedHat AS 3.4 操作系统 客户端操作系统为:Win2000 数据库:Oracle 10g 系统软件 应用服务器:WebSphere 6.0 ND 测试方法 在2分钟内仿真200用户持续访问门户指定页面，页面内容为194K 测试结果 46 根据上述测试结果，在单台2颗Xeon 3.2G CPU、2G RAM的PC服务器平台上，门户服务器平均处理能力能够达到132.11RPS;100个并发访问时，每秒可处理50个访问请求，平均响应时间1.9秒，在2分钟内可以处理15000次以上的用户访问请求，页面访问速度小于3秒，并发用户支持2000 人，在线用户支持2万人。 4.2.6. 平台可靠性和扩展性说明 信息门户平台采用以下技术保证系统的可靠性和可扩展性运行: , 支持在一台应用服务器内部的垂直扩展，可以根据应用服务器内存状况， 同时创建多个服务实例，在一个服务实例故障时，其他服务实例能够自动 接管相应的用户访问请求 , 支持在多台应用服务器之间实现水平扩展，并可以根据各服务器的处理能 力设置相应的负载权重，在一台服务器故障时，其他服务器能够自动接管 相应的用户访问请求 , 支持门户单个应用的在线加载和更新，某个应用出现问题时，可以在服务 不停的情况，实现对该应用的更新 4.2.7. 平台安全性考虑 安全分类 安全措施 网络安全 支持应用服务器部署在内部网络，通过HTTPServer提供对外访问 门户系统管理员可以配置为统一身份认证及权限管理平台中的指定用户，不 存在对操作系统用户的依赖 主机安全 支持对门户系统管理员账号强制定期变更 支持Solaris,Linux等安全性高UNIX操作系统 传输安全 支持HTTPS的加密传输机制 对统一身份认证及权限管理平台的访问账号是受限账号 访问安全 对相关数据库的访问账号是受限账号 系统只使用J2EE服务器标准端口 所有涉及到对其他数据库(系统库、业务库、共享库)的访问的账号采用加密 存储 存储安全 对统一身份认证及权限管理平台的访问账号采用加密存储 对于采用凭证登录和凭证登录的Portlet应用,其登录凭证采用加密存储 47 4.3. 数据中心平台 数据中心建设可以分为三个阶段，第一个阶段主要是公共数据库的建设，其目标是集成学校现有和即将建设的应用，标准化学校的相关数据，提供部分针对具体业务的查询和报表。第二阶段主要是数据库应用建设，其目标是对学校的数据资产进行盘活，提供面向全局的数据展示服务。第三阶段主要是数据仓库建设，其目标是根据学校的具体需求和数据情况提供高层次的数据服务，加强学校的核心竞争力。 公共数据库平台的建设须依据数据中心整体架构，考虑未来数据应用需求，建设一个面向未来的、先进的数据平台。 数据中心实现数据存储、数据交换、数据服务、数据处理功能，主要为学校的数据集成与应用提供一个综合性的支撑平台，数据中心应基于学校的具体需求建设，面向学校的综合信息服务，为未来构建新的业务应用提供强大的数据平台和服务平台。 智慧校园系统的数据交换系统将通过CIF(客户信息系统)传输层(JMS接口，JAVA消息服务接口)的数据交换方式在区域内、代理之间通过两种方式共享数据:发布/订阅和请求/应答。代理将订阅者感兴趣的数据变化(CIF_Event消息)发送给区域综合服务，从而实现发布过程。代理也可以向区域综合服务发送CIF_Request消息，请求应答结果，最后将收到一个或多个CIF_Response 应答消息，实现与教育资源网、CMIS系统、教委体系原有应用系统或机构信息系统、新构建的应用系统之间进行快速、安全的数据交换。如下图所示: 48 数据中心建设重点分为以下三个方面: , 建设全局数据集成与应用集成中心 数据中心以数据的集成与应用的集成为目标构建综合性的学校应用中心，使业务系统完成从以技术为中心向以数据为中心的方向转变。 , 提供多角度、多层次的数据服务 数据中心基于开放的标准与规范，通过OLTP(联机事务处理)、OLAP(联机分析处理)数据处理相结合的手段实现各种数据服务，使学校业务和管理系统在战略层面、战术层面、操作层面、运营层面都能为相关各类用户提供更好的支持和服务。 , 保护投资，增强现有应用 数据中心对现有的信息技术资产具有兼容性，可以保护已有投资、避免重复构建，提供对专有系统的集成能力，提高已有系统和新系统的可靠性、模块化、可扩展性、可伸缩性和稳定性。 49 4.3.1. 技术路线 数据交换平台是智慧校园核心技术支撑平台的重要组成部分，是整个系统的信息传输、信息交换总线。通过数据交换平台将各业务系统数据库中需集成的数据自动上传到共享数据库中，并按各业务系统的订阅需求将共享数据分发到各业务系统，从而实现数据的统一集成和标准化，为提供数据的综合查询、统计分析奠定数据基础。同时，保留各业务系统的原有数据库，确保各业务系统的完整性。 目前，数据交换平台底层技术的选择有两种技术路线:一种是单纯满足数据交换需求，强调数据集成能力，简化适配器开发，例如Oracle数据集成器(ODI);另一种是采用EAI(Enterprise Application Integration，企业应用集成)方案，在SOA(Service-Oriented Architecture，面向服务的体系结构)架构模式下，实施服务总线ESB(Enterprise Service Bus，即企业服务总线)，强调设计架构，需要大量开发适配器，但是能为学校奠定一个有效的SOA架构基础，并且从数据集成开始做起，积累经验，例如SUN CAPS就是这样的解决方案。 首选方案是以CAPS为基础的服务总线模式设计，同时不局限于CAPS的能力，还参考了EAI领域的Tibco、Vitria等知名公司的解决方案。超越CAPS的这部分功能需要另外开发实现。 4.3.2. 设计要点 根据中小学的实际情况和需求，数据交换平台设计应该考虑以下要点: 1、遵循统一的数据交换标准 数据交换平台的目的是在数据中心和各业务部门原有业务系统之间交换数据。由于各业务系统的技术构架和信息表示不同，要在这些系统之间交换数据，首要的问题就是定义一种标准的数据格式及数据交换的规范，以方便实现不同硬件平台、不同操作系统平台、不同语言平台应用之间的平滑通信。 2、支持异构系统、异构数据库的交互及数据存取 数据交换首先涉及到如何与各部门、各异构系统及其异构数据库进行交互，实现数据的存取。 50 能够对各部门、各业务系统的数据库定义数据抽取规则，从而实现自动地从各级部门的数据库或相应业务系统中抽取共享数据库所需的数据。数据存取的需求具体可归纳为: , 支持多种异构数据库，如主流的关系型数据库包括:Oracle、SQL Server、 DB2、Sybase等; , 集成各种异构的业务系统，通过接口实现应用交互和数据存取，如 WebService接口、文本型数据库接口; , 能够根据定义和规则，自动捕获数据的更新和变化。 3、信息传输 , 支持灵活的数据交换方式:可以根据不同部门的情况，对于不同类型的数 据有不同的更新要求，可分别采取多种数据上传的方式，比如，对于信息 变更频繁的数据，能够实现实时更新;而对校园中变动不是很频繁的数 据，如人事数据、设备数据，则实现定时更新，如可定义每日上传一次， 或每周一次。对于数据上传的时间，也可灵活定义，如为了避开网络高 峰，减少对系统的影响，可定义在晚间及凌晨等系统和网络均比较“空 闲”的时候来进行数据的同步。 , 大数据量的支持。 , 支持跨平台、跨多种网络模式的分布式数据交换。 , 可靠和安全。 4、数据转换 平台能够适应各系统数据内容和格式的变化，提供可视化的转换配置界面，并实现各系统数据与中心标准数据之间灵活的转换。 5、能够对交换数据进行验证和质量控制，比如: , 能够根据一定的规则，进行数据验证，验证数据是否符合入库要求。 , 提供完善的日志。 6、数据交换的安全 支持对敏感数据进行加密传输。 51 4.3.3. 平台框架 系统主要由以下部分组成: , 业务应用集成 , 数据集成 , 信息总线 , 安全控管 , 信息模型 , 业务流程管理(包括了数据整合服务、信息服务) , 监控管理平台 首先通过数据交换平台提供的大量现成的连接器/适配器实现与各种异构的 业务系统的快速连接与无缝集成，从而实现对业务系统的集成。另外，通过数 据库连接器及文件连接器，能够实现与主流的关系型数据库和文件系统的数据 交换，完成各种数据的存取操作。 在应用连接、数据库连接的基础上，由信息总线或消息总线来负责在所有 系统之间传输、路由数据和消息，实现数据、服务、命令的上传与下达。信息总 线还实现了多级平台之间的整合和集成。 安全控管则统一管理整个共享数据库平台的安全和权限服务，保证整个集 成平台的安全可靠。信息模型对整个平台中流转的数据和服务请求进行标准化 的建模，是整个集成平台的统一数据标准和服务接口标准，从而为业务系统的 集成和未来可能增加的新业务系统提供技术框架，奠定现有系统和未来系统 “即插即用”的基础。现有系统和未来新增的系统，只要符合相应的数据框架和 服务接口框架，即可以“即插即用”的方式融入到整个集成平台的运行体系之 中。 数据整合流程实现数据交换的统一调度，整合了关键业务流程，这些关键 业务流程跨越不同业务系统和数据库，并按照预先定义好的规则完成数据转 换、验证、入库。数据整合流程对各个业务系统和数据库按需进行协调和调 度，完成各项数据整合工作。 信息服务整合了各业务系统的数据请求，负责将管理数据从各业务系统中 进行实时抽取，为各业务系统的数据请求提供支持，实现数据在异构业务系统 52 之间的共享，并为报表分析系统提供数据来源。 监控管理平台提供强大的数据流、业务流的监控、分析及优化功能，能够集中、远程、统一管理整个集成平台和运行系统，并实时获得系统运行、运行数据、运行流程的状态。 整个体系结构能够完全满足共享数据库平台建设的需要，既实现了横向的整合(也即流程整合)，也实现了纵向整合(也即数据整合)。并且充分考虑了系统的可扩展性，提供了共享数据库平台信息共享、互连互通的整个应用支撑框架，既能够对现有的应用和数据进行集成与整合，又为后续的业务应用开发奠定了强大的支撑。 4.3.4. 应用集成与数据集成 共享数据库平台首先涉及到如何与各级部门、各异构业务系统及其异构数据库进行交互，实现数据的存取。应能够对各级部门、各业务系统的数据库定义数据抽取规则，从而实现自动地从各级部门的数据库或相应业务系统中抽取共享数据库所需的数据。 业务系统及其数据库是异构的，实现架构各不相同，有C/S结构和B/S结构;实现技术也异构。 数据交换平台提供了大量功能强大的现成的连接器，能够充分实现与这些系统、这些技术体系的快速连接和交互。在实现时，只需适当地配置产品化的连接器即可，无需编码。 根据不同业务系统的技术架构和接口方式，可分别选择合适的适配器与之连接，实现对这些系统的集成，并最终接入到信息总线。 样，数据的集成是通过现成的数据库连接器和文件连接器来完成的。如同 下图: 53 数据交换平台包含众多成熟并经过了实际项目检验的连接器。主要包括: , 数据库连接器:支持主流常见数据库，如 ORACLE, DB2, SQL SERVER, SYBASE等; , 协议连接器:支持各种通讯协议标准，如HTTP、HTTPS、FTP、SMTP、 POP3、SMS 、SOCKET、文件传送、IIOP(Internet Inter-ORB Protocol，互联网 内部对象请求代理协议)、RMI(Remote Method Invocation，远程方法调用)、 SOAP(Simple Object Access Protocol，简单对象访问协议)、JMS等; , 技术连接器:如Web Service等等。 数据交换平台提供的连接器还支持以下接口技术: , J2EE接口:数据交换平台每一个组件都提供J2EE/RMI接口供其它系统调用， 同时, 数据交换平台也可调用其它J2EE系统; , Web Service接口:数据交换平台每一个组件都可作为一个Web服务供其它系统 调用;同时，数据交换平台也可调用其它Web Service界面，接口定义是WSDL (Web Services Description Language，Web服务描述语言)。 数据交换平台连接器可根据消息获取方式的不同分为两大类: , 主动向业务系统获取数据; , 业务系统更新数据触发事件，向连接器发布数据，连接器实时获取变更的数 据。 数据交换平台连接器满足JCA(J2EE Connector Architecture)标准，JCA提 供的多种开放标准或规范的接口技术，不仅为插件的开发提供了灵活性，而 且，为整个系统的开放性奠定了坚实的基础。 54 数据交换平台连接器可自动探测并捕获应用中的变化，将信息转换进入数据交换平台，然后以原来的数据格式送回到应用中，通过图形连接模型可容易地建立应用连接，并进行修改。根据不同的系统, 可以选用适当的接口方式和具体的连接器。 除此之外，数据交换平台还基于JCA的框架提供二次开发所需的SDK，包括开发适配器的全套Java和C，，的API，提供对自主开发的应用的广泛支持。 4.3.5. 数据交换机制 根据应用规模及应用内容，选择数据交换平台技术体系结构时最重要的是跨平台性、安全性、可靠性、稳定性及可管理性，同时要有良好的可扩展能力。数据交换平台的开始阶段主要实现数据的单向集成，即数据由各业务部门单向上报至数据中心。随着应用的推进和深入，管理的资源将会非常丰富，不但需要考虑将来可能的双向数据交换，还应考虑到进一步的应用集成乃至业务流程的集成。 结构如下图: 55 如上图，我们可以建立中心与业务部门两级的数据交换平台。整个数据交换平台可分为两个重要的组成部分，一个为数据交换中心 (SmartExchangeServer)，是部署在数据中心的数据交换中心服务，另一个是数据交换代理(SmartAgent)，是部署在各个部门的数据交换代理程序。数据交换中心和各个数据交换代理通过数据交换平台实现相互连接，提供了从业务部门的子数据库系统向中心综合数据库系统进行数据同步复制的能力，同时，该平台还为后续的扩展提供了基础，也即各业务部门子数据库系统也可以根据预先配置的服务，接收到共享数据库的数据库信息，通过数据交换平台完成数据的双向传输、同步，实现数据的复用。另外，实现了对整个数据交换平台的集中管理和统一管理，并保证了整个数据交换平台系统的灵活性和充分的可扩展性。 数据交换中心是数据集成、交换的中枢。主要实现以下功能: , 统一管理和调度各数据交换代理，为地域分布的客户端提供统一集中管理功 56 能。 , 建立统一的数据模型。即根据共享数据库的格式，统一数据的标准，具体创 建、管理和维护元数据。 , 定义数据转换关系。即定义各业务部门数据与中心标准数据之间的转换关系。 , 在数据模型的基础上实现数据有效性验证和数据质量控制。 , 实现数据的自动汇集与入库。 , 提供统一的安全控制管理机制，为整个分布式异构数据交换平台提供安全保 障。 , 对整个数据交换平台的进行管理和监控。实时地监控数据交换流量、异常报告 等。 数据交换代理主要负责数据按规则抽取和数据可靠高效地上传。 数据交换代理通过适配器实现与各种异构数据库、异构业务系统的快速连 接与无缝集成。如通过数据库源适配器(RDBMS Source 连接器)与不同的数据 库进行连接，并自动检测数据的变化(增、删、改)，实时捕获变化的数据。数 据交换代理的业务调度模块基于强大的业务调度功能来定义数据的抽取规则、 数据的路由规则、数据的传输规则，提供不同业务部门不同的数据抽取需求、 不同的数据传输需求的强有力的支持，并能够通过图形化的界面快速创建或改 变规则，最大限度地提供充分的灵活性。数据交换代理同时提供了系统运行的 监控和管理功能。 数据交换中心和数据交换代理之间，通过消息中间件通讯器进行集成，两 级通讯器之间通过数据联邦功能实现数据的单向或双向传输，从而构成可靠、 高效、安全的信息传输总线。 如下图所示，整个数据交换平台的逻辑实现可看作三大部分，数据交换中 心、数据交换代理和消息传输总线。 57 下面描述业务部门数据从业务系统经过数据交换平台到共享数据库的交换 过程: 1) 业务部门业务系统的相关操作，产生业务部门数据库的更新，如增加或 修改了相关的业务数据，并提交到业务部门数据库中。 2) 业务部门的数据交换代理通过各自的数据库连接器与业务部门业务数据 库连接。当业务系统的业务数据库发生变动时，数据库连接器能够捕 获数据库的事务变化，并基于预先制定的数据抽取规则，实时将满足 要求的数据变化信息发送到数据中心(或者业务系统定期将更新数据存 储为相应格式的文件放置在特定的目录下，文件连接器定时从特定目 录下读取数据文件)。 3) 数据交换代理的数据传输调度模块根据预先配置的流程及相关参数(如 数据传输周期、数据传输时间、数据的加密、数据的压缩)等规则来调 度和处理数据并最终把数据汇集到消息中间件通讯器的Channel中(可 58 靠消息渠道)。 4) 各业务部门数据代理的通讯器与数据交换中心的通讯器之间通过数据联 邦模式实现高效的数据交换，共同组成可靠、高效的信息传输总线， 完成两级数据交换。 5) 数据交换中心从信息传输总线接收变化的数据信息，首先进行必要的数 据调度处理，如解密、解压缩等。 6) 根据预先利用图形化工具定义的数据转换规则进行数据格式的转换，实 现数据的标准化。 7) 根据元数据规则及相关业务规则对数据有效性进行验证，实现对数据质 量的控制，并进行入库前的数据查重。 8) 最后数据交换中心的数据库连接器把符合标准的合格数据信息更新到中 心的综合数据库中。 此外，在整个数据交换过程中，数据交换中心的图形化监控管理平台能够 实时地进行监控。 4.3.6. 平台部署及性能说明 公共数据库平台支持如下图所示部署架构: 59 基于上述结构，既能够满足项目对核心数据库高安全性的要求，又能够满足和后续智慧校园系统进行数据交换的需求。 在这种结构下，系统的性能情况如下: 测试环境 环境 说明 本次测试在局域网中完成，网络带宽10M。局域网中还有大约30台网络环境 机器在同时工作。 服务器:CPU:P?700，内存:512M 硬件环境 客户端:CPU:P?700，内存:512M 服务器操作系统为:RedHat AS 2.1 操作系统 客户端操作系统WIN2000; 共享库:Oracle 9.2.0.2 数据库版本 业务库:Oracle 9.2.0.2 业务数据整合和共享数据订阅所采用的表共有45个字段，字段长度测试数据量 总和为1.5K。该表有191601条记录。一次处理最大数据流量为:191601 ×1.5K= 287401.5K,280M 测试结果 集成方作业 测试路线 测试内容 式 时间 业务数(1)基于业务库表ETL抽取从业务库中抽取191601条记录，操作4分钟 据整合 输入 类型为UPDATE/INSERT 60 (2)基于业务库视图ETL抽从业务库中抽取191601条记录,操作4分钟 取输入 类型为UPDATE/INSERT (3)基于业务数据源文件从数据文件中抽取191601条记录,操6分钟 ETL抽取输入(Access) 作类型UPDATE/INSERT (1)业务系统基于共享库数从共享库表中抽取191601条记录，操4分钟 据表的ETL 抽取 作类型为UPDATE/INSERT 共享库插入191601条记录，业务库刷2分钟 新快照 (2)基于共享库数据表的增 量快照输出 共享库更新其中3000条记录，业务库1分钟 刷新快照 (3)基于共享库数据表跨库Select count(*) from 操作 <1秒 视图输出 共享数(4)业务系统基于共享库视从共享库视图中抽取191601条记录，4分钟 据订阅 图的ETL抽取 操作类型为UPDATE/INSERT 共享库插入191601条记录，业务库刷2分钟 新快照 (5)基于共享库视图完全快 照输出 共享库更新其中3000条记录，业务库2分钟 刷新快照 (6)基于共享库视图跨库视Select count(*) from 操作 〈1秒 图输出 (7)基于共享库数据文件输依赖于业务系统开发的数据处理接口 出 程序。 61