空间信息服务框架

2.2.2　空间信息服务框架

为了解决空间信息共享与互操作等问题，OGC组织制定了OpenGIS服务体系结构标准(OpenGIS Service Architecture Specification)，后来该标准又被ISO/TC211引用，成为地理信息服务规范ISO19119。

OGC组织是一个非盈利性的组织，目的是促进采用新的技术和商业方式来提高地理信息处理的互操作性，OGC会员主要包括GIS相关的厂商，以及一些高等院校和政府部门等，其技术委员会负责具体的标准制定工作。OGC标准是基于开放的分布式处理参考模型(Reference Model of Open Distributed Process，RM-ODP)。该模型是从信息领域衍生过来的，提出了五个观点:企业观点、计算观点、信息观点、工程观点、技术观点(Percivall，2002)。

2.2.2.1　企业观点

企业观点(Enterprise Viewpoint)是基于开放分布式处理信息系统的观点，它的重点在以企业的层面看待这个系统，强调的是系统的应用范围、目的等。因此，基于企业观点来认识服务旨在建立服务在业务逻辑中的角色，以及服务所关联的用户角色和业务策略。相对而言，OpenGIS服务体系结构标准更侧重于计算观点、信息观点、工程观点、技术观点的描述。

2.2.2.2　计算观点

计算观点(Computational Viewpoint)是在不考虑系统实现及其语义内容的前提下，描述分布式系统的组件部分，以及这些组件和接口之间的交互模式。从计算的观点来讲，要实现互操作则需要系统具备可互操作的接口(Interface)和服务(Service)。

计算观点定义服务规范(SV_ServiceSpecification)通过一组接口(SV_Interface)来定义和描述其功能，接口由一组操作(SV_Operation)组成，操作则描述了接口所承担的某个动作和功能。服务(SV_Service)通过实现接口(SV_Interface)的端口(SV_Port)来访问(图2.1)。

图2.1　服务的定义(Percivall，2002)

在网络环境下有很多单个的服务，各个服务实现不同类型的功能，要实现复杂功能的服务就需要通过服务链将不同功能的服务组合起来。在OGC规范里定义了用户定义链、流程管理服务链和集成服务链等三种服务链:

(1)用户定义链又称透明服务链。用户自己很清楚有哪种功能的原子服务，然后可以通过用户理解的方式将各原子服务组合在一起，完成复杂的空间信息处理服务流程。所有的原子服务功能，以及服务的组合方式是并行还是串行等，对于用户都是透明的。用户控制服务链的整个过程。

(2)流程管理服务链又称半透明服务链。在这种情况下，由用户调用工作流管理服务，由该服务控制服务链，用户了解组成服务链中的单个服务的调用情况。

(3)集成服务链又称不透明服务链。在这种情况下，用户调用一个服务，该服务负责执行服务链，用户不了解服务链中调用了哪些服务以及服务是如何组合的。

服务的元数据包括基本服务元数据部分、描述服务的操作部分以及描述数据部分。

(1)基本服务元数据部分(SV_ServiceIdentification)提供了服务的一般描述，包括服务类型、访问特性、数据约束条件等信息。

(2)描述服务的操作部分(SV_OperationMetadata)包括操作名称，适用的分布式计算平台(DCP)列表(如CORBA或网络服务环境)、操作的描述和调用地址等。

(3)描述数据部分(MD_DataIdentification)，是针对某个特定服务的，包括空间表达类型、空间分辨率、语言、字符集、空间范围等。

SV_ServiceSpecification描述的是服务类型，而SV_ServiceIdentification描述的是一个特定的服务(或称服务实例)(图2.2)。当一个服务与所操作的数据集紧密关联时，服务的元数据需要提供MD_DataIdentification部分;当服务实例与所操作的数据集松散耦合时，服务实例与数据集的关联可以通过服务类型与数据类型的关联来描述。

图2.2　服务与服务元数据结构比较(Percivall，2002)

2.2.2.3　信息观点

信息观点(Information viewpoint)主要强调信息模型(Information Model)在语法和语义上的互操作。实现语法上的互操作(Syntactic Interoperability)可以采用一个通用的地理要素模型作为信息模型，该模型采用相同的结构来表达多种类型的地理要素。实现不同地理要素类型之间语义上的互操作(Semantic Interoperability)需要建立不同的地理要素类型定义之间的匹配或映射关系。

信息处理的语义也是信息观点关心的内容。每个服务需要为它的操作定义语法接口，同时通过描述操作的含义和其顺序处理过程，例如前提条件和后续条件(pre-和post-conditions)，来明确服务的语义信息。

按照功能划分，空间信息服务可以包括6大类别:

(1)地理人机交互服务(Geographic human interaction services):该类服务进行人与系统之间的交互，主要通过信息显示、信息输入和适宜的对话框等形式来实现人机交互服务。具体的服务类别有目录服务浏览器、数据可视化浏览器、服务编辑器、符号编辑器等。

(2)地理模型/信息管理服务(Geographic model/Information management services):该类服务负责数据、元数据的物理存储和管理。例如要素访问服务、地图访问服务、覆盖访问服务、传感器观测服务、注册服务、目录服务、地名辞典服务、订单服务等。

(3)地理工作流/任务服务(Geographic workflow/Task services):实现特定的任务或行为的服务，该服务通常是一组由不同的人实施的行为或处理步骤完成。例如服务链引擎、事件通知服务等。

(4)地理处理服务(Geographic processing services):提供针对数据进行计算的功能服务。属于操作服务的一部分，主要负责提供能够满足用户请求的功能服务。处理服务可以进一步划分为四个子类:空间处理、专题处理、时间处理和元数据处理。坐标变换与转换、矢栅转换、影像纠正、数据重采样等属于空间处理服务;专题处理服务包括变化检测、影像处理和分类、地理编码等服务;时间处理服务包括基于时间的采样、转换、子集提取等;元数据处理服务包括统计分析、地理标注服务等。

(5)地理通信服务(Geographic communication Services):负责通信网络上的数据的编码和传输。格式转换、数据压缩、消息服务、传输服务等都属于此类服务。

(6)地理系统管理服务(Geographic system management services):负责管理整个分布式系统的部件、应用和网络等。

计算观点考虑的是服务链的构建方式，而构建好一个语法上正确的服务链后，需要考虑服务链语义上的正确性，即执行结果在语义上是正确的。地理信息服务链的语义考虑的因素包括:

(1)数据适宜性:输入的空间数据集是否适宜后续的处理操作?例如数据的精度和分辨率是否满足要求、数据是否与专题的要求相关等。

(2)服务对数据的影响:服务链中的服务对数据操作后产生了什么影响?例如数据的误差源自哪里、误差如何传播等。

(3)服务的执行顺序:服务链中服务的执行顺序对结果会产生什么样的影响?例如一个空间操作(如正射变换)是应该在一个专题操作(如属性值重采样)之前还是之后执行等。

对服务链语义正确性的评价既依赖于对每个服务的理解，例如对服务元数据的评估，同时也依赖于用户对服务组合的理解。

2.2.2.4　工程观点

工程观点(Engineering viewpoint)强调系统的分布机制和分布透明机制，以及提供安全和持久性等服务。分布透明机制对应用而言屏蔽了系统分布的复杂性。分布透明包括位置透明、复制透明、访问透明等。

工程观点研究分布式系统的架构。图2.3提供了一个分布式系统的逻辑四层架构。每一层既包括IT领域通用的服务类型，也包括GIS领域特定的服务类型。第一层是人机交互服务层(Human interaction services)，负责人与系统的交互;第二层是用户处理服务层(User processing services)，提供一些能满足用户需求的处理服务;第三层是共享处理服务层(Shared processing services)，提供能够满足大多数用户公共服务需求的处理服务;第四层是模型/信息管理服务层(Model/Information management services)，负责数据的物理存储和管理。工作流/任务服务(Workflow/Task services)负责把一组服务集成起来提供特定的处理服务。通信服务(Communication Services)负责建立不同层之间的联系。系统管理服务(System management services)对不同层的服务进行管理。

图2.3　一个分布式系统的四层逻辑架构(Percivall，2002)

逻辑架构可以映射为多种物理架构。逻辑模型描述了一个系统中服务及其接口的组织结构，而物理模型则反映了实现服务的组件及其接口的组织结构。图2.4显示了逻辑4层架构映射为传统的GIS客户端服务器模式中胖客户(Thick Client)和瘦客户(Thin Client)的物理架构。胖客户中在用户服务部分提供大部分的功能，而瘦客户架构的客户端(例如网络浏览器)主要包括用户对话框和数据表现功能。网络浏览器(Web Browser)与网络服务器(Web Server)通过HTTP协议和HTML/XML文档进行交互，网络服务器接收用户请求，在应用服务器上进行处理，然后将结果传回网络浏览器。

图2.4　逻辑4层架构映射为胖客户和瘦客户的物理架构(Percivall，2002)

2.2.2.5　技术观点

技术观点(Technology viewpoint)关注支撑一个分布式系统的基础设施，它描述一个分布式系统中的硬件和软件组成部分。从技术观点实现互操作的要求出发，需要提供一个支持分布式系统各组成部件互操作的基础设施。该基础设施可以通过分布式计算平台提供，允许分布式系统中的对象实现跨网络、硬件平台、操作系统和编程语言的互操作。

技术观点支持的地理互操作模式可以见图2.5。对象之间的通信是由通信服务(Communication Service)完成，比如CORBA环境下的对象请求代理(ORB)。通信服务使得分布式系统中的各个组成部件之间能够进行互操作，例如图2.5中通信服务A

图2.5　技术观点支持的地理互操作模式(Percivall，2002)

(Communication Service A)支持系统A中的组成部件，如客户端A(Client A)、地理数据服务器A(Geodata Server A)和地理服务组件A(GIS Service Component A)，进行互操作，通信服务B(Communication Service B)支持系统B中的组成部件进行互操作。要实现系统A和系统B之间的互操作，系统A中的组件要能够请求系统B中的组件提供的服务，反之亦然。

如果两个系统采用相同的分布式计算平台(DCP)，则这两个系统可以通过相同的通信服务实现一个系统的对象调用另外一个系统的对象提供的服务。如果两个系统采用不同的DCP，那么它们之间的互操作需要借助某些特殊的“桥梁”工具来实现。这些“桥梁”工具允许一种DCP中的对象与另一种DCP中的对象进行互操作。

由于存在多种类型的DCP，一个与平台无关的抽象规范(Abstract specification)往往必须由多种特定平台的实现规范(Implementation specification)来实现。服务抽象规范与服务实现规范的具体关系可以见图2.6。服务抽象规范是平台独立(Platform-neutral)的服务规范，与该抽象规范对应的实现规范可以基于多个具体平台(Platform-specific)进行定义，例如OGC的简单要素访问规范就有基于SQL、COM/OLE和CORBA平台的实现规范与之对应。由于存在多种不同的分布式计算平台(DCP)，所以一般需要有多个具体平台的实现规范与服务的抽象规范对应。为了实现不同实现规范之间的互操作，实现规范要提供与抽象规范中概念的映射关系。

图2.6　服务抽象规范与服务实现规范的关系(Percivall，2002)