1前言
1.1项目背景
国内某市网上审批系统是由市级审批平台和区县政府审批平台两级平台组成。总体策略是先建立市级平台将各个市级委办局部门整合起来，然后在市级平台的基础上整合区县，将全市区县和市级集成成为一个整体。整个集成分成两个层面进行，首先进行用户管理的集成，由于市级平台和区县的系统建设是独立进行，所以都有自己的独立的用户管理系统，所以必须整合区县和市级用户管理，整合的前提是：一网注册、全市通行、独立管理；其次，是业务层面的集成，要求区县和市级能够进行业务协同、互联互通。这里重点介绍一下用户集成的思路和技术。
市级和区县采用的用户管理系统都是Novell eDirectory8.1系列。
1.2集成原则
用户集成主要指市级平台和区县政府审批平台外网申报用户的集成，实现申报用户一处注册，全市通行：就是说在区县注册的用户能访问市级在线服务平台，反之，在市级在线服务平台注册的用户能访问区县在线平台。
用户集成的原则主要有以下几点：
l 用户集成只针对外网的申报用户。
l 用户在一个平台注册后，在另一个平台也可以用有相同帐号登录。
l 用户需要到注册平台进行资料修改操作（通过提供注册平台链接解决跨平台修改问题）
l 全市用户标识唯一，通过注册平台后缀区分不同平台用户（用户标识有两部分组成：用户自定义的用户名＋注册平台后缀）
l 用户跨平台登录时，如果两个平台属性不一致，需要认证平台进行赋值。
1.3集成方式
目前，考虑到的用户集成主要有以下几种方式：
l 数据集成：指通过目录服务产品来实现数据上的集成，集成方案包括“物理数据集成”和“逻辑数据集成”。
l 应用集成：指通过应用层上进行用户注册、登录、认证等相应接口规范而不考虑数据实际存储的方式来实现集成。
考虑到全市各区县由不同单位承建，应用建设水平各不相同，所以推荐选择数据集成方案，下面重点分析数据集成方案。
2数据集成方案概述
2.1概述
数据集成主要是从数据的存储上进行集成，借助于目录服务系统，进行相应的数据存储和管理。基于目录服务的用户管理能够实现逻辑上统一，对应用透明，物理上分布，服务器分担处理的需要。
基于目录服务系统的数据集成方式，需要统一市级平台和区县平台目录体系管理方式，以及相应的用户属性，这一点需要通过定义全市统一的规范来保证实施。
数据集成方式可以通过两种方案来实现，包括：物理数据集成、逻辑数据集成。下面详细说明。
2.2物理数据集成
物理数据集成也称为多副本集成，即在任一区县（或市级平台）所在的分区均有其它分区的数据副本，进行数据查询的时候，只搜索一个分区数据就可以。当任意分区进行数据更新时，通过目录服务系统复制功能进行数据同步。
图一 物理数据集成
该方案的优点有：
1． 由于任一区县（或市级平台）所在的分区均有其它分区的数据副本，查询是在本地完成，因此数据查询、登录认证的效率高。
2． 数据存储备份多，任一区县的目录服务停掉不会影响其它区县的应用。
缺点如下：
1． 目录树上的任何一个对象的增加、删除、修改都要同步到所有的分区。对网络资源要求较高，系统开销教大。
2． 统一每个平台时间，需要有一台时间服务器，作为各分区目录服务的时间标准。
3． 广播式的同步会导致数据的意外丢失，不稳定。
4． 由于每一个树下有所有平台的数据，所以各树下的不同平台数据管理需要综合考虑加入维护权限、同步管理等手段，应用复杂度高。
2.3逻辑数据集成
图二 逻辑数据集成
逻辑数据集成也称为引用集成，即在任一区县所在的分区只有自己平台的数据。依据全市统一的数据目录管理体系实现不同分区的分布式管理，在进行数据查询、帐号登录时先检索本地分区，如果没有成功再检索其它分区的数据。
该方案的优点有：
1． 实现了逻辑上统一、物理上独立的分布式管理需求，单一分区的数据管理方式变更，不影响其他分区的应用。
2． 由于任一区县所在的分区只有根分区的引用，没有数据同步的系统开销。
3． 自主式管理，整棵树可以有一个总管理员，每棵子树有子管理员。子管理员只能对自己平台数据进行管理。
缺点如下：
1． 由于任一区县所在的分区只有根分区的引用，当检索其它分区数据时效率较低。
2． 数据存储单一，当任一分区的目录服务停掉时，可能会影响上层应用，导致该分区数据无法检索查询。
2.4方案选型
审批外网服务平台将由市级、各区级组成，数据集成的目的是实现一处注册、全网登录。从用户使用习惯上分析，多数用户应该会选择从注册地进行登录，所以异地登录人员数量不会太大，所以比较用户登录时对“检索速度”和“检索精度”的要求，应该更强调检索精度。此外，逻辑数据集成方案对用户的注册和登录实现分区的存储和搜索，其速度不会太慢，所以选择逻辑数据集成方案。下面将对实施逻辑数据集成时需要考虑的问题进行描述。
3实施规则
逻辑数据集成对系统的规范性要求比较高，在进行系统实施前，应充分全面考虑相关的规范与规则。而在系统实施中，用户集成主要从用户注册、登录、管理等三方面考虑，涉及到系统内部的目录结构组织、数据检索、数据维护等问题，下面将从以下几个方面进行详细描述：
l 用户注册规范：主要包括用户注册流程规定、用户命名规范、用户属性规范、用户存储规范等。
l 用户登录规范：主要包括用户登录流程规定、用户信息搜索原则等。
l 用户管理规范：主要包括用户信息管理规则。
3.1用户注册规范
用户进行注册时，考虑到系统数据物理分布，逻辑集中机制，确定了利用注册地后缀方式来区分不同平台的用户原则。因此，注册流程对用户来讲，和一般注册流程一样，而对系统内部来讲，存储数据的入口为系统所在的分区组织单元，而不是整棵树的根，进行数据存储的时候，一定要遵守全市统一的目录体系规范。注册流程参见下图：
图三 注册流程
涉及到用户注册的主要有以下几方面的规范：
l 用户命名规范。
l 用户属性规范。
l 数据存储规范。
3.1.1 用户命名规范
统一用户命名规范主要考虑跨平台用户认证以及增强用户资源地可管理性，用户名称是用来唯一标识用户的，对用户的命名有如下限制：
1． 用户标识包括两部分：用户名＋@＋注册地后缀，用户标识全市唯一。这样，用户在注册的时候，系统通过搜索对应的分区是否已存用户名即可，保存数据的时候要自动在用户名后面加上注册地后缀。
2． 具体的注册地后缀规则如下：
无后缀 表示市级 AB表示AB区
CD表示CD县 EF表示EF区
...
后缀采用注册区县中文拼音的前两位，市级平台没有后缀，不允许包括其他区县的后缀。
3． 用户名称作为用户的唯一标识，一旦生成，则不允许用户修改。
4． 用户名称的构成包括数字、字母、下划线“_”、以及汉字，不能使用其他字符（包括作为分隔符的@），长度必须大于6个字符，小于20个字符。
5． 用户名称不区分大小写。
3.1.2 用户属性规范
为了进行全市统一认证，必须对用户对象的属性进行规范，规范的内容有：
1． 各区县平台的用户类型分为一般用户类型、市民及企业。其中，各区县平台的协同办公平台用户属于一般用户类型，市民及单位用户为在线服务平台用户，且都继承一般用户类型的属性。详见用户类型表的schema定义
2． 用户的属性分为用户凭证属性、推荐使用的扩展属性、及各平台自定义扩展属性，其中，凭证属性是全市各区县平台及市级平台都能识别的用户身份凭证信息，推荐扩展属性分为ldap标准属性及已建设平台定义的属性。自定义扩展属性为每个平台自己独有的属性。详见用户属性表的schema定义。
3． 用户的属性的名称、数据类型、以及限制在数据层和应用层最好保持一致。
4． 用户进行注册时，注册平台负责录入用户所填的属性信息。用户进行登录时，认证平台负责对用户进行授权，目录系统中存在的属性就读取出来，认证平台需要的特殊属性，目录系统中没有的，则由认证平台对其进行赋值。（一般都是赋予最低级别的取值）
3.1.3 用户存储规范
用户注册的数据一定遵守全市统一目录结构规范，具体目录结构规范参见后节。所有的目录管理系统注册入口必须需要指向本地，即用户注册应用程序中指定的DN必须是本地[在线平台]节点。比如，AB区的注册用户，指定的就是AB区的[在线平台]节点，市级的注册用户，指定的就是市级的[在线平台]节点。
3.2目录结构规范
3.2.1 整体目录组织结构
基于逻辑数据集成的集成方式，目录结构必须统一。目前，考虑到的对全市目录结构组成方案，大体参见下图：
图四 目录组织结构
为保证全市用户可以在各区县和市级平台系统统一注册和认证，必须遵循如下原则：
1．必须遵循全市统一目录结构，以市为根节点，各区县为二级节点，以区县为单位划分分区。
2．二级节点的结构需要存在[在线平台]节点，在这个节点下面存储在线平台外网用户。
3.2.2 组织单元目录结构
由于目录服务系统的特点，当某容器下的直接节点数超过20万，会严重影响性能，而且Novell公司建议每个Container的对像数量保持在1000数量级最佳。分析应用实际的用户数量大约在20万-100万之间，若达到理想的情况下在一个节点会有100-200万用户注册。基于以上的分析，需要对目录结构进行系统的划分。这样才能保证认证和访问的高效。最初由几个想法如下：
l 按街道，按照街道组织所有的用户，就是根据街道建立Container，然后根据注册用户的街道将其放到相应的街道Container中。
l 按用户名称的首字母，根据用户注册名称的首字母，建立以26个字母A-Z命名的Container，根据每个注册名称的首字母放到相应的Container中。.比如注册的Zhangsan，那么将Zhangsan放到Z Container中。
这两种组织用户的方法的优点是直观简单，系统设计也比较简单。按照街道组织用户的缺点是，不能做到用户的均匀分布，有些街道的人多，有些人少。另外，很多人注册的时候没有街道或者不填写街道，可能加剧用户分布不均。有悖于提高认证效率的初衷。再说强迫用户在注册的时候填写街道，有些不尽情合理。按照用户首字母组织用户的缺点也有不能做到用户的均匀分布，有些字母必然多用，比如e、i、s、z等。另外，100万用户，没有Container中平均是5万个左右，认证和访问的效率本身不高。
由于在实际应用，管理员不需要直接接触eDirectory，所以按照街道和用户注册名称首字母组织的优点-简单直观就显得不很重要了。最终我们选择通过对用户注册名称进行HASH组织用户。按照20-100万用户算，以及每个Container数量是1000级，算得最佳的Container数量也是1000级。
因此，对[在线平台]节点下的目录结构进行规划。规划的内容包括：
1． 根据实际需要，初始化1000个组织单元，命名分别为ZX0,ZX1……,ZX999。
2． 存储用户数据时，根据散列算法，通过用户名计算相应的散列值，存到相应的组织单元中，散列算法见后面。
3． 查找用户时，根据散列算法，通过用户名计算相应的散列值，到相应的组织单元中查找，散列算法见后面。
3.2.3 散列算法
1． 算法描述
根据用户名称的每一个字符的ASCII码平方后求和，然后取后三位作为散列值，其中，汉字作为一个字符来处理，所有字符编码格式采用GB2312。
2． 算法实现举例
Int 声明整型变量
String 声明字符串变量
SUBSTRING 取得某个字符串的部分
RETURN 函数返回
ASCII 取得某个字符包括汉字的ASCII码
TO_STRING 将某个字符从数字转化成字符串
String GetHashValue(String cn) {
Int Result;//保存中间的结果
Int cn_Len;//保存字符串的长度
cn_Len :=Length(cn);//得到字符串的长度
for (int i=1;i<=cn_Len;i++)
//平方后求和
Result =Result+i*(ASCII(SUBSTRING(cn,i,1)),2)* (ASCII(SUBSTRING(cn,i,1)),2);
return(SUBSTRING (TO_STRING(Result),-3,3));//返回后三位
}
3.3用户登录规范
用户登录时，必须提供用户标识、密码、才能进行登录，系统首先通过分析用户提供的用户标识来获得其注册地点信息，然后根据注册地点信息确定用户数据所在的分区，根据相应的搜索规范进行搜索。登录过程参见下图：
图五 用户登录过程
用户登录主要涉及以下几方面问题：
l 用户搜索规范
l 统一入口规范
浙公网安备 33010602011771号