教育管理信息系统互操作通信模型设计与实现

教育管理信息系统互操作通信模型设计与实现摘要：针对教育行业信息系统的互操作迫切需要，在分析现有解决方案不足的前提下，提出采用WebServices技术构建异构信息系统互操作框架，设计了异构信息系统互操作通信模型，并基于.Net平台对该模型的可行性进行了实验验证与测试，同时通过对模型的经济成本分析，论证了本设计是高效率低成本的解决方案。关键词：教育信息系统、互操作、通信模型、Web服务DesignandImplementationonCommunicationModelofEducationManagementInformationSystemInteroperabilityAbstract:Aimingattheurgentrequirementofeducationalprofessioninformationsysteminteroperability,inanalyzingthedeficiencyoftheonhandsolutionproject,ProposesusingWebServicestechnologytobuildinteroperabilityframeofheterogeneousinformationsystem.Thecommunicationmodelofheterogeneousinformationsystemisdesigned;thefeasibilityofthismodelisconductedexperimentalverificationandtestaccordingtothe.Netplatform,anddemonstrationthisdesignisahighefficiencyandlowcostsolutionproject,throughthecostanalysisofeconomyaboutthemodel.Keyword:EducationInformationSystem、Interoperability、CommunicationModel、WebServices1引言在教育信息化发展过程中，建立了大量的管理信息系统，但由于缺乏有关教育管理信息模型方面的标准和规范，造成这些信息系统之间存在兼容性差、数据信息资源难以交流共享等问题。教育部发布的《教育管理信息化标准》[1]正是为解决这一问题而制定的，从《标准》已发布第1部分《学校管理信息标准》来看，其实质上是将我国教育行业内的各类信息进行分类，采用数据字典方法建立信息模型，以实现信息语义的确定性和一致性。与此相对，同样是针对教育行业内的信息系统的互操作问题，国内外某些机构还提出了一些具体的技术方案。如美国软件与信息工业协会在北美地区广泛推行了学校互操作框架（SIF，SchoolsInteroperabilityFramework）[2]。国内的北京师范大学现代教育技术研究所在非等效借鉴SIF的基础上，提出了一个重要概念——教育管理信息系统互操作框架（EMIF，SpecificationforEducationManagementInformationSystemInteroperabilityFramework）[3]。总结起来，现有解决方案的问题在于：a．无论是SIF还是EMIF，二者都是基于复杂系统对接模式来实现互操作框架的通信模型，对于每个应用，通过为其数据库编写连接代码来实现互操作性。对于解决现有的教育MIS系统的互操作问题，它不失为一个有效的解决方案。但从发展来看，教育管理信息系统需要摆脱独立解决方案的实现模式，需要舍弃复杂系统连接的实现方法。b．要求信息语义与通信数据语义紧密耦合。正因为如此，这两种方案在设计时将信息模型和通信模型都作为标准的主要内容，但在实际应用中，一旦信息模型有变化，将直接导致通信模型的大范围修改。在这种情况下，我们以《教育管理信息化标准》[1]作为系统的信息模型，基于Web服务技术，构建异构信息系统互操作通信模型，实现教育管理信息系统建设中信息资源库与各单位、部门自治管理信息系统之间的信息交换。2基于WebServices的异构信息系统通信模型设计在网络分布式环境下，异构信息系统“互操作性”（Interoperability）依赖两个基础：信息模型和通信模型。信息模型包括模型结构和模型的语义约定，主要解决数据的相互理解问题；通信模型包括通信系统的体系结构和协议数据的语义规范，主要解决数据互通问题。对于异构信息系统的互操作，现在常规的解决方案是基于复杂系统对接模式实现的。针对每个应用，通过为其数据库编写连接代码来实现互操作性，该方案的缺点在于信息模型与通信模型间是一种紧密耦合关系，在实际应用中，一旦信息模型有变化，将直接导致通信模型的大范围修改。从发展来看，异构信息系统的互操作需要摆脱独立解决方案的实现模式，需要舍弃复杂系统连接的实现方法。有关信息模型的确定，需要从行业本身的特点出发，根据不同行业的实际情况来制订标准或规范，如电力行业的IEC61850标准、教育行业的教育管理信息化标准等。通过这些标准的建立，实现信息语义的确定性和一致性。在此基础上，需要有合适的通信模型来实现数据互通，基于XML技术的WebServices正是建立异构系统通信模型的有效手段，代表着发展方向。WebServices的主要目标就是在现有各种异构平台的基础上构建一个通用的与平台无关，语言无关的技术层，各种不同平台之上的应用依靠这个技术层来实现彼此的连接和集成。[4]这样WebServices就可以将分布于不同平台上的异构系统以一种柔性的，松耦合的方式集成为一个灵活的系统，这个系统可以根据要求不同而灵活的变化。2.1通信模型体系架构随着教育信息数据中心的建立，目前主要的数据互操作问题存在于数据中心与下属单位信息系统之间、各单位信息系统之间、单位内部各部门信息系统之间等多个层次，为此，我们设计如图1所示的通信模型总体架构。该体系结构由教育信息互操作服务平台（EISP）、服务注册中心（SRC）和数据交换代理（DEA）三个部分组成。（1）教育信息互操作服务平台（EISP）教育信息互操作服务平台完成数据中心到下属单位信息系统的数据交换、各单位信息系统间的数据交换，它由一系列中间件、服务、Web服务接口组成。其核心组件包括数据交换引擎、安全管理、系统管理以及Web服务接口。图1教育异构信息系统互操作体系架构教育信息互操作服务平台（EISP）服务注册中心（UDDI规范实现）数据交换代理A单位A信息系统数据交换节点A数据交换代理B单位B信息系统DEA数据交换节点B数据交换代理C单位C信息系统DEA数据交换节点C数据中心DEA安全模型嵌入其中数据交换引擎：基于SOAP消息实现数据交换，提供数据交换模式的管理、数据交换服务、基于元数据的数据变换服务等。安全管理服务：主要解决数据交换过程中可能存在的一系列安全问题，包括SOAP消息的安全通信、用户的统一身份管理、权限管理等。系统管理服务：实现对系统的配置管理和状态监控。通过系统管理服务配置EISP各部分的运行参数，服务的启停控制，监控整个系统的运行状态。Web服务接口：通过WSDL文档向外部应用程序和数据交换节点描述数据交换的相关Web服务以及安全策略。（2）服务注册中心（SRC）服务注册中心提供针对Web服务的注册管理和发布功能。各数据交换节点DEA通过EISP向SRC注册自己的数据交换Web服务，EISP根据注册的信息进行路由，主动调用数据交换节点的数据访问服务来向数据交换节点传送数据或从数据交换节点获取数据。（3）数据交换代理（DEA）数据交换代理代表各单位信息系统来主动参与数据交换事务。根据应用需求，DEA应包含数据转换、服务发布与描述、安全策略应用等功能。数据转换：根据数据交换的要求，基于元数据模型建立XML报文与关系数据库的双向映射。服务发布与描述：发布本地信息系统的数据交换服务，通过WSDL文档对服务的接口和调用方法进行描述，并通过EISP向服务注册中心（SRC）进行注册。安全策略应用：根据EISP安全管理服务的要求，建立相应的安全策略执行机制，并将所使用的具体安全策略通过WSDL进行描述。上述通信模型的实现，重点在于数据交换机制的建立。2.2数据交换机制在异构信息系统的互操作体系结构中，有关数据交换的事务处理主要包括两类：获取数据和更新数据。根据这两类数据交换，这里定义了两种数据交换机制，即“请求—应答模型”和“发布—预约模型”。请求—应答模型是指当DEA需要数据时即生成一个请求报文发送给EISP，EISP将请求报文转发给应答方DEA，应答方DEA即反馈一个应答报文，并通过EISP转发给原请求方DEA。发布—预约模型是指当应用程序更新本地数据后即通过它的DEA制作一个事件报文发送给EISP，EISP负责将该事件报文发布给所有关心该数据的其他DEA。（1）请求—应答机制当应用程序需要获取指定数据对象时，应通过DEA向EISP传递一个请求报文。请求报文中一般不需要指明谁是应答者，EISP就会去搜索服务注册中心，看哪些部门提供此方面的服务。服务注册中心返回查询结果，接着EISP将查询到的该数据对象服务的所有提供者作为应答者，并将请求报文传递给它们。在整个区域中，每一类数据对象都可以有多个应答者，并且非提供者也可以成为应答者。数据对象的每一个应答者都有权等待和处理请求，并返回一个或一组应答报文，通过EISP转发给原请求者。DEA在发送请求报文时也可以明确指定某DEA作为请求的应答者。这时请求方DEA应在它的请求报文中指定应答者。EISP在收到请求报文时会检查请求报文中是否存在指定信息，如果存在，还要检查指定的应答者是否具有应答权限。只有当上述条件满足，ZISC才会将请求报文转发给这个指定的应答者。下面举例说明请求—应答机制的实现。假设已有学生管理系统、图书馆管理系统和教学管理系统等三个数据交换节点，现在图书馆管理系统和教学管理系统需要从学生管理系统中请求报文1请求报文2应答报文1应答报文2EISP注册服务图书馆管理系统教学管理系统服务注册中心（UDDI）本地数据和制定的标准数据格式转换DEA1DEA2同上DEA3图2请求—应答机制学生管理系统获取学生数据，那么它们之间的报文传递关系如下所述（见图2）：a、注册服务：各DEA通过EISP向发送注册服务报文，注册成为服务使用者。（已注册则不必重复此过程）b、提供：DEA3通过ZISC向服务注册中心发送提供服务注册报文（其中必须包含关于此服务的WSDL文档描述或其URL地址），成为学生数据服务的提供者。（已成为提供者则不必重复此过程）c、请求：DEA1和DEA2分别向EISP发送请求报文，请求获取学生数据。d、转发：EISP接收DEA1的请求报文1，通过查询服务注册中心，指定DEA3为应答者，并将请求报文1传递给它（同样处理请求报文2）。e、应答：DEA3处理请求报文1（包括了和学生管理系统的数据转换过程），返回应答报文1给EISP（同样处理请求报文2）。f、转发：EISP接收DEA3的应答报文1，将该报文转发给DEA1（同样处理应答报文2）g、转换：DEA1将接收到的基于SOAP标准格式的应答报文1转换为本系统的内部的数据格式（同样处理应答报文2）（2）发布—预约机制数据对象的更新事件包括数据的添加、修改和删除。当应用系统更新了它的数据对象时，应通过事件报文将更新事件传递给EISP。数据对象的使用者（其它应用程序）如果希望及时获取数据的更新情况，应向EISP预约数据对象的更新事件。预约通过向EISP发送预约报文实现。事件发布者将数据对象的更新事件传递给EISP后，EISP负责将它传递给所有预约该数据对象更新事件的预约者。EISP转发事件报文时不会通知原事件发布者，因此事件发布者在完成事件发布后，就无需关心将有哪些应用程序接收更新事件，以及更新事件是否已传递给预约者。在整个体系中，每一类数据对象都可以有多个事件发布者，但谁可以取得事件发布权限则取决于EISP的访问控制管理。下面举例说明发布—预约机制的