中篇：第一章-Web-地理信息服务

第一章Web地理信息效劳尹章才 网络效劳是Web2.0的重要技术根底和实现方式，网格、云计算等都是基于网络效劳的。其中，XML是网络效劳的根底语言。1.1Web效劳本节来源于：Web效劳，维基百科，://1.1.1核心定义一、Web效劳Web效劳〔WebService〕是一种面向效劳的架构的技术，通过标准的Web协议提供效劳，目的是保证不同平台的应用效劳可以互操作。根据W3C的定义，Web效劳应当是一个软件系统，用以支持网络间不同机器的互动操作。网络效劳通常是许多应用程序接口〔API〕所组成的，它们通过网络，例如国际互联网〔Internet〕的远程效劳器端，执行客户所提交效劳的请求。尽管W3C的定义涵盖诸多相异且无法介分的系统，不过通常我们指有关于主从式架构〔C/S〕之间根据SOAP协议进行传递XML格式消息〔图〕。无论定义还是实现，Web效劳过程中会由效劳器提供一个机器可读的描述〔通常基于WSDL〕以辨识效劳器所提供的Web效劳。另外，虽然WSDL不是SOAP效劳端点的必要条件，但目前基于Java的主流Web效劳开发框架往往需要WSDL实现客户端的源代码生成。一些工业标准化组织，比方WS-I，就在Web效劳定义中强制包含SOAP和WSDL。WebService体系结构基于效劳提供者、效劳注册中心和效劳请求者之间的交互。效劳提供者在效劳注册中心发布Web效劳描述语言WSDL；效劳请求者使用注册中心的UDDI注册效劳来搜索其所需Web效劳，并通过SOAP将该Web效劳和本部门的当前应用绑定，实现空间数据与操作的共享。二、关键技术Web效劳建立在XML、WSDL、SOAP和UDDI等协议和标准之上，具有完好的封装性、松耦合、使用协约的标准性、使用标准协议标准、高度可集成能力等特点。其中〔维基百科，://〕，1〕SOAP简单对象访问协议〔SOAP，全写为SimpleObjectAccessProtocol〕是一种标准化的通讯标准，主要用于Web效劳中。SOAP的出现是为了简化网页效劳器〔WebServer〕在从XML数据库中提取数据时，无需花时间去格式化页面，并能够让不同应用程序之间透过HTTP通讯协定，以XML格式互相交换彼此的数据，使其与编程语言、平台和硬件无关。此标准由IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出，并得到IBM，莲花〔Lotus〕，康柏〔Compaq〕等公司的支持，于2000年提交给万维网联盟〔WorldWideWebConsortium；W3C〕，目前SOAP1.1版是业界共同的标准，属于第二代的XML协定〔第一代具主要代表性的技术为XML-RPC以及WDDX〕。用一个简单的例子来说明SOAP使用过程，一个SOAP消息可以发送到一个具有WebService功能的Web站点。例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个XML格式的信息，其中包含了查询结果〔价格，位置，特点，或者其他信息〕。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。2〕WSDL一个XML格式文档，用以描述效劳端口访问方式和使用协议的细节。通常用来辅助生成效劳器和客户端代码及配置信息。WSDL〔Web效劳描述语言，WebServicesDescriptionLanguage〕是为描述Web效劳发布的XML格式。WSDL2.0版将被作为推荐标准〔recommendation〕〔一种官方标准〕，并将被W3C组织批准为正式标准。WSDL描述Web效劳的公共接口。这是一个基于XML的关于如何与Web效劳通讯和使用的效劳描述；也就是描述与目录中列出的Web效劳进行交互时需要绑定的协议和信息格式。通常采用抽象语言描述该效劳支持的操作和信息，使用的时候再将实际的网络协议和信息格式绑定给该效劳。3〕UDDI一个用来发布和搜索WEB效劳的协议，应用程序可借由此协议在设计或运行时找到目标WEB效劳。UDDI是统一描述、发现和集成〔UniversalDescription,Discovery,andIntegration〕的缩写。它是一个基于XML的跨平台的描述标准，可以使世界范围内的企业在互联网上发布自己所提供的效劳。UDDI是OASIS发起的一个开放工程，它使企业在互联网上可以互相发现并且定义业务之间的交互。UDDI业务注册包括三个元件：白页：有关企业的根本信息，如地址、联系方式以及的标识；黄页：基于标准分类的目录；绿页：与效劳相关联的绑定信息，及指向这些效劳所实现的技术标准的引用。这些标准由这些组织制订：W3C负责XML、SOAP及WSDL；OASIS负责UDDI。三、根本特征〔龙岳红2008〕就技术角度而言，Web效劳是对象/组件技术在Inetmet上的延伸，它具备以下特征：1〕完好的封装性Web效劳具备良好的封装性，对于效劳使用者而言，他能且仅能看到该Web效劳所提供的接口。2〕松散藕合当一个Web效劳的实现发生变更的时候，只要其调用界面不变，对效劳的调用者不会有任何影响。也就是说，只要Web效劳的调用接口不变，Web效劳的实现的任何变更对效劳调用者来说都是透明的，甚至是当Web效劳的实现平台从J2EE迁移到了.NET或者是相反的迁移流程，效劳的用户都可以对此一无所知。3〕使用标准协议标准Web效劳使用开放的标准协议进行描述、传输和交换。这些协议具有完全免费的标准，以便由任意方进行实现。4〕高度可集成能力Web效劳是可组合的，可以用简单的效劳构建更复杂的效劳。由于Web效劳采取简单的、易理解的标准协议作为效劳接口描述和协同描述标准，完全屏蔽了不同软件平台的差异，从而可以在不同平台间进行互操作，实现了在当前环境下最高的可集成性。5〕Web效劳是比组件更高层的架构(抽象)Web效劳并不是面向对象方法和基于组件方法建立企业应用的替代品，而是一种比组件技术更高层的抽象。组件技术通常是多个组件一起共同提供企业所需的某项功能，而Web效劳通常针对企业范围内一个处理流程提供整体的业务解决方案。Web效劳由组件构成，一个(或几个)组件会暴露在效劳接口中。1.1.2使用方式一、远程过程调用1概念远程过程调用〔RemoteProcedureCall，RPC〕是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作远程调用或远程方法调用。2信息传递远程过程调用是一个分布式计算的C/S的例子，它简单而又广受欢送。远程过程调用总是由客户端对效劳器发出一个执行假设干过程请求，并用客户端提供的参数，执行结果将返回给客户端。由于存在各式各样的变体和细节差异，对应地派生了各式远程过程调用协议，而且它们并不互相兼容。为了允许不同的客户端均能访问效劳器，许多标准化的RPC系统应运而生了，其中大局部采用接口描述语言〔InterfaceDescriptionLanguage，IDL〕，方便跨平台的远程过程调用。3在Web效劳中的应用Web效劳提供一个分布式函数或方法接口供用户调用，这是一种比较传统的方式。通常，在WSDL中对RPC接口进行定义〔类似于早期的XML-RPC〕。尽管最初的Web效劳广泛采用RPC方式部署，但针对其过于紧密之耦合性的批评声也随之不断。这是因为RPC式Web效劳实质上是利用一个简单的映射，以把用户请求直接转化成为一个特定语言编写的函数或方法。如今，多数效劳提供商认定此种方式在未来将难有作为，在他们的推动下，WS-I根本协议集〔WS-IBasicProfile，WS是WebService的简称〕已不再支持远程过程调用。二、面向效劳架构1概念〔〕面向效劳的体系结构(Service-OrientedArchitec-ture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为效劳)通过定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现效劳的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的效劳可以以一种统一和通用的方式进行交互。这种具有中立的接口定义〔没有强制绑定到特定的实现上〕的特征称为效劳之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性；另一点是，当组成整个应用程序的每个效劳的内部结构和实现逐渐地发生改变时，它能够继续存在。而与此相对，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对局部或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。虽然面向效劳的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于SOA的系统并不排除使用面向对象的设计来构建单个效劳，但是其整体设计却是面向效劳的。由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA系统原型的一个典型例子是通用对象请求代理体系结构(CommonObjectRequestBrokerArchitecture，CORBA)，它已经出现很长时间了，其定义的概念与SOA相似。然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以XML为根底的。通过使用WSDL来描述接口，效劳已经转到更动态且更灵活的接口系统中，非IDL可比了。总之，SOA是一种“如何将软件组织在一起”的抽象概念，依赖于用XML和Web效劳实现并以软件的形式存在的更加具体的观念和技术。2特征〔〕1〕可重用，一个效劳创立后能用于多个应用和业务流程。2〕松耦合，效劳请求者到效劳提供者的绑定与效劳之间应该是松耦合的。因此，效劳请求者不需要知道效劳提供者实现的技术细节，例如程序语言、底层平台等等。3〕明确定义的接口，效劳交互必须是明确定义的。效劳请求者不知道也不关心效劳究竟是由哪种程序设计语言编写的。4〕无状态的效劳设计，效劳不应该依赖于其他效劳的上下文和状态。5〕基于开放标准，当前SOA的实现形式是Web效劳，基于的是公开的W3C及其他公认标准．采用第一代Web效劳定义的SOAP、WSDL和UDDI以及第二代Web效劳定义的WS-*来实现SOA。3在Web效劳中的应用现在，业界比较关注的是遵从SOA概念来构筑Web效劳。在SOA中，通讯由消息驱动，而不再是某个动作〔方法调用〕，这种Web效劳也被称作面向消息的效劳。SOA式Web效劳得到了大局部主要软件供给商以及业界专家的支持和肯定。作为与RPC方式的最大差异，SOA方式更加关注如何连接效劳而不是特定某个实现的细节。WSDL定义了联络效劳的必要内容。值得一提的是，SOA不是Web效劳。Web效劳是技术标准，而SOA是设计原那么。特别是Web效劳中的WSDL，是一个SOA配套的接口定义标准：这是Web效劳和SOA的根本联系。从本质上来说，SOA是一种架构模式，而Web效劳是利用一组标准实现的效劳。Web效劳是实现SOA的方式之一。用Web效劳来实现SOA的好处是你可以实现一个中立平台，来获得效劳，而且随着越来越多的软件商支持越来越多的Web效劳标准，你会取得更好的通用性〔〕。三、表述性状态转移1REST设计概念和准那么〔〕：1〕网络上的所有事物都被抽象为资源〔resource〕；2〕每个资源对应一个唯一的资源标识〔resourceidentifier〕；3〕通过通用的连接器接口〔genericconnectorinterface〕对资源进行操作；4〕对资源的各种操作不会改变资源标识；5〕所有的操作都是无状态的〔stateless〕。2在Web效劳中的应用表述性状态转移式〔Representationalstatetransfer，REST〕Web效劳类似于HTTP或其他类似协议，它们把接口限定在一组广为人知的标准动作中〔比方HTTP的GET、PUT、DELETE〕以供调用。此类Web效劳关注与那些稳定的资源的互动，而不是消息或动作。此种效劳可以通过WSDL来描述SOAP消息内容，通过HTTP限定动作接口；或者完全在SOAP中对动作进行抽象。1.2根底Web地理信息效劳开放地理信息系统协会(OpenGISConsortiumOGC)致力于为地理信息系统间的数据和效劳互操作提供统一，它是一个非盈利的志愿的国际标准化组织，引领着空间地理信息标准及效劳的开展。目前在空间数据互操作领域，基于CGI模式的互操作方法是一种根本的操作方法。通过国际标准化组织〔ISO/TC211〕或技术联盟〔如OGC〕制定空间数据互操作的接口标准，GIS软件商开发遵循这一接口标准的空间数据的读写函数，可以实现异构空间数据库的互操作。目前，基于HTTP、XML的空间数据互操作主要涉及WebService的相关技术，是未来互操作的开展趋势。OGC和ISO/TC211共同推出了基于Web效劳〔XML〕的空间数据互操作实现标准WMS，WFS，WCS〔OGC,://〕。以上三个标准既可以做为Web效劳的空间数据效劳标准，又可以做为空间数据的互操作实现接口。只要某一个GIS软件支持这个接口，部署在本地效劳器上，其他GIS软件就可以通过这个接口得到所需要的数据。从技术实现的角度，可以将Web效劳理解为一个应用程序〔可以用现有的各种编程语言实现〕，它向外界暴露出一个能通过Web进行调用的接口，允许被任何平台、任何系统，用任何语言编写的程序调用。这意味着，Web效劳可以实现跨平台、跨语言、跨硬件的互操作。1.2.1网络地图效劳作为OGC基于Web地图效劳的互操作标准，WMS凭借其简单明了的请求方式和丰富的响应信息，为在互联网上实现多源异构地理空间数据的集成、共享、互操作和应用提供了一条简捷高效的途径。WMS能动态整合与可视化在线的数据源，而不受格式、数据模型、坐标系以及软件商家的限制(Marta2002)。WMS定义了用来在Internet上得到地图图像的效劳接口，其所生成的地图是以诸如PNG、GIF、JPEG、SVG或WebCGM(WebComputerGraphicsMetafile)的格式存在，为不同来源地理信息的融合与效劳的共享提供了根底。WMS定义了三个操作〔图〕：“GetCapabilities()”返回效劳层的元数据；“GetMap()”返回一定地理范围和维度的地图，用户提供所需地图的边界范围、图像大小、格式、错误处理等信息；“GetFeatureInfo()”是可选的第三种操作，它返回地图中指定要素的属性信息，用户提供所作用的图层和点位置的坐标对〔x,y〕。标准的网络浏览器通过发送URLs〔UniformResourceLocators〕请求来激活这些操作，不同操作对应的URLs内容不同。一般情况下请求地图的URL包括：地图显示那些信息、地图反映地球的那局部、所使用的坐标参考系、输出的图像高度和宽度等。具有相同地理参数和输出大小的两个或多个地图，通过叠加能产生复合地图。同样，单个地图可以来自于不同的效劳器，从而实现网络分布式地图效劳。WMS通过图层组织地理信息，并提供有限的用于显示图层的预定义样式。WMS所呈现的地图可以被定义为一系列的样式化图层〔StyledLayers〕。每个图层可以认为是符号化的要素。一幅地图是由大量的这些图层按照一定的次序构成的。用户通过增加或减少图层，能定义复杂或简单的地图。每个样式化的图层本身表示了“图层”和“样式”的特定融合。理论上讲，图层定义了一系列的要素和定义如何符号化这些要素的样式。WMS仅仅支持指定的图层和样式，并不包括地理要素的自定义符号化机制。1.2.2网络要素效劳Web要素效劳〔WFS,WebFeatureServer〕标准描述了使用HTTP协议通过网络访问要素效劳的标准，是数据访问效劳接口之一。WMS允许客户端重叠显示来自Internet的多个WMS的地图图像。类似地，Web要素效劳允许客户端从多个WFS中使用GML编码的地理空间数据。实现WFS的必要条件：接口必须用XML定义；GML必须被用来在接口中表达要素；一个最小化的WFS必须可以使用GML表达要素；谓语或过滤语言将使用XML定义；用来存储要素的数据库对客户端应用应该是不透明的，它们对数据的唯一查看方法应通过WFS接口；使用XPath表达式子集引用特性。WFS是地理要素数据库提供要素效劳的接口〔图〕。WFS操作支持在使用HTTP协议的分布式计算平台上对要素进行插入、更新、删除、查询和发现操作。为了支持事务和查询操作，以下操作必须定义： GetCapabilities，一个WFS必须可以描述它的能力，特别地，必须指出它可以为哪些要素类型提供效劳以及每个要素类型支持哪些操作。 DescribeFeatureType，WFS必须可以在请求中描述它可以提供效劳的任何要素的结构。GetFeature，WFS必须可以为一个获取要素实例的请求提供效劳。另外，客户端可以规定获取要素的哪些特性，并且可以使用空间和非空间的查询限制条件。 Transaction，WFS可以为事务请求提供效劳。一个事务请求是由修改要素的操作组成的，即对地理要素的创立、修改和删除操作。 LockFeature，WFS可以处理在一个事务期间对一个或多个要素类型实例上锁的请求，这就保证了可序列化的事务被支持。基于对以上操作的描述，可以定义两种类型的要素效劳：根本WFS和事务WFS。其中，根本WFS可以实现GetCapabilities，DescribeFeatureType和GetFeautre操作，它被认为是只读的WFS；事务WFS可以支持所有的WFS操作。图是一个简化的协议图，描述了为了处理一个典型的事务请求，客户端和WFS间来回传递的数据。WFS请求要遵循上述协议，处理请求的过程：客户端应用请求WFS的能力文档，这个文档包含对WFS支持的所有操作的描述和它可以提供效劳的要素类型列表；客户端应用〔可选的〕向WFS发出请求，请求得到WFS可以效劳的一个或多个要素类型的定义；以要素类型的定义为根底，客户端应用向WFS发出事务请求，WFS被调用以读取请求并为之提供效劳。聚合网络要素效劳〔AggregationWebFeatureServicesAWFS〕能够聚合符合OGC的WFS标准的WFS效劳。聚合多个WFS效劳，将它们逻辑关联在一起，可以更加有效的获取到WFS效劳的数据〔聚合网络要素效劳，:///〕。1.2.3网络覆盖效劳网络覆盖效劳〔WCSWebCoverageService〕是空间数据互操作的一个重要组成局部。WCS面向空间影像数据，将包含地理位置值的地理空间数据作为“覆盖”在网上进行交换。OGC的WCS执行标准中定义了三种必须的操作〔WCS,://=41〕：GetCapabilities操作返回描述效劳和数据集的