现基于XML的We与实bGIS通信协议的设计与实.docx
- 文档编号:11209778
- 上传时间:2023-05-29
- 格式:DOCX
- 页数:18
- 大小:168.91KB
现基于XML的We与实bGIS通信协议的设计与实.docx
《现基于XML的We与实bGIS通信协议的设计与实.docx》由会员分享,可在线阅读,更多相关《现基于XML的We与实bGIS通信协议的设计与实.docx(18页珍藏版)》请在冰点文库上搜索。
现基于XML的We与实bGIS通信协议的设计与实
基于XML的WebGIS通信协议的设计与实现
刘昕鹏,罗英伟+,汪小林,许卓群
(北京大学计算机科学技术系,北京100871)
DesignandImplementationofXML-BasedCommunicationProtocolsforWebGIS
LIUXin-Peng,LUOYing-Wei+,WANGXiao-Lin,XUZhuo-Qun
(DepartmentofComputerScienceandTechnology,PekingUniversity,Beijing100871,China)
+Correspondingauthor:
Phn:
+86-10-62763373,Fax:
+86-10-62765805,E-mail:
lyw@,
Received2003-03-17;Accepted2003-09-04
LiuXP,LuoYW,WangXL,XuZQ.DesignandimplementationofXML-basedcommunicationprotocolsforWebGIS.JournalofSoftware,2004,15(6):
899~907.
Abstract:
Concerningthefeaturesofcomplexobjectsandmassivedatatransmission,anewXML-basedmethodtodesignandimplementcommunicationprotocolsforWebGISispresented.WiththeaidofUML,thetypicalrequiringandrespondingprotocolsofWebGISareanalyzedthroughobject-orientedconcept.Basedonobjectorientedanalysisoftheprotocols,themechanismofdesigningcommunicationprotocolsfollowingW3C’sXMLSchemaspecificationisillustrated.Finally,themainflowofembeddingtheprotocolsintoWebGISisgivenbypackingandparsingXML-basedprotocolsinaWebGISapplicationprototype.ThiskindofprotocolscanbeusedinspatialinformationexchangeamongheterogeneousWebGISplatformsindistributedenvironment.
Keywords:
XML;XMLschema;WebGIS;validator;protocol
摘要:
针对WebGIS通信中面向复杂对象及大容量传输的特点,给出了一个新的基于XML的WebGIS通信协议的设计和实现方法.使用UML工具以面向对象的方法细致分析了WebGIS典型的请求和响应协议,并据此详细说明了使用W3C的XMLSchema规范设计WebGIS的通信协议的基本方法.最后结合一个WebGIS应用原型,给出了在WebGIS系统中通过对基于XML的通信协议的打包和解析,完成嵌入的主要流程.该通信协议能够适用于分布式异构平台下多种WebGIS系统架构的空间信息交换.
关键词:
XML;XMLschema;WebGIS;验证器;协议
中图法分类号:
TP393 文献标识码:
A
WebGIS是一个将地理信息及其处理分布于Web计算平台的网络化GIS系统.目前国际上对于WebGIS软件技术的研究基本上集中在空间数据模型、空间数据结构、网络环境下的空间信息组织管理、通信协议、分布式策略等方面,本文所涉及到的方面是WebGIS的通信协议问题[1].WebGIS的通信协议主要分为控制命令协议和空间数据传输协议.以往的WebGIS通信协议大都通过参数帧描述控制命令,这需要仔细定义协议格式并实现相应的协议解析,因而不具有通用性.比如,一个数据请求协议的参数帧可能定义如下:
请求用户
请求时间
是否要整个图层
图层名
是否要索引
索引id
其他域段…
而实际上,请求交通线图层的协议可能仅仅填充如下(但这样也造成了很大的浪费):
“lxp”
2002/6/10
True
“交通线”
False
Null
其他域段均为空
XML能够方便地描述具有包含关系的概念模型,而且它对概念模型的表达直观易懂,形式灵活,不受类似参数帧的模式限制.使用XML描述协议,不仅可以定义统一的数据和控制命令格式,而且可以方便地使用已有的XML解析器,从而极大地方便了协议的扩展和系统对协议的集成.目前已经有了使用XML作为通信协议的先例.ArcInfo在它的基于服务器网站的可发布数据平台ArcIMS中,已经使用了ArcXML作为基本的命令和数据传输协议在用户网页和后台的空间数据服务器之间进行通信[2].更值得一提的是,W3C在2000年5月推出了SimpleObjectAccessProtocol(SOAP)1.1[3],它是基于XML表达的轻量级协议,用于在非集中式环境下建立一个信息交换的框架.我们基于XML的WebGIS通信协议的思想来源于SOAP模型,但是我们主要侧重于对WebGIS系统的应用.
1WebGIS通信协议分析
为了更好地分析WebGIS通信协议,我们选取JAVA语言开发了具有简单应用的WebGIS原型系统.该系统由3部分组成:
Applet、WebGIS服务器和数据服务器,如图1所示.
数据服务器为GIS服务器提供了访问空间数据库的接口.WebGIS服务器负责监听来自客户端的请求,并与合法用户建立连接.GIS服务器有专门的数据库访问模块负责完成与数据服务器的交互,获得用户请求的数据信息.WebGIS服务器还集成了有关GIS数据分析处理的各种模块,这包括拓扑分析、最短路径分析、叠加分析、数据转换等基本模块.这样,比较复杂的GIS数据处理将在WebGIS服务器端完成,而在Applet中保留基本的地图功能,从而当Applet在客户端下载运行时能够保证WebGIS客户端的小巧灵活,即实现“瘦客户端”.通过将Applet嵌入到网页中去,并与网页一起提供各种交互界面,WebGIS用户能够完成各种空间操作功能.
Applet在整个WebGIS交互中起到了关键的作用.在Applet内部封装基本的GIS功能,形成一系列具有特定用途的工具性Applet.例如,用于地图显示的Applet、用于拓扑分析的Applet和用于属性查询的Applet等.通过重新定义这些Applet界面中的鼠标事件,并留出公有的外部接口,用户可以使用JavaScript等语言对这些Applet进行类似构件的二次开发.
在Applet运行过程中,用户请求和Web服务器的数据响应形成基本的交互事务.这些交互都将通过WebGIS的通信协议来进行表达.为了完成Applet界面提供的基本GIS交互功能,C/S两端必须对请求和响应的细节分层,定义良好的协议规范,以求高效、准确地完成交互,这是因为:
为了更大限度地利用网络带宽,提高系统交互的并行性,必须认真分析目前WebGIS基础的事务交互中的协议内容,给出协议内容中涉及各类几何数据及其控制的相关性的严格表达,以定义高效的请求和响应模式.
WebGIS的通信协议具有鲜明的层次划分,采用以往的协议格式会定义出复杂的协议集合,从而形成最后协议编排中过多的控制字段和数据字段,导致协议开发的复杂化和最终通信效率的下降.因此,定义新的协议规范是一个需要迫切解决的问题.
WebGIS的通信协议必须是易于更新和修改的.新的协议规范应该考虑协议的动态扩充能力.
通过对WebGIS系统的基本交互的分析发现,WebGIS通信协议的基本内容具有典型的树形结构,能够非常方便地使用类结构建模,并利用形式化的UML图规范协议细节.类继承和类包含为协议的扩展提供了非常良好的结构支持,这就使得我们定义全新的协议规范成为可能.
用户与WebGIS系统的Web服务器端的交互决定了WebGIS系统通信协议的主要内容.下面两节给出了客户端请求和服务器响应的通信协议的详细说明,并使用UML图给出了形式化的描述.
1.1WebGIS请求协议的UML说明
在原型系统中,Applet内部包含了地图编辑和实体查询等处理模块.这样,WebGIS通信协议主要负责地图数据的请求和响应.地图是分层的,基本的请求为图层获取.获取一个图层的请求途径是多样的,主要包括:
通过提供图层名来请求图层,这是最基本的请求方式;
通过重定向图层数据的位置来请求
图层;
通过提供几何数据的空间索引子树来请求相应的几何对象索引信息;
通过提供空间范围来请求图层中指定范围内的几何实体.
根据上面对图层请求的主要内容的分析,图2给出了WebGIS系统关于地图数据请求协议的UML描述.
请求开始于类Requests,它是一系列请求Request的容器.每一个具体的Request都要使用一个id标记,并用time记录请求的时间.从Request派生出的LayerRequest,表明目前的协议只包括图层请求.每一个基本的图层请求必须包括必须的图层名name.根据上面对图层请求的细化,从LayerRequest派生出GetLayer,GetRedirection,GetSpatialIndex和GetEntities这4种请求方式.
GetLayer这种方式将得到由图层名标志的整个图层的相关信息.
GetRedirection需要使用成员类Redirection提供重定向的数据位置redirection.
GetSpatialIndex需要提供空间索引子树,它用于表达用户请求的部分几何实体的索引描述.索引子树由基本的SiNode树节点构成,它可以直接是一个SiLeaf类型的叶节点,用recursive标明递归的层数,也可以是一棵真正意义上的子树,树中的每个非叶节点用entry标明入口.
GetEntities需要用Condition成员类描述用户请求的实体的条件限制.条件用Expression表达,它或者是True,标明没有条件约束,或者用Inside下的Box指明请求的范围.
1.2WebGIS响应协议的UML说明
针对上面的请求协议规范,在服务器端的响应也有相应的设计,主要包括:
对仅基于图层名的图层请求响应,它响应给客户端所请求图层的主要属性信息;
对空间索引树的请求响应,它响应给客户端相应的空间索引子树,每个节点已经携带了对应的索引信息;
对几何实体的请求响应,它将以集合的形式返回所有满足用户请求条件的实体信息以及重定向获取实体域段的地址信息;
对重定向的请求响应,它将简单地回传重定向地址,真正的重定向数据获取将由服务器相应的处理模块完成;
对几何实体域段的请求响应,它将响应重定向获取域段数据的地址信息.
同样,这些响应协议的分类可以对应到如图3所示的UML图.
Fig.3UMLdiagramofrespondingprotocols
图3响应协议的UML描述
类似于请求协议,一组Reply可以被作为Replies的成员类,形成从服务器传来的多个响应.一个Reply必须用一个id进行标志,同时指明响应的对象replyto,并用hasmore提示是否还有更多的响应或是结束.从Reply继承得到5类具体的响应:
ReplyGetLayer,ReplyGetSpatialIndex,ReplyGetEntities,ReplyRedirection和ReplyField.
ReplyGetLayer是对请求协议中GetLayer的响应,它包含了服务器处理得到的用户请求图层的基本信息:
名称(name)、范围(extent)、缺省色(defaultColor)以及比例尺(mapScale).
ReplyGetSpatialIndex是对请求协议中GetSpatialIndex的响应,它包含了以SiNodeData作为树节点(叶节点或者非叶节点)的空间索引子树.每个节点列出了它的入口entry以及该节点以下子树的范围(extent).
ReplyGetEntities是对请求协议中GetEntities的响应,它包含记录了一列满足用户请求条件的Entity的Entities成员类.每个满足条件的Entity由id标志,并注明该Entity的范围(extent).Entity的数据信息被细化为用Fields描述.Fields记录了一列归属于该Entity的Field重定向信息.Field被具体化为BianaryField,BlobField,ClobField,GeometryField,ObjectField,StringField,NumberField和DateField共8类.
ReplyRedirection是对请求协议中GetRedirection的响应,它包含一个Redirection,后者使用redirection字符串指明重定向的地点.
另外,也可以采用ReplyField直接响应某个属性域段.
需要说明的是,我们着重对基于Applet的WebGIS模型进行了通信协议的分析,这主要是为了反映在与平台无关的Java语言为开发背景下使用通信协议的平台无关性.由于基于XML的WebGIS通信协议自身被编排为文本格式,而不同于以往的二进制数据流,在特定的比较成熟的平台技术下,例如微软的ActiveX控件、基于C代码的CGI过滤服务器模式以及Plugin模式等等,基于XML的文本解析和处理也得到很强的支持,因而该协议仍然有很广泛的应用空间.
1.3基于XML的WebGIS通信协议和GML
OGC在2000年5月12日发布了基于XML的空间信息表达规范GML(geographymarkuplanguage)1.0,并很快成为业界所接受的空间信息交换格式.在许多大型的、需要集成分布式异构GIS平台并且构造平台之上的应用集成框架的商业应用中,GML已经被首先采纳,作为标准的空间数据的通信格式.基于XML的WebGIS通信协议与GML有着紧密的联系,但是仍然存在区别:
GML语言(目前比较完善的版本是GML2.0)主要面向为用于描述客观世界的几何实体定义平台无关的、标准的几何实体类框架,并提供标准的标签格式(这一点通过GML1.0的DTD和GML2.0的Schema来提供),它不包括对几何实体的面向应用的控制信息,而基于XML的WebGIS通信协议则能够描述特定的服务请求和响应;
GML是数据定义语言,它本身不包括协议的控制信息,即它本身不能作为独立的协议,而基于XML的WebGIS通信协议则使用了GML作为其描述空间数据的部分.例如,图2中的Box可以使用GML中的Box标签来进行描述.可以说,基于XML的WebGIS通信协议是针对实际的GIS应用对GML的扩展.
从以上两点可以看出,基于XML的WebGIS通信协议具有良好的适应性,它既集成了面向应用的数据控制信息,也集成了标准的GML数据描述信息,做到了GIS平台无关,可以被方便地嵌入多种分布式GIS应用中.
2基于XML的WebGIS通信协议的实现
通过定义协议的XMLSchema文档,也就定义了基于XML表达的协议的元数据.使用元数据规范化协议,能够从数据的模式抽象层次定义基本的协议表达.对协议的元数据的修改,能够完成一类协议的重定义,这有利于协议集的更新和扩展.
2.1WebGIS系统通信协议的XMLSchema实现——定义协议的元数据
从UML类图结构可以很方便地转换到XMLSchema,转换一般要基于以下的规则[4~6](限于篇幅,这里并不列出具体的请求协议和响应协议的XMLSchema):
UML中的一个类对应于XMLSchema中的一个复杂类型.UML图中的类分为抽象类和非抽象类两种.抽象类一般能够概括出由它继承得到的所有派生类的公有属性和方法,其本身不能够被实例化.在XMLSchema中,可以使用属性abstract标志抽象类对应的复杂类型为抽象类型.
UML中的类属性对应于XMLSchema中各种复杂类型的属性.
UML中的类继承对应于XMLSchema中的类型扩展标签中的base属性值.该值指明了继承链中的基
类型.
UML中的成员类通过定义XMLSchema中复杂类型的嵌套子元素得以表达.
2.2协议验证器
2.2.1验证器在系统协议传输中的应用
使用XMLSchema描述WebGIS系统的通信协议模式的主要目的在于利用XMLSchema对XML数据文件的元数据说明能力,使用通用的基于XMLSchema的XML文档验证器自动完成基于XML的通信协议有效性检查.验证器在系统的协议传输过程中可以被认为是在C/S两端的一个流程开关.为了提高系统的效率,我们基于这样的假设:
服务器的响应协议一般被认为已经严格遵循了上面XMLSchema的定义,在客户端接收到响应时,可以关闭验证开关,直接对XML表达的协议进行解析;
熟悉、友好的客户端会被服务器识记.从这样的客户端提交的请求协议一般也认为是严格遵守了XMLSchema的定义,从而在服务器处理请求时,关闭验证开关,直接对请求协议进行解析;
新的客户端必须经过一个阶段获取服务器的足够信任.在这个阶段内,凡是由客户端提交的请求协议必须经过验证器的有效性检查,避免因为协议本身的错误造成协议解析的不必要的资源消耗.
2.2.2协议验证器的基本验证流程
基于XML的WebGIS通信协议的XMLSchema所包含的类型和元素定义遵循通用的XML文档描述规则,但是由于其自身受应用需求限制,并没有完全涉及所有的XMLSchema定义特征,所以采用通用的XML验证器会对本身就很复杂的协议验证增加由于不必要的为实现通用验证能力带来的额外负荷.实现面向协议本身的协议验证器是提供系统交互性能的重要保证之一.
协议基本验证流程可以用图4来描述.系统采用W3C开发的DOM(documentobjectmodel)来解析协议的XMLSchema和协议本身.通过XMLSchema验证协议的有效性,尽管可以确保以后协议解析的正确性,但是这一过程本身是复杂而耗时的,所以,只要当确实有必要进行协议验证时才完成这一流程.
Fig.4WorkflowofXMLschema-basedvalidatorforprotocols
图4与协议相关的基于XMLSchema的验证器工作流程
2.2.3协议所涉及的XMLSchema的基本验证项
实现元素类型的嵌套结构检查的主要办法是:
从协议的DOM树和定义协议的XMLSchema的类型树的根节点出发,采用深度优先的树周游算法,用类型树的节点信息逐一验证协议的DOM树节点.元素类型的嵌套结构检查是以下验证项的框架.伴随着树周游,每个节点都将对以下的验证项作依次检查.
元素名称检查
出现在DOM树的每个元素的标签名称必须在XMLSchema类型树的相应类型中有定义,而且因为XML是大小写相关的,所以在进行验证时,DOM树被周游到的当前元素必须和类型树中相应元素定义做区分大小写的字符串匹配.
属性继承和use属性检查
类型树的构造方便了在属性继承时的检查.验证器所要做的是将DOM树的元素结点中的属性列表和类型树中对应的元素定义的属性列表进行匹配.在匹配时主要是验证那些必需属性是否在协议的表达中出现,属性名是否匹配,属性类型是否对应.必需属性在XMLSchema中用属性的use值加以说明,这一点也被记录在类型树节点信息中.
元素出现次数(minOccurs,maxOccurs)检查
验证器为协议的DOM树中的每个元素建立一个计数器,随着树周游的进行,计数器记下每个元素在协议的实际表达时出现的次数,最终和类型树中相应元素定义的阈限制进行比较,如果出现不符,即说明协议无效.
复杂元素的内容组合(sequence,choice,all)检查
XMLSchema允许的内容组合主要有sequence,choice和all这3种.在XMLSchema的类型树中,sequence,choice和all都将作为独立的树节点出现.验证器将为这3种节点的子节点生成一个元素链,并考虑协议中相应元素出现的顺序和次数来完成验证.
2.3协议的XML打包及类解析的实现
通过定义协议的XMLSchema给出了协议的元数据描述.通过实现与协议相关的简单验证器保证了通过http传输的协议的正确性.然而要真正实现WebGIS系统对基于XML的协议的集成,必须在C/S两端将具体的请求或响应协议从对象集合打包为XML数据流,并且相应地能够将XML数据流解析为协议的对象集合.
2.3.1一个简单的请求回话
图5给出了一个具体体现协议打包和解析的通信会话流程.客户端在执行用户显示“北京市交通线”图层的请求时,首先需要用请求协议的UML对象类建立内存中的协议对象树.对象树经过XML打包,而成为根据请求协议的XMLSchema规范书写的XML字符流.字符流通过C/S之间的Internet连接到达服务器,被接收下来而重新形成请求协议的对象树.服务器识别出这是GetLayer请求,将它分派给GetLayer处理模块,后者通过GetLayer对象的属性从数据库中查询得到“北京市交通线”图层数据.
WebServer
TransferstreamofXML-basedprotocolsusinghttp
Webbrowser
Webserver
Parse
XML-basedprotocols
Receiveprotocols
PackXML-basedprotocols
Launchrequests
Dispatchrequests
Sendprotocols
Fig.5PackingandparsingofXML-basedprotocolsforWebGIS
图5基于XML的WebGIS系统协议打包和解析
2.3.2协议的XML打包
协议的XML打包是同时存在于C/S两端的协议处理模块.
在客户端,用户在Applet上触发的请求事件被客户端所捕获,接着被装入请求的对象树中.请求的对象树是我们根据请求协议的UML图设计的JAVA类的实例集合.它作为用户请求和XML协议生成的中间界面,是方便WebGIS系统XML协议集成的重要组成部分.在服务器端,服务器同样需要将从各个处理模块得到的数据和响应信息装入响应协议的对象树中,再打包成XML协议流传给客户端.
协议的XML打包过程本身是简单的,这和我们从协议的UML图生成协议的XMLSche
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 XML We bGIS 通信协议 设计