信息资源系统技术规范.docx
《信息资源系统技术规范.docx》由会员分享，可在线阅读，更多相关《信息资源系统技术规范.docx（12页珍藏版）》请在冰豆网上搜索。
信息资源系统技术规范
某大学信息资源系统技术规范
为了进一步规范我校数字校园建设，保障信息资源共享和信息资源系统集成，根据《某大学数字校园建设规划》，特制订以下技术规范：
1、适用范围：
各职能部门改建、新建的信息管理系统、信息资源系统等；
2、系统规范：
信息资源系统的服务端（Web服务器、应用服务器和数据库服务器）能够在Unix、Linux操作系统上运行，支持Oracle数据库；
3、架构规范：
信息资源系统应采用B/S结构的三层架构，即Web服务器、应用服务器和数据库服务器，以方便用户使用；
4、开发技术规范：
应采用JavaEE（J2EE）标准、组件技术及在数据交换上对XML的支持；
5、数据交换规范：
当业务系统需要与数字校园平台的公共数据库进行数据交换时，要按照学校制定的数据同步方案执行（附1）；
6、信息编码规范：
信息资源系统所用编码应符合《教育管理信息化标准》（第一部分：
学校管理信息标准）（2003.9），教育部远程教育标准（DLTS）和某大学自编编码规范；
7、统一身份认证集成规范：
B/S架构的业务系统与数字校园进行SSO集成时，要按照学校制定的SSO集成方案执行（附2），建议尽量采用集成方案一；
8、扩展性规范：
信息资源系统须具有良好的扩展性。
业务系统建设的长期性和内容的广泛性决定了系统在构建和使用过程中，必然面临着各类扩展性需求，例如业务规模的扩展、业务类型的扩展等。
因此要求模块间应相对独立，接口清晰，内部的业务流程升级和改造与其它模块无关，并为将来学校二次开发提供开发API等；
9、本规范未尽事宜联系校网络信息中心；本规范最终解释权归校网络信息中心。
二○○九年四月二十四日
附1：
数据同步方案
第一章数据同步流程
数据同步是指第三方业务系统与公共数据库平台（以下简称数据平台）之间进行的周期性数据交互，包括数据从业务系统到数据平台的同步以及数据从数据平台到业务系统的同步两个流程。
一、从业务系统到数字校园平台的同步
1.1为了实现数据的准确性同步，根据需要，需要第三方开发商在其业务系统的数据库中建立共享数据视图，并授权给数据平台用户只读权限，数据平台对视图进行抽取，将数据抽取到平台的中间表（临时表）中，如图1－1所示。
图1－1
数据平台也会在其数据库中建立相应的中间表，其表结构与第三方业务系统提供的视图表结构相同，并周期性的将业务系统视图的数据同步到该中间表中。
通过数据清洗将数据及时的更新公共数据库中的目标表中，进而实现了第三方业务系统中的数据可持续地与数据平台之间的同步。
二、从数字校园平台到业务系统的同步
为了配合第三方业务系统从数据平台同步相关数据的需求，数据平台为业务系统提供所需数据的视图，并将数据的变化信息体现在数据变更表中，业务系统在第一次初始化所需共享数据后，通过定时读取数据变更表中的数据变更信息，对所需共享数据进行更新，如图1－2所示。
图1－2
第二章需要第三方厂商做的工作
一、从业务系统到数字校园平台
在数据从第三方业务系统到数据平台的同步过程中，数据平台需要第三方开发商在其业务系统的数据库中建立共享数据视图，并授权给数据平台用户只读权限，数据平台对视图进行抽取。
如图2－1虚线部分所示。
图2－1
二、从数字校园平台到业务系统
在数据从数据平台到第三方业务系统同步的过程中，数据平台为业务系统提供所需数据的视图，并将数据的变化信息体现在数据变更表中，业务系统在第一次初始化所需共享数据后，通过定时读取数据变更表中的数据变更信息，对所需共享数据进行更新，如图2－2虚线部分所示。
图2－2
第三章数据同步数据平台做的工作
一、从业务系统到数据平台
在数据从第三方业务系统到数据平台的同步过程中，数据平台会从第三方业务系统提供的视图中读取数据到平台下的中间表中，与数据平台中的历史数据进行对比，将数据的变更信息写到数据变更表中，如图3－1虚线部分所示。
图3－1
二、从数据平台到业务系统
在数据从数据平台到第三方业务系统同步的过程中，数据平台会为第三方业务系统提供相应的视图表作为接口供其操作，并把数据的更新情况及时的反映到数据变更表中以实现数据同步，如图3－2虚线部分所示。
附2：
数字校园平台单点登陆（SSO）解决方案
方案1、采用信息平台提供的统一身份认证系统实现SSO
1.使用平台提供的统一身份认证系统CAS进行SSO集成的条件：
Ø前提条件：
第三方系统的用户身份信息使用信息平台的用户身份信息；或存在一个第三方系统和信息平台用户身份信息的对应关系表，并由双方系统共同维护。
Ø实现条件：
1）需要第三方系统修改代码。
2）如果第三方系统中包含的不需要认证就能访问的内容过多，则采用共享密钥或是模拟登陆方式。
2.具体实现：
第三方系统开发商需要完成以下两个主要工作：
1）在自己的应用中配置CAS客户端。
2）取消此应用原先的认证登陆程序（不是必须的），改为根据CAS认证信息处理登陆。
要完成第一个工作，需要以下步骤：
1）使用由数字校园平台提供的、封装好的CASClientJAR包，放在应用/WEB-INF/lib/下。
2）在应用的web.xml中加入CASFilter相关的filter配置
其中，filter-class属性需要指定项目中使用的CAS过滤器类。
上面的配置中指定的是默认的CAS过滤器类。
第三方系统可以根据处理登陆的操作来扩展此类并覆盖相关方法。
3）配置casFilterConfig.xml。
这个文件需要放在对方应用的/WEB-INF/classes下。
指的是CASServer的登陆URL；
指的是CASServer的验证URL
指的是当前要集成的第三方应用的服务器和端口号，服务器可以是机器名、域名和ip等，最好使用域名。
端口不指定的话默认是80。
下的指定了不需要CASFilter进行过滤的资源。
Ø第三方j2ee应用可能都会有特殊的判断用户是否已经登录的逻辑以及特殊的存储在Session中的用户登录信息。
因此要完成第二个步骤，第三方j2ee应用可以通过扩展CASClient端提供的com.neusoft.education.tp.sso.client.filter.DefaultCASFilter这个类，并覆盖其中的如下四个方法来实现在过滤的过程中处理业务系统登陆操作，并且在web.xml中的属性中写入自己扩展类的类名：
1）isNeedCASLoginOrValidate
这个方法判断请求的用户是否需要通过CAS登陆和验证。
返回true则需要；返回false则不需要并直接进入业务系统处理登陆后的操作。
此方法需要进行如下判断：
判断当前获取的CASReceipt对象是否有效（代表是否是已经通过CASServer认证的用户），并且对不需要filter过滤的资源进行特殊处理（在casFilterConfig.xml中下的中记录的资源会自动放行）。
注意：
第三方系统覆盖此方法进行特殊处理时必须要调用此方法进行默认的处理。
2）isNeedRedirectToCAS
当isNeedCASLoginOrValidate方法返回true（代表用户需要访问受CASClient保护的资源但用户尚未经过CASServer认证）的时候，正常情况下会直接转向CASServer的登陆地址。
但如果第三方系统需要在CASClient将用户请求重定向到CASServer进行登陆操作之前处理一些特殊逻辑判断或处理的话，则在此方法中完成其操作。
返回true则转向，false则不转向。
DefaultCASFilter中的这个方法直接返回true，转向CASServer进行登录验证。
3）isNeedValidate
当CASServer对登陆用户完成认证后，会生成ServiceTicket放在URL中返回给客户端浏览器重新定向到CASClient端。
CASClient端得到ST后，正常情况下会拿着这个ST去CASServer端进行确认以得到用户的身份信息。
但如果第三方系统需要在CASClient拿着ST去CASServer进行确认之前做一些特殊逻辑判断或处理的话，则需要在此方法中完成其逻辑处理。
返回true，则去CASServer端确认并得到用户身份；返回false，则不去确认，这样也就得不到用户的身份。
DefaultCASFilter中的这个方法直接返回true，转向CASServer进行确认。
4）userLoginAndValidated
如果用户已经通过了CASServer的登陆验证，那么在这个方法中处理登陆验证成功后的操作，比如将需要用到的用户信息放入session等操作（第三方系统需将自己处理登陆验证后的逻辑写在这个类中）。
特别注意：
第三方系统在其覆盖方法中做处理之前一定要调用此方法进行默认处理：
super.userLoginAndValidated（request,response,receipt）;
否则就会导致isNeedCASLoginOrValidate方法得到错误的结果。
完成以上工作后，通过CAS实现第三方系统的SSO集成基本也就完成了。
方案2、使用与第三方系统共享密钥方式实现SSO
这种方式实现SSO要双方的系统在共享密钥的设置（包括密钥的生成、认证过程中密钥的交换方式等）达成一致。
具体方案如下：
Ø前提条件：
1）平台用户账号和第三方业务系统账号如果不同，需要在公共数据库中建立对应关系。
Ø实现条件：
1）平台服务器和第三方业务系统服务器的系统时间要保持一致。
因为第三方业务系统需要通过我们传递的时间戳参数time_stamp来校验请求在时间上的合法性。
2）如果使用静态密钥的话，需要双方系统开发商约定好共同使用的密钥KEY是什么（随意，最好复杂些但有规律）。
如果使用动态密钥的话，那么第三方系统需给我们提供其生成动态密钥的系统接口供我们调用。
3）双方系统开发商约定传递给他们的参数有哪些，以及传递的方式是什么。
4）承建数字校园平台的东软公司和第三方业务系统开发商约定好需要校验的加密字符串en_string的组成规则。
如：
第三方业务系统用户名user_name+KEY+time_stamp。
5）约定好校验字符串的加密方式是MD5或其它加密方式
附3：
统一身份认证的实现方式
一、采用数字校园平台的CAS进行身份认证
具体实现参见【附2数字校园平台单点登陆（SSO）解决方案】中的方案1
二、通过数据库认证方式
1.数据平台为业务系统提供数字校园平台用户的账号和密码，其中密码为MD5加密后的密文形式保存。
2.业务系统不为用户提供密码修改功能，用户只能在数字校园平台门户中进行密码修改。
3.当用户登陆业务系统时，业务系统首先读取存于本地数据库中的用户账号信息，如果与提交的登陆信息不匹配，再读取数据平台提供的用户账号信息与用户登陆信息进行比对，并对无法登陆的用户给出相应的信息提示。
同时将数据平台与本地数据库中不同步的信息更新到本地数据库中。
三、通过标准的LDAP协议认证方式
1.数字校园平台为业务系统提供标准的LDAP目录服务，符合LDAPv3版本标准。
2.业务系统可以直接使用数字校园平台提供的LDAP目录服务，也可以将数据同步到业务系统本地的LDAP目录中。
3.业务系统不为用户提供密码修改功能，用户只能在数字校园平台门户中进行密码修改。
4.当用户登陆业务系统时，首先读取存于本地LDAP中的用户账号信息，如果与提交的登陆信息不匹配，再读取数字校园平台的LDAP中用户账号信息与用户登陆信息进行比对，并对无法登陆的用户给出相应的信息提示。
同时将数字校园平台LDAP与本地LDAP中不同步的信息更新到本地LDAP中。
升级会员 