[计算机软件及应用]LDAP目录数据完整性检验设计与实现.pptVIP

LDAP目录数据完整性检验设计与实现 西安交通大学信息与网络中心 韩博 bohan@xjtu.edu.cn 2006年10月19日 内容介绍 一、项目背景 二、技术目标 三、实现思路 四、内容和实现要点 五、未来展望 一、项目背景 1、“211”二期工程校园网子项目建设内容 2、数字化校园数据中心基础设施 3、目录服务管理子系统介绍 1、“211”二期工程校园网子项目 2003年规划 2005年10月开始执行，合作开发 原计算机网络与信息中心《西安交通大学校园网“211”二期建设规划》建设内容之一 目标：提供校园信息化支撑与服务 以数据中心的高度提出 非一次性建设项目 较长规划：按照5年需求概算 多次建设： “211二期工程”校园网分项完成部分内容， “985”二期工程数字化校园分项完成其他内容。 1、 “211”二期工程校园网子项目 拟按照校园数据中心的目标来建设，其基本结构如下： 2、数字化校园数据中心基础设施 解决当时得问题：整合学校MIS 绝大多数职能部门均独立建设 面向管理和面向服务一体设计 系统功能能解决部门自己的办公问题 部门业务处理已经离不开 使用相对稳定(使用惯性) 技术上存在的问题较多：安全　外部连接　扩展 改造困难：多为委托开发　部分开发过程不规范 已出现需要被整合的需求：特别在数据上和认证上 2、数字化校园数据中心基础设施 目标：打破部门之间信息孤岛 用户统一 数据共享 (统筹)为学校IT服务提供支持 方针：资源统一建设和管理 软件（后期投资少、自主性） 硬件（统筹建设、校内共享） 总体要求：降低学校IT成本，（一定程度上）提高IT水平 211二期完成的目录服务内容示意图 3、目录服务管理子系统介绍 该子系统的建设目标 实现用户认证信息的统一管理 实现单点登录样例。 实现基于角色的统一授权管理 3、目录服务管理子系统介绍-图 3、目录服务管理子系统介绍 系统的对象 附：统一授权管理的功能模型设计 3、目录服务管理子系统介绍 需要存储到目录的数据 学校的基础数据 用户、资源、角色、应用（表示）、组织机构 关系数据 基本数据之间的关系 例：用户——组织机构 资源——应用 3、目录服务管理子系统介绍 目录存储关系型数据 通过条目位置区分条目类型 通过条目属性存储参照信息 在条目之间设定其他关系 3、目录服务管理子系统介绍 产生的问题：目录数据的完整性缺乏保障 原因： 目录没有提供表一级的数据定义 目录保障属性的语法正确，并不做语义限制 无法保障用户自定义的条目间约束 二、技术目标 1、保障目录数据的完整性 2、保证目录的性能 3、适应性和灵活性 1、保障目录数据的完整性 关系数据的完整性要求 实体完整性 参照完整性 其他业务规则要求的完整性 1、保障目录数据的完整性 实体完整性 某目录下的条目必须具有某些对象类，可以具有另一些对象类，除此之外，不能再有其他类型的对象类 1、保障目录数据的完整性 参照完整性 条目A如果在某个属性值里引用另外一个条目B的DN，则B条目必须存在 举例： 1、保障目录数据的完整性 其他业务规则要求的完整性 通过RDN关联的条目 例：每个管理员的资源存储在另一个目录下的条目 管理员与这个资源条目之间通过相同的RDN联系起来 2、保证目录的性能 目录系统目标：100万目录对象 性能要求(10万实际用户数据) 测试环境下3秒/万用户并发 测试环境下1s/普通访问 需要保证目录的性能 数据不完整对系统的影响 多应用查询速度 锁定目录等问题 在应用系统中做验证可能要增加大量操作 3、适应性和灵活性 能够适应目录的变化 随着应用变化，目录可能需要变化 能够变动检查策略 不同的环境下需要不同的策略 例：实体完整性不需要每次都检查 参照完整性必须经常检查 三、实现思路 1、可能的方案 2、方案的选择 3、配置需求及策略 1、可能的方案 方案A：在应用系统中添加完整性检查 每次的更新操作都确保完整性 需要事务支持 增加系统响应时间 方案B：在应用系统外执行完整性检查 可周期性执行 可保证系统响应时间 系统在两次检查间隔内可能不一致 2、方案的选择 应用系统内部 仅保证提交的数据完整 应用系统外部 完整性的检查 周期（自动） 临时（手动或条件触发） 不完整数据的更正 自动（简单的删除、添加、修改） 手动（条目的创建） 3、配置需求及策略 检查内容 适应目录的变化 可进行有侧重点的检查 检查周期 发生概率低的不完整性 发生概率高的不完整性 检查策略 更正 记录 3、配置需求及策略 配置方式 XML (举例) 四、检查内容和实现要点 1、系统构成 2、配置文件及检查内容 针对实体完整性的配置、检查 针对参照完整性的配置、检查 针对业务规则要求的完整性的配置、检查 1、系