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

文章出处：http://www.nexussmartsolutions.com 作者：许鑫 苏新宁   人气： 发表时间：2011年11月23日

    对于数字化校园的研究，比较一致的观点是把数字化校园的建设分成了三大类，第一类的平台的建设，正如前面系列文章中介绍的统一身份认证、统一信息门户、共享数据中心、一卡通平台等；第二类是应用建设，各种各样的MIS系统、OA系统等等，与学校的各个业务部门和流程密切相关的管理信息系统；第三类是资源建设，包括数字图书馆、数据博物馆、课件库、资源库等数字资源的建设。然而，究竟如何构建我们的整体的数字化校园，如何将这三者有机的联系一起，集成便成了大家共同关注的问题。 

    1 数字化校园总体方案设计 

    数字化校园整体解决方案一般分为数字化校园应用支撑平台解决方案、数字化校园应用建设解决方案、数字化校园应用接入解决方案、数字化校园应用表现解决方案、数字化校园管理决策支持解决方案五大部分，如图1所示。 

图1 数字化校园总体方案设计

    其中应用支撑平台是整个数字化校园的软件基础平台，主要包括共享数据中心、统一身份认证、统一信息门户和一卡通平台系统（校园金融消费与电子识别解决方案）等几个部分。 

    应用建设解决方案综合了大量高校的需求调研结果，是扩展性和适用性强大的各类管理信息系统，可以分为师生员工管理、教务事务管理、科研外事管理、后勤事务管理、财务事务管理、固定资产管理、办公自动化系统等大类，具体细化，比如师生员工管理包括了人事管理、招生管理、迎新管理、学工管理、就业管理、校友管理等具体的管理信息系统，再如后勤事务管理也包含了食堂就餐、商场、超市、洗衣、复印、校巴、考勤、门禁、医疗、体育设施、上机、电控、水控、保安巡更等子系统。 

    而应用系统接入方案则重要依靠一些应用系统集成工具，将原有的应用系统可以方便的接入校园共享数据中心，身份认证系统、信息门户系统和一卡通系统，这一块的设计和考虑将是本文研究的重点，后面将有进一步的探讨。最后通过在共享数据中心基础上应用数据挖掘技术提供的一系列数值分析工具实现管理决策支持等工作，进一步提升校园管理水平。 

    2 数字化校园中的一体化设计 

    在实际的数字化校园建设中，我们可以采用接入的方式完整各类平台和系统的整合，但这只是一种事后的处理方法，在新开展的数字化校园整体建设中，我们的期望的是在一开始就能有一体化的设计，把并在后期的实施中不折不扣的实现既定的规划和设计，在一体化设计中，贯穿于始终的是数据和流程这两个关键。
 
    2．1 数据 

    在数据上的考虑首先体现在信息标准的建设上，继而体现在信息的分类、数据的组织和数据库的设计上[ 2,3 ]。举例而言，如果高校缺乏对校园信息化的深入理解，那么在其构建信息标准的时候就无法根据具体学校的实际情况自主考虑。一般通用的教育部信息标准也仅仅是供参考的，只说明信息点内容，并不标明主键信息，这就需要在实际的实施中针对学校情况进行分类（也就是数据库的建表设计），在科学性、系统性等原则下，按照信息来源、组织形式或者使用范围等几种方法，把相同类型的数据提炼出来，完成对信息的分类。然后再为每张表建立一个主键ID，其生成为UUID（全球统一标识码 ），实现以一张核心信息表为主，若干张附属信息作为补充，理清表与表之间的逻辑关系（表的组织，若干主题库等）。
    同样的一体化设计还体现在对平台系统的深入理解上，以有鲜明特点的一卡通系统为例，必须对一卡通业务数据有一定的了解，才可能在数据中心设计出符合一卡通需求的类别及库表来，才能够清晰地梳理出谁是核心表谁是主键，才能够完成一卡通相应数据字段和其它应用系统字段的对应，并完成较深层次的集成……这些一体化的设计也存在于其他校园平台的设计中。 

    2．2 流程 

    流程既体现在现有流程的实现上，又体现在校园业务流程的重组上，是否在设计上充分的考虑，关系到需求变更带来的快速调整能否实现？也关系到各种功能扩充的高效实施。 

    以数字化校园整体解决方案为例，在技术架构层与层之间以及层内各组件之间定义了标准接口，达到松耦合，使应用系统的开发及后续扩展只需要关注其中相关的部分。当某些提供服务的业务系统发生变化时，不会影响到使用服务的其他业务系统的正确运行。而且新的流程需求产生以后，或者学校业务流程发生了改变，事前的充分设计和各类机制的存在就成了积极的保障。 

    2．3 方法 

    除了数据和流程的一体化设计以外，在整体的数字化校园建设中还需要注意方法。方法论的一致不仅仅体现在早期的整体统一规划中，更体现在高校信息化应用需求的实现中。统一数据标准、统一数据交互、个性定制、统一权限、统一建设、统一表现及表现扩展、统一管理等都是数字化校园一体化设计中方法所需要的关注的。再者关于数字化校园建设中的问题及对策在我们的本系列文章的第一篇中也有相应的研究和描述，前瞻性的规划、统一性的设计、整体性的建设构成了我们数字化校园建设方法论的核心。 

    在此基础上的扩展还体现在建设的步骤和节奏上，体现在投资上和评估上。有些学校应用建设比较完善，他们需要的可能是后期的整合；有些学校直接先上平台等基础设施，它们可能需要的是如何在平台基础上更快更方便的建设应用；也有些学校分别进行了一些一卡通、资源库、基础平台之类的信息化建设，此时后期的集成变成了关键。各个学校有各个学校建设的步骤，同时对于节奏的控制也十分重要，既不能“贪多嚼不烂”，虎头蛇尾的建设，也不能“再而衰，三而竭”，信息化进程拖沓不可控是很严重的问题。此外一体化的设计还体现的投资上的综合考虑，比如在软硬件部署上根据建设要求充分考虑，共享设计，避免重复投资。避免购买很多服务器，但大多数利用不高，或者购买了各类数据库软件，但各个库上跑的数据和业务都很有限等诸如此类的问题。 

    3 数字化校园中应用集成设计 

    数字化校园的应用集成设计主要体现在平台和应用的对接上，同时，因为一卡通平台涉及到硬件设备，而且又是金融化的系统，所以其集成也是有特点的。 

    3．1 校园各类应用系统的平台集成 

    3．1．1 各类MIS与共享数据中心 

    对于各类MIS与共享数据中心平台的集成，首先要分析应用的数据结构和共享数据中心库内的数据结构的区别。建立双方都能认可的一个协议后，根据校园数据标准使用数据集成客户端工具在共享数据中心库中建立系统需要的部分或者全部数据结构。针对系统间对于某些字段的定义仍然存在着区别，建立一种规则来达到双方共同认可的字段对应。共享数据中心根据应用系统的业务需要，生成相应的主题库和中间件，应用系统在进行数据操作的时候，直接调用中间件服务操作主题库，以达到对共享数据中心库的操作。 

    对数据中心的集成接入特点体现在需要对要接入的每一个应用系统的数据源进行调研，确保提供一定程度的数据接口，这个从应用系统往共享数据中心的上行过程要确定从应用系统抽取哪些数据，这些数据的含义是什么，即提供相应的数据字典，并且确定对应于数据中心的哪张表，可接入的数据接口模式分为： 

 模式一：直接开放数据库，只需要只读的账户权限即可，需要在绝对保证原有系统数据安全性和完整性，不影响原有系统运行的基础上建立触发器。 

 模式二：中间文件数据源，如应用系统不能对外开放数据库，则可以导出差异数据文件到指定的目录，这些文件可以是Access文件数据库模式、excel文件模式等，格式可在实施时共同商定。 

    3．1．2 各类MIS与统一身份认证 

    数字化校园的整体建设客观上要求建设统一的身份认证中心，针对各个集成到身份认证系统的应用系统，提供身份相关服务。这里是最权威的用户基本信息的集中存储，用户身份信息的唯一入口；对每个应用提供用户组的定义，为权限管理提供了手段；提供了用户身份认证服务和单点登陆（SSO）的方法。数据同步服务提供用户数据同步复制的机制，支持应用建立单独的数据库，并保持两边数据的一致性和不冗余；数据访问服务提供了安全的、有权限控制的应用系统访问用户身份信息的方法。用户在登录应用系统的时候，应用系统会取得用户的用户名和密码，此时它把用户名和密码通过加密方式提交给统一身份认证系统。统一身份认证系统在得到用户名和密码后立即验证其合法性，主要就是反映其是否有访问系统的权限，统一身份认证系统把得到的结果返回给应用系统。 

    各类MIS和认证平台的集成主要体现在统一身份认证给其他的应用系统提供访问者身份的验证信息。每一个应用系统通过某种途径访问把访问者的信息提交给统一身份认证平台，一般是通过使用socket实现访问接口，应用系统把访问者信息按照规定的要求格式转化为xml包，发送到统一身份认证平台前置机上，前置机收取后经过处理返回结果包，同样也是采用xml格式。现阶段统一身份认证平台能够提供给Portal比较详细的认证，包括权限等，但对于其他的各类应用系统则接入层次参差不齐，这是因为一些系统内部存在着自己的权限分配策略（非RBAC模式），没有或者不能够把权限分配存放在统一身份认证平台上。若应用系统把其使用权限移交到统一身份认证平台上，那么必须要按照要求把权限按照角色或者组织来划分，则认证平台在返回结果包时包含着访问者的角色和权限信息。 

    3．1．3 各类MIS与统一信息门户 

    建设统一信息门户作为个人单点登陆和信息发布的集中点，一方面面向个人用户，如果个人不登陆，在信息门户上可以获取公共的信息；用户在信息门户登陆一次以后查询到所有与其个人相关的信息及进行某些业务系统的操作；提供链接，对于某些集成到统一身份认证系统且有单独Web信息发布的应用，可以平滑进入，无需再次身份认证。在面向应用开发方面，提供了统一的应用开发模式；提供了基于Web的统一的权限管理模式；提供了统一的界面表现形式，可以将来源于各种应用系统的数据集中发布，互不干扰。 

    应用系统首先按照逻辑/表示分开的原则分析自己的结构，表示层的结构通过Portlet形式安装在统一信息门户系统中，应用系统自身保留对业务逻辑处理的结构，并提供给接口统一信息门户系统访问。当用户使用统一信息门户系统中的某一Portlet时，统一信息门户系统会将用户对Portlet的操作反映给应用系统的业务处理接口，处理完毕后，会返回给统一信息门户系统，Portlet则把这些结果反映在页面上。对门户平台的接入大体上有三种方式，一种是开发者把页面和逻辑都卸载Portlet中，则此Portlet可以脱离开现有的应用系统，成为现有应用系统的替代者；另外一种是开发者可以把逻辑和页面分离，Portlet是其页面部分，每次把需要的信息通过POST方法提交到应用系统中，应用系统的Servlet或其它运行程序通过处理把结果返回给Portal，Portlet把得到的结果显示出来；还有一种是其他的应用系统也可以提供相应的EJB，开发者只需要在Portlet中直接调用具体的EJB即可。 

    3．2 一卡通平台和其他平台的集成 

    3．2．1 一卡通与共享数据中心 

    在数字化校园中，数据层面的所需信息集中存储，并给各应用子系统共享，有效防止信息的冗余和不一致，保证数据的准确性和可靠性；可以方便的实现核心数据的集中管理、备份，提高系统的安全性，减少设备的投资和管理的人力成本。数据中心在数据级对“一卡通”和其他系统的数据进行无缝集成，便于信息的共享、交流和各项业务的协作。 

    一卡通系统应该充分使用统一共享数据平台提供的公共数据编码、身份信息等数据。而不应该单独维护一套独立、非标准的信息。同时一卡通系统拥有自己的业务数据库，将其他应用系统需要的信息纳入共享数据库的统一设计中，实现校园一卡通系统数据对整个数字化校园的共享。通过数字化校园应用建设，形成一套符合高校自身实际的管理信息化标准，也是数字化校园建设中的一项重要内容。我们根据自己的理解，结合大量的案例，会根据学校信息化现状提出信息代码编码标准、软硬件平台标准、应用系统规范、业务流程规范和数据交换标准等，这样为今后的应用系统的建设制定了规范。一卡通作为重要的应用系统必须符合整体标准。 

    一般而言为了集成，一卡通使用的公共信息字典必须遵循学校的信息编码规范，数据模式必须遵循数据库第三范式，一卡通使用的用户及其信息必须和业务系统提供的信息是一致的，可以相互关联的，以保证一卡通的数据和学校的其他信息数据能同时进行查询、分析、统计。针对于卡的门户应用，共享数据中心中的数据需要既能展示相关的信息，如：校园卡选课后学生的选课课程、选课的缴费等，又能统计相关的信息，如：不同的专业的学生费用使用总计及平均消费情况等，这些都需要充分的集成设计。 

    3．2．2 一卡通与统一身份认证 

    数字化校园建设初期一般多注重建成以目录服务为基础的统一身份认证系统，而一卡通建设也有自己的身份认证和设备认证，随着数字校园的深入建设，CA认证中心、电子签名、电子印章的出现，我们必须重新规划全校的身份认证体系，卡作为统一身份认证的认证载体，不仅可以用作消费，还为统一身份认证平台提供了基于用户名/密码认证、CA、指纹等存储。
 
    原有一卡通系统具有单独一套的用户管理和用户组管理模块，在和统一身份认证系统集成之后，统一身份认证系统作为添加用户的唯一入口，已经实现了这部分功能，因此一卡通系统中的这部分功能不再需要，身份信息从统一身份认证系统获取。原有的以一卡通管理平台集成的应用，例如图书馆系统、考勤系统，不再到一卡通管理平台认证身份，而是直接和统一身份认证系统集成。 

考虑到校园一卡通系统的特殊应用场景，具有专网设计、脱机使用的要求，统一身份认证中心支持一卡通系统建立自己单独的数据库，定制开发后台数据复制的服务，使得校园一卡通系统可以保持和统一身份认证数据的一致；对于校园一卡通系统的Web应用部分，通过将其纳入信息发布门户体系，使用统一身份认证系统接口，自然支持单点登录。 

 用户信息同步 

    一卡通系统所有用户信息均可以来自于统一身份认证中心，原则上要求统一认证用户库中的用户基本信息数据是相对完整的、权威的，初始化时可从统一身份认证系统中批量导入数据，以后接收统一身份认证系统中的用户变化信息，保持与二者的同步。 

    卡信息同步 

    在统一身份认证系统里面保存卡ID号、卡状态（未发卡、已发卡、已挂失）、卡有效期等信息，一卡通系统在完成发卡、挂失、解挂、补卡、换卡等业务的同时，需要将卡信息同步发送到统一身份认证系统中。 

    卡权限管理 

    一卡通内部的权限，如卡的使用权限、管理权限应当由一卡通平台本身来管理，但消费记录查询等由专门的Web应用处理的这部分权限可以放在统一身份系统中管理。 

    卡认证服务 

    当实现了卡认证服务时，该卡（人）在某个应用系统中的权限可以根据情况选择应用系统单独管理或者由统一身份认证系统分配，以完成卡认证和其它各应用的授权。 

    3．2．3 一卡通与统一信息门户 

    门户系统与“一卡通”系统可以方便地进行整合，门户系统将统一成为应用系统和“一卡通”系统地展现平台，便与学校的统一管理。信息发布平台包含了动态网站的框架和应用系统开发集成平台。信息发布平台部分栏目由平台自身提供的工具维护，与一卡通系统相关的部分则需要二次开发或者集成。平台与一卡通系统的接口分为两部分： 

    数据接口 

    一卡通系统提供数据源，数据源包括数据库表或者视图的结构、用户名称、口令，信息发布平台通过数据源可以获得需要发布的所有信息，可以将数据存储在信息发布临时的数据库中或者直接访问一卡通系统的数据库，在信息发布平台上重新开发和配置查询的应用。
 
    认证接口 

    将一卡通原有的Web发布系统的形式集成进信息发布平台，这种链接不是简单的Web链接，而是需要将一卡通系统的用户登陆进行改进，保证在信息平台上登陆一次即可以进入子系统，无需二次登陆，实现单点登陆。 

    在数字化校园环境下的信息发布平台的形式主要有以下四种：网站、多媒体终端、电话、邮件。网站开发基于统一信息门户平台，以开发Portlet的模式进行；另外挑选造型美观的触摸屏电脑，配备读写器，作为校园的自助多媒体查询终端。自助查询终端不仅仅作为一卡通的系统的信息查询和发布的终端，也应该用于其它应用系统如教务系统、图书馆系统、学工系统等等信息的查询和发布终端。一卡通与统一信息门户的集成包括： 

    （1） 一卡通系统提供数据源，门户平台通过数据源可以获得需要发布的所有信息，可以将数据存储在信息发布临时的数据库中或者直接访问一卡通系统的发布数据库，在信息发布平台上重新开发和配置查询，将各类消费与管理的信息及需要查询的明细发布到门户，提供权限控制下的信息查询与统计和分析。 

    （2） 在门户上集成一卡通系统的用户登录，使得门户上一卡通系统的相应栏目可以直接显示持卡人最直接需要的统计结果，以提供最人性化的服务方式。 

    （3） 在原有信息服务基础上，通过与其他应用及校园基础网络服务的整合，开发新的服务模块，并集成到门户上，利用门户提供的各种发布方式向全校师生提供增值信息服务。 

    （4） 通过将校园一卡通系统的信息查询与统计集成到门户上，可以借助门户的Web发布、多媒体查询终端、电话语音等各种发布手段，扩展校园一卡通服务的覆盖面。 

    4 应用集成示例 

    4．1 综合教务系统集成 

    综合教务管理系统是辅助学校教师、学生进行综合业务管理的一个平台，是数字化校园业务系统中的重点。综合教务管理系统一般具有自己的一套数据库标准和数据结构，但对于整体数字化校园建设的高校而言，因为已经制定了一套统一的信息标准，所以综合教务管理系统的数据就必须和共享数据中心有着一个接入同步的过程。同时综合教务管理系统的使用者是教师和学生，每个使用此系统的人都有着不同的身份、角色、权限。例如在网上选课系统中，不同年级、不同专业的学生所能选择的课程是不一样的，在学生学籍管理中，不同的老师所能做的操作也是不一样的。再者综合教务管理系统的表示层可能是由浏览器或者客户端等方式表现出来，但是其表示层也可以由统一信息门户系统来展示，统一信息门户的最大的优点之一就是应用系统的集成。综上所述，教务系统的集成如图2所示。 

图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 来满足。
 
    从数据的集成到流程的集成，从身份认证的集成到门户表现的集成，从资源的集成到应用的集成，我们在数字化校园中的集成研究任重而道远，期望着和诸位有致于在理论上或者实践中建设整体数字化校园的同仁们共同努力。 

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