最新CETSC-EMIF工作组工作总结.pptVIP

1.2 正式会议 第一次会议（2003年8月29日，北京西郊宾馆） 确定工作组的工作目标和工作内容 提交EMIF1.1工作草案 第二次会议（2003年9月15日，北京大学） 讨论EMIF体系结构相关问题 推出EMIF1.1第一个修改草案 第三次会议（2003年11月26日，北京大学） 讨论EMIF与SIF的专利权和著作权关系 讨论EMIF加密和数字签名方案 讨论EMIF数据规范相关问题 推出EMIF1.1第二个修改草案 * 1.3 非正式会议 建立工作组论坛 /gse_forum/list.asp?boardid=42 非正式讨论 与Intel（中国）公司 与中教育星公司 与其他公司 推出EMIF1.1第三个修改草案 * 二、工作成果概述 经过三次重大讨论、修改，EMIF1.1已经成为比较稳定的版本 更灵活，能广泛兼容各种互操作情形和各类教育软件产品 更实用，易于开发商开发实现 更开放，允许用户自扩展互操作内容（数据对象） 更具本土特征，体现我国教育信息管理的需求特征 参加EMIF工作组的多家开发商已开发实现EMIF1.1的符合性教育软件产品 * 2.1 EMIF1.1体系结构 单区域结构模型 人事管理系统 + 代理 成绩管理系统 + 代理 图书馆系统 + 代理 办公管理系统 + 代理 资源库系统 + 代理 网络教学平台 + 代理 学籍管理系统 + 代理 其他应用软件 + 代理 学科网站 + 代理 信息平台 + 代理 ZIS * 2.1 EMIF1.1体系结构 数据交换模型 数据查询：请求—应答模型 数据更新：发布—预约模型 ①注册和提供 ②发送请求报文 ③转发请求报文 ④发送应答报文 ⑤转发应答报文 ⑥发送预约报文 ⑦发送事件报文 ⑧转发事件报文 学籍管理系统 代理 成绩管理系统 代理 人事管理系统 代理 图书馆管理系统 代理 ZIS ① ④ ③ ⑤ ② ① 请求-应答流程 ① ⑥ ⑧ ① ⑦ 发布-预约流程 * 2.1 EMIF1.1体系结构 异步通信模型 EMIF要求代理之间的通信本质上采用异步通信，即代理之间完成一次通信需要经过两次报文循环 异步通信可以保证通信稳定性 代理A ZIS 代理B EMIF_Request EMIF_Ack EMIF_Request EMIF_Ack * 2.1 EMIF1.1体系结构 安全模型 身份验证 Digital Certificate XML-Signature 加密 XML-Encryption 存取控制 控制代理对每一数据对象的操作权限（请求、应答、预约、发布） ZIS端实现 * 2.1 EMIF1.1体系结构 支持同一数据对象的多提供者 支持在典型EMIF区域中，同一类数据对象（如：P学生基本信息）存在多个提供者 当存在多个提供者时，针对同一个数据对象的EMIF_Request，对应着所有提供者的EMIF_Response的集合 * 2.1 EMIF1.1体系结构 支持推、拉两种报文传递模式 推：ZIS主动向代理建立连接并传递报文 拉：代理首先向ZIS建立连接，发出EMIF_GetMessage命令，然后ZIS在连接中将报文传递给代理 采用哪一种模式由代理向ZIS注册时指定 两种模式本身无优劣之分，关键是代理和ZIS应按照一致的模式通信 * 2.1 EMIF1.1体系结构 要求EMIF HTTP为基本传输层协议 EMIF允许代理与ZIS之间使用任何传输协议，EMIF HTTP为默认协议 当发现其他传输协议不能完成通信时，应使用EMIF HTTP重新建立连接 EMIF HTTP是HTTP1.1（RFC2616）的子集 支持Post method 支持200-OK Response 支持Keep-alive Connection 不支持Transfer Encoding 不支持Data Chunking 不支持Connection:Upgrade * 2.1 EMIF1.1体系结构 要求代理端解决死锁问题 死锁（deadlock）：报文在队列中被按序逐一处理，某时刻当某个报文的处理必须依赖于其后续某个报文首先被处理而报文队列又不允许时，即发生死锁 选择性报文阻塞（Selective Message Blocking，SMB） 代理以锁定方式保留当前不能立即处理的报文 锁定其他同类报文（仅当被锁报文为EMIF_Event时） 向ZIS发送EMIF_Request以获取所需信息 处理ZIS反馈的EMIF_Response 处理原锁定报文 解锁所有锁定报文 要求SMB机制在代理端实现 * 2.1 EMIF1.1体系结构 命名和标识 代理和ZIS应具有区域内唯一的标识 命名规则 组成：英文字母（A-Z，a-z，大小写敏感） 数字（