（教育技术学专业论文）emif架构中zis的设计与实现.pdf

硕士学位论文 m a s t e r st h e s i s 摘要 随着计算机网络技术和通信技术的飞速发展，教育正逐步走向信息化。不断扩 大的教育规模给传统的教育管理模式带来了新的冲击与挑战，信息化教育管理也迫 在眉睫。 目前，虽然很多高等本、专科院校和中小学校都有自己的教育管理信息系统。 但是这些系统大多有着不同的来源，而正是因为这些产品的复杂来源，在实际应用 中呈现出很多问题：如开发商的不同、开发平台的差异使得各个管理信息系统之间 缺乏统一的标准，兼容性、规范性和互操作性都不够，加上网络平台的构成方式不 同，导致各个学校、各个部门之间的信息资源难以共享，因而形成了一个个“信息 孤岛”；低水平重复开发、资源的重复建设现象严重，极大地浪费了大量的人力、 物力和财力；许多软件可扩充性、开放性很差，不便于后期的升级与维护，对技术 发展和教育管理需求发展变化的适应性较差，容易被淘汰；很多软件应用面不够广， 属于单机版产品，或者只能应用于局域网、校园网内，不能应用于i n t e r a c t 。因此， 如何使各教育管理信息系统之间能够相互共享资源，实现互操作是当前教育管理研 究的热点之一。 为此，教育部教育信息化技术标准委员会制定了e m i f 规范( e d u c a t i o n m a n a g e m e n ti n f o r m a t i o ns y s t e mi n t e m p e r a b i l i t yf r a m e w o r k ，教育管理信息系统互操 作规范) ，e m i f 的出台打破了传统的教育管理模式，把原先分散的、孤立的教育管 理信息系统串联起来，并使得系统之间的数据共享和互操作成为可能，大大提高了 教育信息管理的效率。 本论文的工作就是根据e m i f 规范，进行其中一个重要组件区域集成服务 器( z o n ei n t e g r a t i o ns e r v e r ，简称z i s ) 的设计与实现。z i s 的设计与实现严格按照 e m i f 规范中的操作规范、数据规范和报文规范进行，利用x m l 定义共同遵循的数 据对象，利用m 1 甲协议进行报文的通信传输，并以x m l 文档作为报文的载体来 进行数据的交换。 本论 x z i s ( z o n ei n t e g r a t i o ns e r v e r ) a c c o r d i n gt oe m l fn o l t n s t h ed e s i g na n di m p l e m e n t a t i o n o ft h ez i si ss t r i c t l ya c c o r d i n gt oe m i fo p e r a t i n gn o r n l s ，d a t an o r m sa n dm e s s a g en o r m s z i su s ex m lt od e f i n ec o m m o nd a t ao b j e c ta n dh t t pp r o t o c o lt ot r a n s m i tm e s s a g e s w h i c ha l ei nf o r i l lo fx m l t h ep a p e r s i m p l e l y i n t r o d u c e st h em e c h a n i s mo fe d u c a t i o nm a n a g e m e n t i n f o r m a t i o ns y s t e mi n t e r o p e r a b i l i t ya n de m i fn o r m s ，m e s s a g en o m i s ，a n ds t r e s s e st h e f u n c t i o n a ld e s i g no fz i s ，t r e a t m e n ts c h e m eo fe l e v e nk i n d so fm e s s a g e sa n di d i o g r a p h i c i m p l e m e n t a t i o np r o c e d u r e s ，i n c l u d i n gt h ed e s i g na n di m p l e m e n t a t i o no f m 1t h e d a t a s h e e t s a n d s t o r a g ep r o c e s s k e yw o r d s ：e m i f ；z i s ；p u l lm o d e ；p u s hm o d e ；m e s s a g eq u e u e 1 2 研究现状 为了要从本质上克服上述软件的缺点，就必须制定一套完善的教育管理信息标 准。先来看看教育管理信息标准国内外发展的现状i z j 。 1 2 1 国内现状 我国教育管理信息系统标准化工作起步较早，但是发展还不太成熟。目前，此 方面做的工作主要有： 1 1 9 8 9 年，原国家教委为推动我国教育信息化建设，正式颁布实施了国家 教育管理信息系统总体规划纲要。但规划只是一个偏向行政指导的文件，并未涉 及具体的信息规范，且制定的大部分内容已经不适合目前的教育管理系统的要求。 2 1 9 9 1 年，原国家教委开始组织教育管理信息的标准化研究，1 9 9 4 年正式颁 布了普通高等学校的一系列管理基本信息集( 包括“高校教职工管理基本信息集”、 “高校学生管理基本信息集”等) 相对于目前整个国家各级教育管理部门和各级 各类学校来说，这些标准还不够，难以满足教育管理信息系统的建设要求。 3 教育部于1 9 9 9 年开始由发展规划司和教育管理信息中心牵头组织制定教 育管理信息化标准，并成立了教育管理信息化标准顾问组、专家组、课题组。 并于2 0 0 0 年9 月推出了教育管理信息化标准的第一部分：即“学校管理信息 标准”。但是，该标准仍然没有规定与平台无关、与应用程序无关的数据交换格式， 没有提供系统之间的互操作机制，要实现系统的互操作仍很困难。 4 2 0 0 1 年，教育部成立了现代远程教育标准化委员会，加0 3 年正式命名为“全 国信息技术标准化技术委员会教育技术分会”，专门从事教育信息化相关技术标准 的制定和推广工作。北京师范大学现代教育技术研究所承担教育管理信息系统互操 作实施规范制定，并于2 0 0 2 年8 月2 8 发布了e m mw d l 0 ，e m i f 规范是c e i 嬲 技术规范体系中教育管理信息系统互操 胛约际醴购徒逃芾硇枨蠓贡浠氖视越喜睿菀妆惶蕴蛔詈螅 很多软件应用面不够广，属于单机版产品，或者只能应用于局域网、校园网内。不能应用于i n t e r n e d 8 。 m 凋j 褥准醵驰警捌引l ：! 戳臻漤鼎鄹霉莹烈潼瑚蕊啮湾暖；浏爷札需邀囊嚣嚣 冀弦樊矧纠嚣张豁鞠。 。当前，该规范的最新版本为e m i fc d l 1 0参与制定企业组织包括h l t e l ( 中国) 公司、浙大网络公司、常州易维尔公司等十多家公司，但是目前应用该规范开发了软件产品的仅有北京校际通公司和常州易 业接口规范( 最新版本为1 1 版) 中就定义了一套标准化的结构用于在不同系统间 交换数据。这些结构为标准化数据绑定提供了基础以允许软件开发和实现者能够创 建可在由不同的软件开发商独立研制的系统间进行互操作的教学管理程序。 3 a i c c ( a v i a t i o ni n d u s t r yc b t ( c o m p u t e r - b a s e dt r a i n i n g ) c o m m i t l e e ，航空工 业计算机辅助培训委员会) a i c c 早在1 9 8 8 年就成立了，是一个国际性的技术培训专家的联合组织。a i c c 为航空业提供计算机辅助培训系统的开发、发布和评估及其相关的培训技术的指 南。但它提供了软件开发商在多种行业中都能使用的互操作标准。a i c c 提出的建 议对于大多数类型的计算机辅助培训来说是相当一般化的，因此可以广泛适应于航 空培训以外的其他行业。a i c c 的技术建议也就是a g r ( a i c cg u i d e l i n e s & r e c o m m e n d a t i o n s ) ，它包含9 个针对特定领域的技术建议。其中包括关于在不同 的c m i ( c o m p u t e rm a n a g e di n s t r u c t i o n ，计算机管理教学) 系统和c b t 课件间共享 数据和互操作的规范指南。 4 s i f ( s c h o o l si n t e r o p e r a b f l i t yf r a m e w o r k ，学校互操作框架) s i f 是由美国的一些软件公司和教育机构等为帮助克服数据共享的技术障碍， 帮助学校管理的流畅，改进学校管理水平而发起的，主要目的是研究开发一个开放 的规范用以确保k 1 2 教育管理软件应用能更有效地一起工作。目前已有数百家学 校、教育机构和企业加入s i f 支持者的行列。他们致力于创建一套规则和定义，以 允许不同公司的软件程序能快速、无缝、安全地共享信息这套规则与定义被称为 s i f 执行规范。其最新版本是2 0 0 4 年3 月完成的s i f i m p l e m e n t a t i o n s p e c i f i c a t i o n1 5 。 使用遵从这规范的软件。可以使学校系统之间共享数据成为可能，而无器各自再 另外单独编程，也不用每个软件商去费力地理解其他软件商的应用。 在包括上面提到的各种规范中，大多数是主要针对教学内容和教学软件架构的 规范。基本上无法直接借鉴到教育管理信息系统的数据共享和互操作问题上。而s i f 规范正是针对美国学校管理信息系统的标准化问题提出的解决方案。虽然它是基于 美国当地的教育环境制定的，其数据定义具有十分浓厚的美国本土气息，并且它主 要是针对中小学学校管理信息系统的，但是，这一方案的设计思想对我们还是有极 大的参考价值的。 1 3 研究意义 e m i f 的出现，使得把分散的、孤立的信息串联起来，解决了部门与部门之间、 区域与区域之阀的信息共享与数据交换，使得教育管理信息可以横向交换与纵向传 4 输，有助于管理部门的科学决策。与此同时，有效地利用了原有的管理信息系统， 避免了大量浪费与行业垄断，维护了有效的竞争和激励机制，推动了优质服务的可 持续发展i j j 。 但是标准不能仅停留在理论上的探讨与研究，必须注重理论联系实际、指导实 践，并通过实践来不断的完善这个标准，使之能够更好地为教育管理信息化服务。 这套规范展现了一个开放型网络，网络中包括了任意多个教育管理信息系统，而且 各个系统之间可以进行互操作，从而达至信息资源管理更加系统化、科学化，体现 了管理的高效性、便捷性。 从技术上来说，根据此规范来开发、设计教育管理信息系统也呈现多元化的现 象，如何选择一种便捷、高效的技术来实现规定的服务内容，也是非常值得探讨的， 具有深远的现实意义，并在实践中发现规范存在的问题，为规范在理论的完善提供 有价值的参考意见 1 4 本文的工作 教育信息管理互操作规范旨在解决目前不同教育管理信息系统之间的互操作 问题。如果按照e m m 规范完整地开发一套系统，并使该系统能够正常运行，那将 包括四大方面的工作，分别为区域集成服务器的设计与实现、代理的设计与实现、 ) 姒l 报文的加密与解密以及对现有管理信息系统应用程序的修改等。本文的工作 就是根据e m mc d l 1 规范的体系结构、报文规范和数据规范，并结合实际应用需 求来设计并开发e m i f 区域中的核心组件区域集成服务器( z o 耻i n t e g f a t i o n s c h ，简称为z i s ) ，并使之能够有效的与代理( a g 锄t ) 及应用程序配合使用，真 正实现教育管理信息系统之间的互操作现将工作大致分为以下四大类； 1 根据e m i f x 1 5 本文的章节安排 本文共分为7 章。 第一章：绪论。本章主要介绍了基于e m i f 规范的教育管理信息系统的研究背 景、教育管理信息标准国内外研究现状、本论文研究意义及主要工作。 第二章：教育管理信息系统互操作机制。本章主要介绍了教育管理信息系统实 现互操作所要遵循的规范与要求( e m i f 体系结构与报文规范) ，以及实现互操作所 需要的技术支持( x m l 技术) 。 第三章：区域集成服务器z i s 的设计。本章结合e m i f 规范体系及实际应用需 求，从z i s 的功能模块之间的逻辑关系入手，对z i s 进行设计，并给出z i s 的功能 设计模型和子系统模型。 第四章：区域集成服务器z i s 的实现。本章根据第三章的z i s 设计方案，对z i s 后台数据库进行了逻辑与物理设计，并根据z i s 功能模块，逐个进行编码实现工作， 最后给出z i s 测试实例。 第五章；总结与展望。本章主要对本论文的研究成果及其优缺点进行了总结， 提出了需要进一步研究完成的工作，并指出了e m i f 规范在运用中所呈现的不足。 6 硕士学位论文 m a s t e r st h e $ 1 s 第二章教育管理信息系统互操作机制 2 1 什么是软件的互操作 软件的互操作就是指各类软件之间能够彼此交换和使用对方的信息。软件的互 操作要求互操作过程对用户来说是透明的，并且整个互操作过程与操作系统无关、 与传输协议无关、与程序开发语言无关、与开发商无关等等。 互操作可以分为横向互操作与纵向互操作。横向互操作是指处于同一应用层次 或者同一应用区域内的软件之间的互操作，一般是不同类软件之间的互操作；纵向 互操作则是指处于不同应用层次或者应用区域内软件之间的互操作，一般是同类软 件之间的互操作。 2 2 软件互操作的架构方式 目前，实现软件互操作的架构方式主要有三类：p 2 p 架构方式( 基于点对点技 术) 、w e bs e r v i c e 架构方式( 基于端到端技术) 和s i f 或e m i f 架构方式( 基于中 间件技术) 。 p 2 p 架构方式采用的是两个应用软件之间直接进行信息交换，不通过第三方软 件或组件，这种方式只适合于在互操作软件数量不多的情况下使用。如图2 1 所示。 图2 1p 2 p 架构方式 w e bs c r v i c a 是一种新的w e b 应用程序分支，它们是自包含、自描述、模块化 的应用，可以在网络( 通常为w e b ) 中被描述、发布、查找以及通过w e b 来调用， 该架构方式虽然采用的也是两个应用软件直接进行信息交换，但是该互操作过程必 须依赖于w e b 服务的调用，即需要通过服务注册中心。如图2 2 所示，其中w s d l 为w e b 服务描述语言，u d d i 为统一描述发现与集成【4 】。 7 硕士学位论文 m a s t e r 。st h e s i s 图2 2w e b s e r v l c e 架构方式 e m i f 架构方式源于s i f 架构方式，信息发送方与信息接收方必须通过中间件 的转发来间接实现信息交换。该架构方式的最大优点就是通信双方可以是异步通 信，中间件可暂存信息。如图2 3 所示。 图2 3s i f 架构方式 三种架构方式相比之下，从通信可靠性、可伸缩性及平台异构适应性来看，e m i f 架构方式是三者中最值得采用的。我国教育部教育信息化技术标准委员会制定的 教育管理信息系统互操作框架( 简称e m i f ) 也就是在借鉴美国s i f 思想的基础 上，结合我国的教育信息化标准与实际国情而建立的。 2 3 教育管理信息系统互操作规范简介 教育管理信息系统互操作规范是为了使不同的教育管理信息系统之间能够交 换和使用彼此的信息而制定的教育管理信息系统的技术规范。该规范提出了一个教 育管理信息系统互操作框架的概念，并通过对框架及其组件的描述，展现了一个由 任意多个教育管理信息系( e d u c a t i o nm a n a g e m e n ti n f o r m a t i o ns y s t e m ，简称e m i s ) 8 腰士学住论文 m a s t e r st h e s i s 代理的主要作用是把应用程序的数据绑定成符合e m i f 规范的x m l 报文，或 者把收到的x m l 报文解析成应用程序理解的格式。代理程序可以集成在应用程序 内部，也可以作为挂接在应用程序上的一个独立的代理程序。 z i s 和a g e n t 通过使用e m i f 报文规范进行数据交换与系统互操作。报文是规 范的x m l 文档，包含数据和对数据进行操作的信息。 2 3 2e m i f 数据交换模式 e m i f 内各个子系统之间的互操作主要实现两类数据交换的功能： 一个子系统获取另一个子系统的数据。 一个子系统的数据变化时，共享该数据的其它子系统也得到相应数据更新。 根据这两类功能e m i f 创建了两类数据传递模式。一个是“请求与应答模式”， 另一个是“发布与预约模式”。 1 、请求应答模型 如图2 6 所示，想要获取数据的系统( 图 书馆管理系统) 向z i s 发出请求报文，z i s 根 据存取控制列表查找数据的提供者( 学生管理 系统) ，并将请求报文传递给数据提供者，当 数据提供者向z i s 发回相应的应答报文后， z i s 再将其返回给数据的请求者。 要作为数据的提供者，应用程序必须通过 代理先向z i s 发送一个提供报文，每个区域 的每个数据对象只能有一个提供者，而一个区 域内指定的对象却可能有多个应答者。为了控 制哪些数据可以互换，以及谁可以获得这些数 据，z i s 必须提供一个存取控制系统，来限制 谁可以发送请求报文和应答报文，以及哪些数 据可以允许被提供、被请求、被应答、以及被 预约。该存取控制系统必须对每个已注册的应 用程序坚持使用同样的原则。此外，数据的请 求者可以指定应答者，也可以由z i s 指定应答 科5 1 。 2 、发布预约模型 1 0 图2 6 请求一应答模型 图2 7 发布一预约模型 代理程序可以通过发布关于e m i f 数据对象的添加、改变、删除的事件报文来 传递数据的更新信息。如果其它应用程序需要随时得到这些更新信息，就需要由代 理程序进行预约。 如图2 7 所示，一个系统( 图书馆管理系统) 向z i s 发出“预约”报文，预约 某数据的更新信息，当被预约的数据所在系统( 学生管理系统) 数据更新时，该系 统要向z i s 发布“事件”报文，z i s 迅速将事件报文根据存取控制列表发送给预约 者，从而实现数据的迅速更新。 为了确保可伸缩性和可靠性，e m i f 要求数据交换使用异步通信模式，从而避 免报文的丢失。同时，为了提高通信的安全性，e m i f 提供了可靠的安全机制：加 密保护( e n c r y p f i o n ) ，身份验证( a u t h e n t i c a t i o n ) 和存取控制( a c c c s s c o n t r 0 1 ) 。加 密和身份认证机制允许发信方代理向z i s 要求建立传输通道时应达到某种加密和身 份认证级别，存取控制机制允许区域管理员手工实现对代理的操作权限实行控制【鄂。 2 3 3 e m i f 要求 1 、z i s 与代理的命名规则 e m i f 要求每个代理和z i s ”都有一个区域内准一的标识。这个标识放在每个报 文头( e m i f _ h e a d e r ) 的e m i f _ s o u r c e l d 元素中，表示报文的来源，z i s 根据这个 标识来发送反馈报文。e m i f 规范要求代理和z i s 的标识使用英文字母( a - z ，n - z ， 大小写敏感) 、数字( 0 - 9 ) 、下划线( 一) 、连接符( ) 、实点( ) 来描述，并且长 度不能超过2 5 5 个字符，标识应使用描述性的词汇以表明所在地区。此外，代理和 z i s 的标识名最好允许用户进行编辑，这样当标识冲突时，用户可作适当修改以保 证标识在区域中的唯一性嘲。 2 、数据对象标识 e m i f 的数据对象的名称可以使用中文名称。数据对象的名称要尽可能描述出 对象实质，所有数据对象都有一个包含其标识的属性，用r e f l d 表示。为保证标识 的唯一性和标识产生的一致性，规范要求采用全球唯一标识( g l o b a l l yu n i q u e i d e n t i f i e r ，g u i d ) ，g u i d 必须为3 2 个字符的长度，并且使用十六进制数字表示， 中间不包含任何空格或标点符号【5 j 。 3 、报文的标识 代理或z i s 制作的每个报文都应该有个报文标识符e m i f _ m s g l d ，以用来区 别报文。为了排除报文标识符重复的可能，也为了提供一个产生标识符的持久方法， e m i f 也要求报文标识采用g u l l ) 。该标识符在e m i f 中的使用是为了区分对象，不 1 1 硕士学位论文 m a s t e r st h e s i s 会在任何客户端浏览器上显示，也不会被正在使用的应用程序替换【卯。 使用唯一标识符的原因是e m l f 的报文处理使用异步通信方式，也就是说，针 对特定的请求报文发出的应答报文不能实时传达，因此需要通过报文标识使应答报 文和原请求报文建立起正确的对应关系。 4 、对代理和应用程序的要求 任何一个应用程序要想加入e m i f ，首先必须为自己创建一个代理程序。代理 是应用程序的延伸，它的作用是与z i s 通信。代理能妥善处理所有的e m i f 报文， 包括不支持的报文和数据对象。 应用程序及代理应主要执行以下职能1 5 j ； 1 ) 与z i s 建立连接，应用h r 砰s 协议向z l s 提供或预约数据对象； 2 ) 向z i s 发布数据更新事件； 3 ) 数据对象的提供者( 代理) 应答请求报文； 4 ) 应用程序的必要修改，以确保其代理能够将其关心的数据对象的更新信息 发送到e m i f ； 5 ) 支持身份验证和数字签名( 可选) ； 6 ) 选择性报文阻塞机制解决死锁现象。 5 、对z i s 的要求 区域集成服务器( z 硌) 是区域内所有代理的管理中心，它负责将代理的注册 信息和数据存取权限保存下来并进行管理。z i s 应该实现以下功能和要求网： 1 ) 注册代理，包括其他z i s 的注册： 2 ) 存取控制列表( a c l ) ，对各代理的操作权限进行控制； 3 ) 管理数据对象提供信息： 4 ) 管理数据对象预约信息； 5 ) 使用报文队列服务机制，保证报文的稳定性； 6 ) 选择性报文锁定( s m b ) 解决死锁问题； 7 ) z i s 管理功能： 8 ) 提供数据对象e m i fz o n e s t a t u s 。 2 3 4 蔓l m 礤报文规范 为了保证互操作性，e m i f 定义了一组用于代理程序和z i s 之间交流的报文。 这些报文共1 1 类，他们的作用分别是【5 】： e m i f ：a c k ：用来通知是否成功接收或处理报文。 e m i fe v e n t ：用于发布数据对象更新事件。 e m i fp r o v i d e ：用来提供数据对象。 e m i fr c 西s t e r ：用于注册代理。 e m i fr c q u c s t ：用于获取数据对象。 e m i fr c s p s e ：用于应答对数据对象的请求。 e m 球s u b s c r i b c ：用于预约数据对象更新事件。 e m 噩- s y s t e m c 0 n 柏同：用来控制数据流动。 e m 啦p r 0 、，i d e ：与e m 皿p r o v i d e 作用相反，用来取消可提供的数据对象。 e m i f 二v 眦g i s t c r 用来取消注册。 e m 啦- u n 辄b s c r i b e ：用来取消对数据对象更新事件的预约。 报文是e m 区域中各组件通信的内容，是具体通信数据的载体，数据通过报 文被封装起来。然后通过唧i 甲s 协议进行传输。e m 报文规范定义的1 1 类报文 的都具有特定的格式。每个报文都要包含两个最基本的元素，一个是报文的根元素 e m i f - - m e 鲒a g c ，另一个是报文头元素e m i f h e a d c r ，其中e m 叫i c a d e r 中记录了 报文的m 、发送时间、安全级别、报文来源等信息。如注册报文基本格式如下： ? 瑚i 啷i o n - 。1 0 ”c o d 缸g = 。g b 2 3 1 2 ”? 趣m m 醐g ex m l n s = 。h n p ：o d 3 4e m i f u m e l z i s t e f 处理流程 2、提供报文的处理 代理可以通过e m i f _ p r o v i d c 报文将它的数据对象提供给其他应用程序，或者使用e m i f _ u n p r o v i d e 报文来取消对数据对象的提供。 一个e m i f _ p r o v i d e 报文e m i f _ u n p r o v i d e 报文可以一次包含多个数据对象，即 视为一个整体，如果在处理中，任意一个数据对象出现错误，整 嚣嚣塑，鍪霎耄潆萎蕊曾奏鏊割剐要戳蠹 影副毳型鎏鬟姜露面倒m f _ s e c u 砖c h m e l 蚰m珥scrity ( e m i f - s 0 u r c c ldagenln：ccnuemif_sourceid殂sca倒河f_p虹nati仰id删fjieade吐x 硕士学住论文 m a s t e r st h e s i s 1 1 1 0 2 4 0 帅 p u l l h t t p ：2 0 2 1 1 4 3 5 1 3 1 u p l o a d f i l e s a v e f i l e a s p 要解决系统互操作的问题，就必须需要一种与平台无关、与应用程序无关的数 据交换格式，利用一致、标准的客户机界面能够方便地存取、解释和显示它，而这 些要求就使得x m l 成为了e m i f 的理想选择，x m l 是一种完全可移植的数据格式。 利用x m l 这种的中间格式，每个应用程序都能维护自己的格式，它能简便、精确 地进行数据与x m l 格式之间的转换。 1 4 硕士拳住论文 m a s t e r st h e s i s 第三章区域集成服务器z l s 的设计 3 1z i s 的需求分析 根据第二章中e m i f 规范对z i s 提出的要求，并结合实际应用需要，可以发现 区域集成服务器主要应该具备以下几个功能【6 l ： 区域集成服务管理功能：主要定义哪些a g e n t ( 也可以是z i s ) 有权与z i s 建 立连接 定义每个代理对数据对象的存取控制权限，包括数据对象的提供、预约、 添加、修改、删除、请求与应答，并对数据对象的提供信息、预约信息进行管理等 等 提供a g c n t 与z i s 的连接功能：为a g e n t 提供连接服务，并对趣e n t 的每个请 求进行身份验证。 报文处理功能：对接收到的报文进行处理，并向a g c n t 发送应答报文。 报文转发功能：对接收到的请求报文、事件报文和应答报文先存储在报文队列 服务器中，将注册为“推”模式的a g c n t 的报文自动转发给该代理。 因此，按功能需求来分，z i s 可分为六个子系统：区域集成服务管理子系统， 为z i s 进行管理提供服务；a g 甑t 登录连接与验证服务子系统；报文处理服务 予系统；报文转发服务子系统：报文队列服务子系统：数据访问子系统，实 现对后台数据库的数据访问。 3 1 1 区域集成服务管理子系统 该子系统主要负责z i s 的信息配置与定制，主要包括设置z i s 标识名、z i s 的 u r l 和a g c n t 与z i s 的通信协议( t c p 球协议) 、z i s 服务的启动与停止、a g e n t 的添加与删除、z i s 日志进行分析、z i s x 硬士学位论文 m a s t e r s t h e s i s 如果属于请求报文、应答报文或者事件报文，相应的处理器将把报文送入报文队列 等待时机把报文转发出去。 通知报文 图3 1z l s 功能模型图 3 3z i s 的消息与管理机制 z i s 是实施应用集成服务器的物理实体，对所有已注册的a g t 提供集成服务， 负责所有的访问控制和系 统内部的路由并管理区域 中的所有共享数据的程 序z i s 用消息服务机制、 消息传输机制、管理机制 以及数据库服务机制来保 证上述功能的实现，如图 3 2 所示【踟。 3 2 1 消息服务机制 消息服务机制主要解 决的问题在于报文的收发 与处理，由于e m i f 定义 了一套a g e n t 与z i s 之间 交流的报文规范，因此使 图3 2z i s 的消息与管理机制 1 7 顾士学住论文 m a s t e r st h e s j s 得双方能够顺利地进行通信，从而达到互操作。处理报文是消息服务机制的核心， 报文内容涵盖了规范中的十一类报文，各类报文具体处理过程如下【5 l ： 图3 3 e m r e g 妇e f 处理流程 l 、注册报文的处理 代理成为e m 礤的组件之前，必须先在z i s 注册，为z l s 提供必要的连接信息。 硕士学位论文 m a s t e r st h e s i s 3 、预约报文的处理 代理可以使用e m i fs u b s c r i b e 报文预约某些数据对象的更新事件( 如添加、修 改、删除) 。或者使用e m i fu 璐u b s a 曲e 报文来取消对数据对象的预约。代理可以 指定目标代理( 在e m i f d e s t i n a t i o n i d 中指定) ，也可以预约所有事件发布者的事件 报文( 不指定代理) 。 一个e m i f j u b s c r i b c 报文厘m m1i n s u b s c r i b e 报文也可以一次包含多个数据对 象，如果在处理中，任意一个数据对象出现错误，整个操作都将认为是失败的，也 就是不会将任何变化信息写入数据库的提供者数据表吼 预约报文处理处理流程如图3 7 所示，取消预约报文处理流程如图3 8 所示。 图3 7e m 毋s u b s c r i b c 处理流程 项士学位论文 m a s t e r st h e s i s 4 、事件报文的处理 图3 8e m i f _ u n s u b s c n b e 处理流程 图3 9e m i fe v e n t 处理流程 当应用程序对数据对象进行了更新操作( 如添加、修改、删除) ，它的代理应 将更新情况通过e m i fe v e n t 报文传递给z i s ，并由z i s 将更新事件分发给数据对 象的各个预约者。事件报文处理流程如图3 9 所示。 5 、请求报文的处理 当应用程序需要e m i f 数据时，它可以通过代理向z i s 发送e m i fr e q u e s t 报 文索取需要信息。z i s 收到请求报文后，会返回一个e m i f _ a c k 报文，以通知请求 方代理z s 已将请求发送给应答者或者该报文不能处理。 如果请求方指定了应答者，z i s 将直接把请求报文发送给应答者，如果没有指 定应答者，z i s 将根据提供者数据表，将数据对象的所有提供者作为应答者，并将 报文传递给它们【5 】。请求报文处理流程如图3 1 0 所示。 图3 1 0e m i f _ r e q u e s t 处理流程 6 、应答报文的处理 请求报文由z i s 传递给应答者后，应答代理首先返回一个e m i f _ _ a c k 报文。如 果报文中没有错误信息，则表示应答者正在继续处理请求报文。 如果应答者代理成功处理了请求报文，将返回一个或一组由e m i f _ r e s p o n s e 报 顾士学位论文 m a s t e r st h e s i s 文组成的应答报文1 5 1 。应答报文处理过程如图3 1 1 所示。 图3 1 1 e m i f _ r e s p o n s e 处理流程 3 2 2 消息传输机制 为了确保所有的代理和z i s 之间能够互相通信而不用考虑软件的生产厂家的 差异，所有的代理和z i s 都应该支持e m i fh t y p 传输层协议。e m i fm 1 甲协议以 h t t p l 1 作为参考规范。 报文的传输要考虑到的一个重大方面就是数据的安全性问题，报文传输层可以 硕士举住论文 m a s t e r st h e s i s 通过数据加密、客户端和服务器端的验证等方式保证数据传输的安全性，必要的时 候，还提供数据的压缩，这对于传输大量x m l 报文是很重要的。 3 2 3 数据库服务机制 与z i s 相连的数据库中存储着多个列表。如代理列表、存取控制列表、提供者 列表、预约者列表、数据对象列表、消息队列等，这些与z i s 的管理是紧密相关的， z i s 的管理和存储离不开这些列表。 具体数据表的设计与存储过程的实现请见4 2 系统数据库的设计与实现。 第四章区域集成服务器z i s 的实现 整个e m i f 采用c 幅架构，利用w 曲开发技术来解决报文的传输，传输协议为 r 兀甲协议，在x m l 报文传输过程中a g e n t 和z i s 互为服务器。 4 1 系统运行环境、开发工具及技术 整个系统运行的环境为w m d o w s2 0 0 0s c c r ，系统必须装有i i s5 o 。z i s 系统 开发工具采用的是b o d a n dd c l p h i7 0 ，w 曲开发技术采用的是a s p 技术，数据库采 用的是s q l s c r v e r 2 0 0 0 。 b o i l 孤d d 嘶越存在它的i j n u x 版k y l i x 开发工具，因此d e l p h i 的代码经过k y l i 【 编译之后可以在u n 慨上运行，因此，也可以让系统跨平台使用。 4 0 系统数据库的设计与实现 根据e m m 的实际需要与报文规范，z i s 至少需要建立1 0 个表，用来存储各类 信息，这1 0 个表分别是：代理注册信息列表、数据对象列表、数据对象提供列表、 数据对象预约列表、存取控制列表、消息存储列表、报文发送队列、请求与应答列 表、预约列表和) a l 文件列表。 4 2 1 代理注册信息列表( a g 拍t l t e g i s t e r l 舾t ) 代理注册信息列表主要用来存储每个代理的具体注册信息，数据主要来源于注 册报文，其中字段s l p i l i g 是表示该代理是否处于睡眠状态，它的数据来源于 s y s t c m c 衄t | d l 报文，z i s 在发送报文前将检测目标代理是否处于允许接收报文状态。 由于代理标识是区分大小写的，而s q ls e r v e r 数据库本身不区分字段值大小 写，因此需要编写自定义函数s t r c o m d 来对字符的大小写进行严格核对。 此外，代理的删除将影响到其它表中的相关记录，比如：删除代理的同时，将 删除该代理提供数据对象的信息、预约数据对象的信息、消息队列中相关信息、报 文队列中目标地址是该代理的信息等等。为了提高数据更新的准确性 0 rd b o s h c o m p ( d e s d ， s o u r c e i d ) = 1 s e tn o c o 衄t o 盯 自定义函数：( 严格区分字段值大小写) c 舳f u n o ns t r c o 街p ( 鼬l 尉：h a 且( 5 0 ) s 仃2v a r ( 5 0 ) ) r e ny r n s d 兀卫g e r a s b e g d b ：i a r e i 烈1 雹g e r d e c l a r e yd r r s e r i = 0 s e 】r y = 1 d e c i r e i k n d 盯 s e t i i = l e n 皿瓜l m 暇n m 倒 s 扛1 ) ) ) 球l e n ( i 胍蹦( r 豫喇l r l ) ) ) 瑾n o 积岬蹦( s 眈) ) ) s e t i k n = i 卫n o 孤n 琊盯r 蹦 s 眈) ) ) w u ( i 0t h e n b e g i n t e m p q u e r y a c t l v e ：= f a l s e ； t e m p q u e r y s q l c l e a r ； t e m p q u e r y s o l a d d ( s e l e c t f r o m a c c e s s c o n t r o l l i s t w h e r e a g e n t l d e n t i f i e r = t e m p q u e r y s q l a d d ( ”、 x m l m e s s a g e p r o v i d e e m i f _ p r o v i d e e m i f _ h e a d e r e m l f _ s o u r c e l d + | ) t e m p q u e r y s q l a d d ca n dd a t a o b j e c t n a m e = + + d a t a o b j e c t n a m e + ) ； t e m p q u e r y o p e n ； i f t e m p q u e r y r e c o r d c o u n t ot h e n b e g i n i f t e m p q u e r y f i e d v a l u e s p r o v i d e p u r v i e w t h e n b e g i n t e m p q u e r y a c t l v e ：= f a l s e ； t e m p q u e r y s o l c l e a r ； t e m p q u e r y s o l a d d ( s e l e c t 。f r o md a t a o b j e c t p r o v i d ew h e r ed a t a o b j e c t n a m e = ； t e m p q u e r y s q l a d d ( + d a t a o b j e c t h a m e + “飞 t e m p q u e r y o p e n ； ，”“”已存在该数据对象 i f t e m p q u 口 y r e c o r d c o u n t ot h e n b e g i n i f t e m p q u e r y f i e l d v a l u e s 1 ) a t a o b j e c t p r o v i d e r 】 x m l m e s s a g e p r o v i d e e m i f _ p r o v i d e e m i f _ h e a d e r e m i f _ s o u r c e l dt h e n b e e , l n e m i lc a t e g o r y ：= 6 ； e m i l e r r o r c o d e ：= 4 ； b r e a k ； e n d e l s ec o n t i n u e ； e n d ”“”“”“该数据对象不存在 e l s ed l 删e l t 0 s d n e x i ： e n d ： 丘n a l l y d t s r e g i s t e l 胁； d 蛹i c l b s c n d f 慨： e n d ： e n d ： 4 4 测试使用 4 4 1z i s 界面介绍 图4 1 区域集成服务器界面 如图4 1 所示，区域集成服务器的操作界面主要分为四大类，六个部分，这六 个部分分别为：区域集成服务器设置、区域集成服务器注册、代理信息、存取控制 列表、数据对象提供列表和数据对象预约列表。 区域集成服务器设置：该页面主要是对服务器的标识名、名称、u r l 进行编辑 硕士学位论文 m a s t e r st h e s i s 与修改，此外，还包括数据库的连接设置。 区域集成服务器注册：作为区域服务器，它也可能充当代理的身份向上一级z i s 进行注册，该页面主要是用来设置注册报文具体数据内容并进行注册操作的，可设 置参数包括通信模式、最大数据缓冲量、注册名、上级z i s 标识与网址等，同时该 页面也提供了取消注册的操作。 代理信息：该页面以列表的形式列出所有在本服务器注册的代理的相关信息。 服务器管理员可以对代理进行增删，也可以对代理的信息进行修改。 存取控制列表：该页面以列表的形式列出了所有代理对所有数据对象的操作权 限，服务器管理员可以对代理的权