数字化校园中应用集成研究

图2 教务系统对接总体逻辑图 

    具体而言，综合教务系统集成的需求包括： 

    共享数据需求 

    综合教务管理系统本拥有自己的数据系统，为了适应校园数字化整体结构要求，其数据系统应该保存在共享数据中心系统中，从而避免数据冗余，达到数据利用率高的效果。 

    身份验证需求 

    综合教务管理系统本身在设计的时候拥有成熟的权限分配、验证功能，但是为了适应校园数字化整体结构的要求，综合教务管理系统需要将对登录用户身份的验证交给统一身份认证来处理。统一身份认证拥有着一整套的身份验证方法和验证权限的方法，如果综合教务管理系统能够满足统一身份认证系统的权限设定要求，那么统一身份认证系统还能够提供相应的访问权限。 

    门户表示需求 

    现有综合教务管理系统在表示层上已经提供了多种方式给用户使用，但是根据校园数字化的整体结构要求，其表示层应该无缝集成在统一信息门户系统中，综合教务管理系统只提供逻辑处理过程，数据的输入和产生的结果都交给统一信息门户进行处理，统一信息门户系统把产生的结果展现在用户面前。 

    由于现有的各类平台基本具有了各类对接的机制，所以与上述需求对应的集成也就可以方便的设计出了。综合教务管理系统与共享数据中心的集成是首当其冲的数据级集成，数据流示意如图3所示，综合教务管理系统为了达到共享数据中心对接的目的，首先要分析当前的数据结构和共享数据中心库内的数据结构区别，直到建立双方都能认可的一个协议后，根据校园数据标准使用数据集成客户端工具在共享数据中心库中建立综合教务系统需要的部分或者全部数据结构。尽管已经建立好了数据结构，但是两个系统对于某些字段的定义仍然存在着区别，所以需要建立一种规则来达到双方系统共同认可的字段对应。共享数据中心根据综合教务管理系统的业务需要，生成相应的主题库和中间件，综合教务管理系统在进行数据操作的时候，直接调用中间件服务操作主题库，以达到对共享数据中心库的操作。

    综合教务管理系统向统一身份认证系统服务请求示意如图4所示，用户在登录综合教务管理系统的时候会取得用户的用户名和密码，此时它把用户名和密码通过加密方式提交给统一身份认证系统，统一身份认证系统在得到用户名和密码后立即验证其合法性，主要就是反映其是否有访问综合教务系统的权限，统一身份认证系统把得到的结果返回给综合教务管理系统。最后还要考虑的是综合教务管理系统和统一信息门户系统的业务集成，示意如图5，综合教务管理系统首先按照逻辑－表示分开的原则分析自己的结构，表示层的结构通过Portlet形式安装在统一信息门户系统中，综合教务管理系统自身保留对业务逻辑处理的结构，并提供给接口统一信息门户系统访问，当用户使用统一信息门户系统中的综合教务Portlet时，统一信息门户系统会将用户对Portlet的操作反映给综合教务管理系统的业务处理接口，处理完毕后，会返回给统一信息门户系统，综合教务Portlet把这些结果反映在页面上。 

    4．2 身份认证接入接口示例 

    对于统一身份认证，为了更好的集成，一般会提供大量的第三方应用的身份接入接口[ 5 ]，如登录名/别名认证、修改个人信息/密码、获取组织/角色/应用信息、获取证书、模块/组织/角色/应用关联维护等，下面就以登录名认证接口和修改个人信息接口为例予以说明。 

    （1）登录名认证
    方法名
    VerifyUserPassword
    输入
    <?xml version="1.0" encoding="UTF-8"?>
    <Input>
    <Job>VerifyUserPassword</Job>
    <UserID>c0000005</UserID> //用户登录ID 
    <Password>123</Password> //密码
    <SystemName>portal</SystemName>
    </Input>
    输出
    成功
    返回用户基本信息。
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>True</Result>
    <Info>
    <AttrName>SessionID</AttrName> //SessionID
    <AttrValue>1082255488284@1400964957810505343@3</AttrValue>
    </Info>
    <Info>
    <AttrName>cname</AttrName> //姓名
    <AttrValue>许鑫</AttrValue>
    </Info>
    <Info>
    <AttrName>ename</AttrName> //英文名
    <AttrValue />
    </Info>
    ……
    </Output>
    失败
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>False</Result>
    <Info>错误信息</Info>
    </Output>
    （2）修改个人信息
    方法名
    ModifyUser
    输入
    <?xml version="1.0" encoding="UTF-8"?>
    <Input> 
    <Job>ModifyUser</Job> 
    <SessionID>1082266005586@472673864587841191@4</SessionID>
    <SystemName>portal</SystemName>
    <Attr>
    <AttrName>cname</AttrName> //姓名
    <AttrValue>许鑫</AttrValue>
    </Attr>
    <Attr>
    <AttrName>sex</AttrName> //性别
    <AttrValue>1</AttrValue>
    </Attr>
    <Attr>
    <AttrName>alias</AttrName> //别名
    <AttrValue>c0000008</AttrValue>
    </Attr>
    …… //其它用户用户信息
    </Input>
    输出
    成功
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>True</Result>
    <Info>
    <AttrName>phone</AttrName> //联系电话
    <AttrValue />
    </Info>
    …… //新的用户信息
    </Output>
    失败
    <?xml version="1.0" encoding="UTF-8"?>
    <Output>
    <Result>False</Result>
    <Info>错误信息</Info>
    </Output> 

    5 结束语 

    虽然在上文中针对高校的业务我们对其应用集成做了一些研究，但还是远远不够的，因为各个学校的流程千差万别，各个应用系统的底层架构和部署环境也各有特点，我们研究和设计出来的各种方案也只是一些比较通用的集成做法，对于具体的应用我们还得有针对性的进行技术分析和集成设计，比如高校的里面的办公自动化系统（OA）架构就有很多，有基于数据库的，也有基于Domino系统的，因为统一身份认证系统是基于标准J2EE结构，如果OA系统是基于J2EE平台的，J2EE架构又一般采用的是关系型数据库，那么对接的时候可以很方便的以上文描述的方法做集成。

    但如果是基于Domino的OA，因为其自成一套体系，在数据存储的格式、系统开发环境上都和J2EE架构完全不一样，我们要完成对接就得有一些特殊的机制，若办公自动化系统在对登录用户验证身份的时候，需要向统一身份认证系统提交验证请求，那么此时一般采用Domino调用DSAPI库来访问统一身份认证系统，从而达到身份验证的目的。DSAPI 是作为一个共享库（Windows NT/2000/2003 上的一个 DLL 文件或 UNIX/Linux 上的一个共享对象）来实现的，它由 Domino HTTP 进程注册和调用。有一些关键事件与该 HTTP 任务相关联，并且这些事件已被 DSAPI 中的定制代码所改写。由于 DSAPI 实际上代替了 Domino 身份验证模型，它促成了广泛的定制身份验证需求可通过实现 DSAPI 来满足。
 
    从数据的集成到流程的集成，从身份认证的集成到门户表现的集成，从资源的集成到应用的集成，我们在数字化校园中的集成研究任重而道远，期望着和诸位有致于在理论上或者实践中建设整体数字化校园的同仁们共同努力。 

（文/南京大学信息管理系，许鑫 苏新宁）