Open Geospatial Consortium Inc.
Date: 2005-11-17
Reference number of this document: OGC 05-042r2

Version: 0.1.0®

Category: OpenGIS Best Practices Paper

Editor: Arliss Whiteside

OpenGIS® web services architecture description

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning
This document is not an OGC Standard. It is distributed for review and comment. It
is subject to change without notice and may not be referred to as an OGC Standard.
Recipients of this document are invited to submit, with their comments, notificationof any relevant patent rights of which they are aware and to provide supporting
documentation.

Document type:
Document subtype:
Document stage:
Document language:

OpenGIS® Best Practices Paper(none)
Approved
EnglishLicense Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish,
distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to
do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above
copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all
copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except asprovided in the following sentence, no such termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual
Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent,
copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license
without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy orcause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual
Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without
prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may
authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any
LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United
Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of thisAgreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable,
and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be
construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported inviolation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction
which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any
regulations or registration procedures required by applicable law to make this license enforceableii

Copyright © 2012 Open Geospatial Consortium

OGC 05-042r2

Contents

Pagei.

Preface .........................................................................................................................iv

ii.

Document contributor contact points ........................................................................iv

iii.

Revision history ..........................................................................................................iv

iv.

Future work .................................................................................................................iv

Foreword...................................................................................................................................v
Introduction..............................................................................................................................vi
1

Scope ............................................................................................................................1

2

Terms and definitions ..................................................................................................1

3

Abbreviated terms........................................................................................................3

4

OGC web services architecture overview ..................................................................4

5
5.1
5.2
5.3
5.4

Service tiers ..................................................................................................................6
Overview..................................................................................................................6
Information Management Services tier..................................................................7
Processing Services tier ..........................................................................................9Application Services tier.......................................................................................116

Services chaining .......................................................................................................127

Service interfaces.......................................................................................................13

8
8.1
8.2
8.3
8.4
8.5
8.6
9

Services communication............................................................................................15
Overview................................................................................................................15
HTTP GET operation requests .............................................................................15
HTTP POST operation requests...........................................................................15
HTTP operation responses....................................................................................16
MIME types use ....................................................................................................16
SOAP operation requests and responses..............................................................17
Server implementation...............................................................................................17

Annex A (informative) Service trading (publish – find –bind)..........................................18
Annex B (informative) Architecture tiers relationship to ISO 19119................................20
Annex C (informative) OWS architecture relationship to RM-ODP.................................21
Bibliography ...........................................................................................................................22ii

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

FiguresPage

Figure 1 —Service tiers in OWS architecture......................................................................................7
Figure 2 — Service trading objects ................................................................................................... 19

TablesPage

Table 1 — Some specific Information Management Services............................................................8
Table 2 — Some specific types of datasets..........................................................................................9
Table 3 — Some specific Processing Services ................................................................................. 10
Table 4 — Some specific Application Services................................................................................ 12
Table 5 — Some standardized encoding formats and languages .................................................... 14

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

iii

OGC 05-042r2

i.

PrefaceThis document describes many aspects of the OGC web services architecture, which the
OGC is currently developing. This architecture is a service-oriented architecture, with allcomponents providing one or more services to other services or to clients. Since thatarchitecture is being developed largely informally, broad descriptions of that architecture
have not been previously written. Because that architecture is not yet completed, some
aspects are not described here, and other aspects may change in the future.
Suggested additions, changes, and comments on this draft report are welcome andencouraged. Such suggestions may be submitted by email message or by making
suggested changes in an edited copy of this document.

ii.

Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Name
Arliss Whitesideiii.

Organization
BAE Systems E&IS

Revision history
Date

Release

2005-05-23 0.0.0
2005-10-17 0.0.1
2005-11-14 0.1.0

iv.

EditorPrimary clauses
Description
modifiedArliss Whiteside All
Initial draft
Arliss Whiteside All
Minor editing
Arliss Whiteside All
Minor editing as approved paper

Future work
Improvements in this document are desirable to add items to tables and add text to further
describe many subjects.

iv

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Foreword
This document is related to several previous OGC documents, partially superseding those
documents. Among those documents is the OGC Interoperability Program White Paper
titled “Introduction to OGC Web Services” [OGC 2001]. Another such document is OGC
Discussion Paper OGC 03-025 “OpenGIS Web Services Architecture”.
This document includes three informative annexes.
Attention is drawn to the possibility that some of the elements of this document may be
the subject of patent rights. The OGC shall not be held responsible for identifying any or
all such patent rights.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

v

OGC 05-042r2

Introduction
This document summarizes the most significant aspects of the Open Geospatial
Consortium (OGC) web services architecture, which the OGC is currently developing.
This architecture is a service-oriented architecture, with all components providing one ormore services to other services or to clients.

vi

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OpenGIS® Discussion Paper

OGC 05-042r2

OpenGIS® web services architecture description

1

Scope

This document summarizes the most significant aspects of the OGC (Open Geospatial
Consortium) web services (OWS) architecture, which the OGC is currently developing.
This architecture is a service-oriented architecture, with all components providing one ormore services to other services or to clients. Because that architecture is not yet
completed, some aspects are not described here, and other aspects may change in the
future.
NOTEThis document currently contains little information on access control and accounting, because
those subjects are just beginning to be explored by the OGC.

This document (currently) just describes this architecture. It does not attempt to provide
all the guidance needed by an author or editor of an OGC Web Service specification.
2

Terms and definitions

For the purposes of this document, the following terms and definitions apply.
2.1

clientsoftware component that can invoke an operation from a server
2.2

coordinate reference systemcoordinate system which is related to the real world by a datum [ISO 19111]
2.3

coveragefeature that acts as a function to return values from its range for any direct position
within its spatial or spatiotemporal domain
EXAMPLE

Examples include a raster image, polygon overlay, or digital elevation matrix.

2.4

featureabstraction of real world phenomena [ISO 19101]
2.5

functionrule that associates each element from a domain (source, or domain of the function) to aunique element in another domain (target, co-domain, or range) [ISO 19107]

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

1

OGC 05-042r2
2.6

geographic information
information concerning phenomena implicitly or explicitly associated with a location
relative to the Earth [ISO 19128]
2.7

interface
named set of operations that characterize the behaviour of an entity [ISO 19119]
2.8

opaque chaining
aggregate service
chained services appear as a single service which handles all coordination of individual
services behind the aggregate service [paraphrased from ISO 19119]
NOTE

The user has no awareness that there is a set of services behind the aggregate service.

2.9

operation
specification of a transformation or query that an object may be called to execute [ISO19119]
2.10

parameter
variable whose name and value are included in an operation request or response
2.11

requestinvocation of an operation by a client
2.12

response
result of an operation, returned from a server to a client
2.13

serverservice instancea particular instance of a service [ISO 19119 edited]
2.14

servicedistinct part of the functionality that is provided by an entity through interfaces [ISO19119]
capability which a service provider entity makes available to a service user entity at theinterface between those entities [ISO 19104 terms repository]
2.15

service chain
sequence of services where, for each adjacent pair of services, occurrence of the firstaction is necessary for the occurrence of the second action [ISO 19119]

2

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2
2.16

service metadata
metadata describing the operations and geographic information available at a server[ISO 19128]
NOTE

Most of this service metadata is specific to one server implementing a service type.

2.17

translucent chaining
workflow-managed chaining
execution of the chain is managed by a workflow service (or multiple workflow services)[paraphrased from ISO 19119]
NOTE
The user’s involvement in the steps of the chain is mostly watching the chain execute theindividual services that are visible to the user. The defined chain exists prior to the user executing thepattern.

2.18transparent chaining
user defined chaining
user defines and controls the order of execution of the individual services [paraphrased
from ISO 19119]
NOTE

3

Details of the services are not hidden from the user.

Abbreviated terms

BPEL

Business Process Execution Language

COTS

Commercial Off The Shelf

CRS

Coordinate Reference System

GML

Geography Markup Language

HTTP

Hypertext Transfer Protocol

IETF

Internet Engineering Task Force

ISO

International Organization for Standardization

KVP

Keyword Value Pair

MIME

Multipurpose Internet Mail Extensions

OGC

Open Geospatial Consortium

OWS

OGC Web Service, or Open Web Service

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

TBD

To Be Determined

TBR

To Be Reviewed

UDDI

Universal Description, Discovery and Integration Service

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

3

OGC 05-042r2

UML

Unified Modeling Language

URI

Universal Resource Identifier

URL

Uniform Resource Locator

URN

Universal Resource NameWCSWeb Coverage Service

WCTS

Web Coordinate Transformation Service

WFS

Web Feature Service

WICS

Web Image Classification Service

WMS

Web Map Service

WSDL

Web Services Description Language

WTS

Web Terrain Service

XML

Extensible Markup Language

4

OGC web services architecture overview

This Service Oriented Architecture is based on the fundamental roles of service provider
and service consumer within a distributed computing system. This pattern emphasizes
that desired computing can be realized by combining multiple services, for each of which
only the service types (e.g., interfaces and abilities) and server data holdings (e.g.
content) need be known. It focuses component definition on providing and/or consuming
a defined service. A Service Oriented Architecture also focuses on interactions between
components implementing defined services, in the form of service requests, service
responses, and service exceptions.
The significant properties of the OGC web services (OWS) architecture, which the OGC
is currently developing, include:a) Service components are organized into multiple tiers.
1) All components provide services, to clients and/or other components, and eachcomponent is usually called a service (with multiple implementations) or a server(each implementation).
2) Services (or components) are loosely arranged in four tiers, from Clients to
Application Services to Processing Services to Information Management
Services, but un-needed tiers can be bypassed.
3) Services can use other services within the same tier, and this is common in theProcessing Services tier.
4) Each tier of services has a general purpose, which is independent of geographic
data and services.
5) Each tier of services includes multiple specific types of services, many of which
are tailored to geographic data and services.

4

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

6) Servers can operate on (tightly bound) data stored in that server and/or on (looselybound) data retrieved from another server.
b) Services use is often chained.
1) Services can be chained with other services and often are chained, eithertransparently (defined and controlled by the client), translucently (predefined but
visible to the client), and opaquely (predefined and not visible to client), see
Subclause 7.3.5 of [OGC 02-006 and ISO 19119]
2) Services are defined to support defining and executing chains of services.
3) Some service interfaces support server storage of operation results until requestedby the next service in a chain.
c) Service interfaces use open standards and are relatively simple.
1) All services support open standard interfaces from their clients, often OGCspecified service interfaces.
2) OGC web service interfaces are coarse-grained, providing only a few static
operations per service.
3) Service operations are normally stateless, not requiring servers to retain interface
state between operations.
4) One server can implement multiple service interfaces whenever useful.
5) Service interfaces share common parts whenever practical.
6) Service interfaces can have multiple specified levels of functional compliance,and multiple specialized subset and/or superset profiles.
7) Standard XML-based data encoding languages are specified for use in datatransfers.
8) Geographic data and service concepts are closely based on the ISO 191XX seriesof standards.
9) Standard specifications are used for defining and referencing well-known
coordinate reference systems (CRSs).
d) Services communication uses open Internet standards.
1) Communication between components uses standard World Wide Web (WWW)
protocols, namely HTTP GET, HTTP POST, and SOAP.
2) Specific server operations are addressed using Uniform Resource Locators(URLs).
3) Multipurpose Internet Mail Extensions (MIME) types are used to identify datatransfer formats.
4) Data transferred is often encoded using the Extensible Markup Language (XML),
with the contents and format specified using XML Schemas.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

5OGC 05-042r2e) Server and client implementations are not constrained.
1) Services are implemented by software executing on general purpose computersconnected to the Internet. The architecture is hardware and software vendor
neutral.
2) The same and cooperating services can be implemented by servers that are owned
and operated by independent organizations.
3) Many services are implemented by standards-based Commercial Off The Shelf(COTS) software.
4) All services are self-describing, supporting dynamic (just-in-time) connection
binding of services supporting publish-find-bind.
5Service tiers

5.1

Overview

Except for clients, all OWS architecture components provide services, to clients and/or toother components. Each such component is usually called a service when multiple
implementations are expected, and each implementation is called a server (or service
instance). These components are thus usually called services or servers in this document.
Clients are software packages that provide access to a human user, or operate as agentson behalf of other software. Software that provides access to a human user can be thin(e.g., a web browser), thick (a large application), or “chubby” (in between).
All services (or components) are loosely organized in four tiers, as shown in Figure 1.
This organization is loose in that clients and services can bypass un-needed tiers, as
indicated by some arrows. Services can use other services within the same tier, and this iscommon especially in the Processing Services tier. Also, some services perform functionsof more than one tier, when those functions are often used together and combined
implementation is more efficient. Assignment of such combined services to tiers issomewhat arbitrary.
NOTE
Complete separation of services into tiers is not required and is rare, especially when separation
would be inefficient.

6

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Clients+uses
Application Services+uses
Processing Services
+uses
+uses

+uses
+uses

Information Managment Services+uses

Figure 1 —Service tiers in OWS architectureThis OWS architecture is designed for use where data is important and often voluminous.
Servers can operate on (tightly bound) data stored in that server and/or on (looselybound) data retrieved from another server. Most data is stored by the servers in the
Information Management Services tier, but some data (can be and often) is stored in otherservices and servers.
Each tier of services has a general purpose, as indicated by the names in Figure 1. Thattier name is independent of geographic data and services, since some tier services are notspecific to geographic data or services. Each tier of services includes multiple specifictypes of services, many of which are tailored to geographic data and services. Some ofthe services included in each tier are discussed in the following subclauses.
5.2

Information Management Services tier

The Information Management Services tier contains services designed to store andprovide access to data, with each server normally handling multiple separate datasets. In
addition, metadata describing multiple datasets can be stored and searched. Access is
usually to retrieve a client-specified subset of a stored dataset, or to retrieve selected
metadata for all datasets whose metadata meets client-specified query constraints.
The services in the Information Management tier are used by clients and by services in
the Application Services and Processing Services tiers. These services can use otherservices in the Information Management Services tier. The services included in this tierinclude (but are not limited to) the services listed in Table 1.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

7

OGC 05-042r2

Table 1 — Some specific Information Management Services
Service name a
Web Map Service(WMS) bWeb Feature Service(WFS)
Web Coverage Service(WCS)
Catalog Service for
the WEB (CSW) c
Gazetteer Service
Universal Description,
Discovery andIntegration (UDDI)
ServiceStanding orderservices

Order handlingservices

Service description
Dynamically produces spatially referenced map of client-specified groundrectangle from one or more client-selected geographic datasets, returning
pre-defined pictorial renderings of maps in an image or graphics format
Retrieves features and feature collections stored that meet client-specified
selection criteria
Retrieves client-specified subset of client-specified coverage (or image)datasetRetrieves object metadata stored that meets client-specified query criteria
Retrieves location geometries for client-specified geographic names
Allows a client to find a web-based service

Allows a user to request that data over a geographic area be disseminatedwhen it becomes available, including reformat, compress, decompress,
prioritize, and transmit information requested through standing queries or
profilesAllows clients to order products from a provider, including: selection ofgeographic processing options, obtaining quotes on orders, submission oforder, statusing of orders, billing, and accountinga Names ending in “Service” are currently specified specific services. Names ending in “services” are types ofservices that are not yet specified.
b

Can store and access both feature and image (coverage) data.

c Many specific profiles of the CSW are expected to be specified and implemented, for metadata for manydifferent types of datasets, and for also storing and accessing small whole datasets.

The services in this Information Management Services tier usually include someprocessing of the data retrieved. For example, WMS, WCS, and WFS can perform
coordinate transformation and format conversion.
One Catalog Service for the WEB (CSW) server can store metadata (and perhaps also
datasets) for one or more types of datasets, including (but are not limited to) the types
listed in Table 2.

8

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Table 2 — Some specific types of datasets
Type nameServiceFeatureCoverage (including
image)
Styled Layer Descriptor(SLD) document
Map Symbol
Web Map Context
document
OWS Map Context
document
Query template
Filter Encoding (FE)template
URN Definitions XML
document
GML Application
SchemaOWS XML Schema
General XML Schema
UML model
Web Service
Description Language(WSDL) document
Business Process
Execution Language(BPEL) document
Semantics document
Annotation document
Accounting record
5.3Type description
Definition of a service or server
Geographic features and feature collections (including composite features)
Geographic coverage or image, can be a gridded coverage or another typeof coverage, can be georectified or notSpecifies client-controlled styling for map portrayal of features and images(coverages)
Defines map display symbols
Specifies a composite, symbolized map view that can be saved, restored,
and transmitted to other viewers, using WMS only
Specifies a composite, symbolized map view that can be saved, restored,
and transmitted to other viewers, using WFS, WCS, WMS, etc.
Template for OGC Common Catalog Query Language queries
Template for queries for features or other data meeting specified constraints
Encoding in XML of definitions of URNs defined by OGC or otherorganization
Geography Markup Language (GML) application schema and/or profile for
specific application
XML Schema used by an OWS or other service
Any XML Schema
Any UML modelSpecifies web service interface

Specifies process sequences for specific purpose

Defines semantics (e.g., ontologies coming out of GSW IE)Specifies annotation of coverage (or image) (e.g., coming out of GMLJP2
IE?)
Records usage of servers and other resources, for billing and other purposes

Processing Services tier

The Processing Services tier contains services designed to process data, sometimes bothfeature and image (coverage) data. The services in the Processing Services tier are usedby clients and by services in the Application Services tier. These services can use otherservices in the Processing Services and Information Management Services tiers. The
services included in this tier include (but are not limited to) the services listed in Table 3.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

9OGC 05-042r2

Table 3 — Some specific Processing Services
Service name a
SLD Web Map Service(WMS) bWeb Terrain Service(WTS) bWeb 3D Service(W3DS)Web Coordinate
Transformation
Service (WCTS) b
Web ImageClassification Service(WICS)
Feature Portrayal
Service (FPS)
Coverage Portrayal
Service (CPS)
Geoparser Service

Geocoder Service
Geolinking Service(GLS) bGeolinked Data Access
Service (GDAS)
Geographic data
extraction services
Dimension measurement services
Route determination
services
Proximity analysis
services
Change detection
services
Data alignment services
Feature generalization
services

10Service description
Dynamically produces spatially referenced maps from geographic feature
and/or coverage data, returning client-specified pictorial renderings ofmaps in an image format (not actual feature data or coverage data)
Dynamically produces client-specified perspective views from geographic
feature and/or coverage data, returning client-specified pictorial
renderings of data in an image or graphics format
Dynamically produces client-specified perspective views from geographic
feature data, returning perspectives of feature data in a graphical format
Transforms the coordinates of feature or coverage data from one coordinate
reference system (CRS) to another, including “transformations”,“conversions”, rectification, and orthorectification
Performs classification of digital images, using client-selected supervised or
unsupervised image classification method
Dynamically produces client-specified pictorial renderings in an image orgraphics format of features and feature collections usually dynamically
retrieved from a Web Feature Server (WFS)
Dynamically produces client-specified pictorial renderings in an image orgraphics format of a coverage subset dynamically retrieved from a Web
Coverage Service (WCS)
Service to scan text documents for location-based references, such as aplace names, addresses, postal codes, etc., for passage to a geocoding
service.
Service to augment location-based text references with position coordinates
Service that links geospatial data
Service that uses linked geospatial data
Services supporting extraction of feature and terrain information fromimagesServices that compute dimensions of objects visible in an image or othergeospatial data
Determine optimal path between two specified points based on input
parameters and properties contained in a Feature Collection; may also
determine distance between points and/or time to follow path
Given a position or geographic feature, finds all objects with a specified setof properties that are located within a user-specified distance of theposition or feature.
Services to find differences between two data sets that represent the samegeographical area at different times
Service that adjusts sensor geometry models to improve the match of acoverage (or image) with other coverages and/or known ground positions
Service that reduces spatial variation in a feature collection to counteract
the undesirable effects of scale reduction

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Service name a
Coverage generalization services
Format conversion
services
Semantic translation
services aService description
Service that reduces spatial variation in a coverage to counteract theundesirable effects of scale reduction
Service that converts data from one format to another, including datacompression and decompression
Service that converts data from one set of semantics to anothera Names ending in “Service” are currently specified specific services. Names ending in “services” are types ofservices that are not yet specified.
b

Can process both feature and image (coverage) data.

5.4

Application Services tier

The Application Services tier contains services designed to support Clients, especiallythin client software such as web browsers. That is, these Application Services aredesigned for use by clients instead of each client directly performing these often-needed
support functions. The services in the Application Services tier are used by Clients, andcan use other services in the Application Services, Processing Services, and Information
Management Services tiers. The services included in this tier include (but are not limitedto) the services listed in Table 4.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

11

OGC 05-042r2

Table 4 — Some specific Application Services
Service name a
Web portal services
WMS application
services
Gazetteer application
services
Geographic data
discovery services
Geographic data
extraction services
Geographic data
management services
Map stylemanagement services
Map symbol
management services
Data structure
management services
Feature generalization
application services
Coverage generalization services
Other application
services
Chain definition
services
Workflow enactment
services

Service description
Services that allow a user to interact with multiple application services fordifferent data types and purposes
Services that allow a user to interact with a Web Map Service (WMS) tofind, style, and get data of interest
Services that allow a user to interact with a Gazetteer service
Services that allow a user to locate and browse metadata about geographic
data, interacting with a catalog
Services that allow a user to extract and edit feature data, interacting withimages and feature data
Services that allow a user to manage geospatial data input and retirement,interacting with Information Management Services
Services that allow a user to create, edit, and manage map styles, interactingwith Information Management Services
Services that allow a user to create, edit, and manage map symbols,
interacting with Information Management Services
Services that allow a user to create, edit, and manage data structures,interacting with Information Management Services
Services that allow a user to interact with Processing services for feature
generalization
Services that allow a user to interact with Processing services for coverage
generalization
Services that allow a user to interact with other Processing and Information
Management services
Services to define a service chain and enable it to be executed by the
workflow enactment service; may also provide a chain validation service
Services to interpret chain definitions and control instantiation of servers andsequencing of activities, maintaining internal state information associatedwith various services being executed

Access control
services

Services that control access to other servers, for privacy, intellectual
property, and other reasons

Usage accounting
services

Services that keep track of the usage of other servers, for billing and otherpurposesa Names ending in “Service” are currently specified specific services. Names ending in “services” are types ofservices that are not yet specified.

6

Services chaining

In many cases, multiple services must be used together to perform a useful function. The
OWS architecture thus supports “chaining” together of multiple servers, and suchchaining is often used. This chaining is not limited to a linear chain; a network of services
can also be “chained”. Within such a chain, most servers input the data that is output
from the previous server in the chain. Services can be chained transparently (defined andcontrolled by the client), translucently (predefined but visible to the client), and opaquely

12

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2(predefined and not visible to client), see Subclause 7.3.5 of [OGC 02-006 and ISO
19119].
To facilitate service chaining, some services are defined to support defining andexecuting chains of services. Also, some Processing Service interfaces are designed tosupport retrieving the data to be processed from another service, which can be an
Information Management Service or another Processing Service. To allow more efficient
execution of server chains, some service interfaces support server storage of operation
results until requested by next service in a chain.
7

Service interfaces

The basic components of a service oriented architecture are services. There are many
definitions of “service”, from the abstract to the concrete and practical. One definition is“useful/meaningful combination of operational interfaces and accessible content”. Thisdefinition adds “content” to the ISO/OGC definitions:a) Service: distinct part of the functionality that is provided by an entity throughinterfaces.
b) Interface: named set of operations that characterize the behavior of an entity.
c) Operation: specification of a transformation or query that an object may be called to
execute. It has a name and lists of input and output parameters.
OGC web service interfaces use open standards and are relatively simple. All services
support open standard interfaces from their clients, often OGC-specified service
interfaces. In addition to being well-specified and interoperable tested, the OGC-specified
service interfaces are coarse-grained, providing only a few static operations per service.
For many services, only three service operations are specified.
NOTE 1 OGC web service interfaces are not fine-grained object-oriented, providing tens of operations
per service to be implemented and exercised, with some interface objects being dynamically created anddestroyed.

In most cases, one service listed in Clause 5 includes just one interface. However, it ispossible for one service to include more than one identified interface, normally limited toa few such interfaces. Also, one server can implement multiple interfaces wheneveruseful, without those interfaces being combined in a specified service.
NOTE 2 One service interface is not required to support all the abilities of one server. For example,
some WCS, WMS, and WFS data servers are expected to also implement CSW service interfaces
cataloging the datasets available from that server.

The OGC web service interfaces are usually stateless, so session information is notpassed between a client and server. Clients (or Application Services) retain any neededinterface state between operations.
NOTE 3 Client-service sessions are not used, not requiring servers to retain interface state between
operations. This also simplifies use in a dynamic network, where a server can stop operation or fail.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

13

OGC 05-042r2

The OGC web service interfaces share common parts whenever practical, allowing thoseparts to be specified and implemented only once. For example, all OWSs have amandatory GetCapabilities operation to retrieve server metadata. That server metadata
includes four required sections, with the contents and format of three sections common to
all services, and part of the fourth section common to most services. In addition, many
service interfaces have multiple specified levels of functional compliance, or multiple
specialized subset and/or superset profiles.
NOTE 4 The interface parts are NOT separately and independently specified and developed. When moreparts are common among interfaces, less work is needed to implement services and define new ones. In
addition to the GetCapabilities operation, all OWSs have one mandatory operation to get a data subset, andmost have one optional operation to get the description of a dataset or object. Interface compliance levels
and profiles inherently share interface parts wherever practical.

Standard XML-based data encoding formats and languages are used in many server-toclient and client-to-server data transfers. The formats and languages specified include(but are not limited to) those listed in Table 5. In these formats and languages andelsewhere, the geographic data and service concepts are closely based on the ISO 191XX
series of standards.
NOTE 5 The ISO 191XX data and service concepts were developed by international groups of experts,
so are carefully formulated and are being widely used. The concepts or semantics used by different services
are not independently developed and specified.

Table 5 — Some standardized encoding formats and languages
Specification name
Filter Encoding (FE)OGC Common Catalog
Query Language
Styled Layer Descriptor(SLD)
Geography Markup
Language (GML)
Coordinate Reference
Systems (part of GML)
Web Map Context
OWS Context
URNs using ogc URN
namespace
Sensor Model Language(SensorML)
Web Service Description
Language (WSDL)
Business Process Execution
Language (BPEL)

14

Description
Encodes queries for features or other data meeting specified constraints
Encodes catalog queries for objects meeting specified constraints
Encodes client-controlled styling for map portrayal of features andcoverages (images)
Language defined using XML Schemas based on the ISO 191XX seriesof standards, to be used to specify application-specific XML Schemas
Encodes definitions of coordinate reference systems, coordinate
systems, datums, and coordinate transformations (and conversions)
Encodes WMS application display context
Encodes multiple OWS application display context
Standardized Universal Resource Identifiers (URNs) referencing mostwell-known coordinate reference systems (CRSs) and grid CRSs
Encodes descriptions of remote and in-situ sensors, including imaging
and environmental sensors
Encodes web service interfaces
Encodes process sequences for specific purposes

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

88.1

Services communication
Overview

Communication between clients and services, and between services, uses only open nonproprietary Internet standards. That is, the OWS architecture uses the Internet or
equivalent as its distributed computing platform (DCP). More specifically,
communication between components uses standard World Wide Web (WWW) protocols,
namely HTTP GET, HTTP POST, and Simple Object Access Protocol (SOAP). Specificoperations of specific servers are addressed using Uniform Resource Locators (URLs).
Multipurpose Internet Mail Extensions (MIME) types are used to identify data transfer
formats. The data transferred is often encoded using the Extensible Markup Language(XML), with the contents and format carefully specified using XML Schemas.
NOTE
Communication between components does not use CORBA, DCOM, .NET, or SQL. However,those protocols can be used within the implementation of a server.

8.2

HTTP GET operation requests

In many cases, a request to perform an operation by a service is transferred as aHypertext Transfer Protocol (HTTP) GET message. That GET message is addressed to a
HTTP Uniform Resource Locator (URL), where that URL locates a specific operation ofa specific server. A URL for a HTTP GET request is in fact only a URL prefix, to which
additional parameters are appended to construct a valid operation request. The prefix
defines the network address to which operation request messages are sent, and may also
identify a configuration of that server.
A query is appended to the URL prefix to form a complete request message. Each OWS
operation request has mandatory and usually optional request parameters. Each parameterhas a defined name, and has multiple allowed values. To formulate the query part of the
URL, the mandatory request parameters, and any desired optional parameters, areappended as name/value pairs in the form "name=value&" (parameter name, equals sign,
parameter value, ampersand). In the OGC, this parameter encoding is often referred to as
keyword value pair (KVP) encoding.
8.3

HTTP POST operation requests

Less frequently, a request to perform an operation by a service is transferred as aHypertext Transfer Protocol (HTTP) POST message. That POST message is addressed toa (possibly different) HTTP Uniform Resource Locator (URL), where that URL locates a
specific operation of a specific server. A URL for a HTTP POST request is a complete
URL (not merely a prefix as in the HTTP GET case).
Clients transmit request parameters to the URL in the body of the HTTP POST message.
An OWS does not require additional parameters to be appended to the URL in order toconstruct a valid target for the operation request. When HTTP POST is used, theoperation request message is normally encoded as an XML document, formatted as
specified by one or more XML Schemas. The operation request message can alternately
be KVP encoded, in the body of the HTTP POST message.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

15

OGC 05-042r2
8.4

HTTP operation responses

After receiving an operation request, a server replies with a response message
corresponding exactly to the request, or sends an exception report if unable to respondcorrectly. Responses to operation requests are the same whether the request is transferredby HTTP GET or POST. In most cases, the operation response is encoded in XML, using
XML Schemas to specify the correct response contents and format. These statements
apply to both normal and exception operation responses, which are separately specified
for each OWS service.
All XML Schemas used contain documentation of the meaning of each specified element,
attribute, and type. All of these documentation elements are considered normative, unlesslabeled “informative”. Almost all of the concrete XML elements defined in these OWS
Schemas can be used without separate XML Schemas, whenever no content extensions or
restrictions are needed. An additional XML Schema is used whenever element contents
extension is required, and should be used in some other cases to specify needed
restrictions.
NOTE
XML documents are not required to be validated against their respective schemas for normal
service use. However, XML parsing and validation should follow normal XML syntax rules, for example
regarding XML Namespaces.

A server may send an HTTP Redirect message (using HTTP response codes as defined in[IETF RFC 2616]) to an absolute URL that is different from the valid request URL thatwas sent by the client. HTTP Redirect causes the client to issue a new HTTP request for
the new URL. Several redirects could in theory occur. Practically speaking, the redirect
sequence ends when the server responds with an operation response. The final responseshall be an OWS operation response that corresponds exactly to the original operation
request, or an exception report.
8.5

MIME types use

Response messages are accompanied by the appropriate Multipurpose Internet Mail
Extensions (MIME) type for that message. A list of MIME types in common use on theinternet is maintained by the Internet Assigned Numbers Authority [IANA]. Servers can
support parameterized MIME types, and this is common to more completely identify the
specific format. In addition to parameterized MIME types, servers usually offer the basic
un-parameterized version of the format, for clients that do no understand theparameterized MIME type.
Response messages are accompanied by other HTTP entity headers as appropriate. In
particular, the Expires and Last-Modified headers provide important information for datacaching. Content-Length may be used by clients to know when data transmission iscomplete and to efficiently allocate space for results, and Content-Encoding or ContentTransfer-Encoding may be necessary for proper interpretation of the results. When
returning a large XML document, some form of data compression should be supported;since client-server communication transfer speeds will be considerably faster if the
document is compressed.

16

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2
8.6

SOAP operation requests and responses

In some cases, a request to perform a specific operation by a specific server can betransferred in a Simple Object Access Protocol (SOAP) operation request message. That
SOAP request message is addressed to a HTTP Uniform Resource Locator (URL), wherethat URL locates a specific operation of a specific server (TBR). In this case, theoperation request parameters are encoded in XML just like they can be for HTTP POST.
When SOAP is used, the response from that operation is transferred in a SOAP operation
reply message, and is XML encoded just like responses to HTTP POST requests.
9

Server implementation

Servers and client implementations are not constrained except for supporting thespecified service interfaces. Each can be implemented by software executing on any
general purpose computer connected to the Internet or equivalent. The architecture is
hardware and software vendor neutral. The same and cooperating services can be
implemented by servers that are owned and operated by independent organizations.
NOTE
Cooperating servers and clients need not be owned and operated by one organization or byformally cooperating organizations.

All OWS services and clients are implemented by available standards-based Commercial
Off The Shelf (COTS) software. This commercial software can sometimes be usedwithout requiring major software development, or can be adapted to specific needs withlimited software development.
All services are self-describing, supporting dynamic (just-in-time) connection binding ofservices supporting publish-find-bind. That is, each server is able to “publish itself”, byproviding a single authoritative source of its own server description upon request.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

17

OGC 05-042r2

Annex A
(informative)
Service trading (publish – find –bind)Service trading supports the offering and discovery of interfaces which provide servicesof particular types. A trader implementation records service offers and matches requests
for advertised services. Publishing a capability or offering a service is called “export”.
Matching a service request against published offers or discovering services is called“import”. This can also be described in an equivalent manner as the “Publish – Find –Bind” (PFB) pattern of service interaction. The fundamental roles are:a) Trader (Registry) - registers service offers from exporter objects and returns service
offers to importer objects upon request according to some criteria.
b) Exporter (Service) - registers service offers with the trader objectc) Importer (Client) - obtains service offers, satisfying some criteria, from the trader
object.
NOTE
In the OWS architecture, a Registry can be implemented using the Catalog Service for the
WEB (CSW) service interface.

The ODP Trading function is elaborated in document [ISO/IEC 13235-1] and refinedsomewhat in the OMG Trading specification [TBD], which is technically aligned withthe computational view of the ODP trading function. Most importantly, a trader supports
dynamic (i.e. run-time) binding between service providers and requesters, since sites andapplications are frequently changing in large distributed systems. The fundamental roles
and interactions are depicted in Figure 2.1 The equivalent PFB terminology is shown aswell (blue italic text). A trader registers service offers from exporter objects and returns
service offers upon request to importer objects according to some criteria.

1 Many readers will recognize Figure 2 : many of the recent web services white papers include
similar diagrams that map onto it directly. In many cases ‘find’, ‘bind’, and ‘publish’ substitutefor ‘import’, ‘service interaction’, and ‘export’, respectively.

18

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Trader(Registry)

Import(Find)

Export(Publish)

Exporter(Service)

Importer(Client)

service interaction(Bind)
Figure 2 — Service trading objects
A Trader plays the role of “matchmaker” in a service-based architecture. The interaction
pattern is:a) To publish a service offer, an Exporter gives a Trader a description of a server,
including a description of the interface at which that service instance is available.
b) To find suitable server offers, an Importer asks a Trader for a server having certain
characteristics. The trader checks the previously registered descriptions of servers andresponds to the importer with the information required to bind with a service instance.
Preferences may be applied to the set of offers matched according to service type,
constraint expressions, and various policies. Use of the preferences can determine theorder used to return matched offers to the importer.
c) To bind a service, an Importer applies information received from the Trader to bind toa server. The Client then proceeds to use that server.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

19

OGC 05-042r2

Annex B(informative)
Architecture tiers relationship to ISO 19119

The four tiers of the OWS architecture are loosely related to the geographic services
categories specified in Subclause 8.3 of ISO 19119 Geographic information — Services(copied in OGC Abstract Specification Topic 12). This relationship is:a) The Application Services and the Clients together provide the “human interaction
services” described in Subclause 8.3.2.
b) The Processing Services provide the “processing services” described in Subclause
8.3.5. It would be possible to divide these services into the “spatial”, “thematic”,“temporal” and “metadata” categories described in Subclause 8.3.5.
c) The Information Management Services provide the “model/information management
services” described in Subclause 8.3.3.
In this description of the OWS architecture, the storage of datasets is not separated from
catalogues or registries that store and search metadata, because they are not separated in
ISO 19119. Also, these services are not separated because that distinction is frequently
fuzzy. Furthermore, one server can implement a dataset storage and retrieval interface
plus a catalogue interface for storing and searching the metadata for those datasets.
Some services perform functions of more than one tier, when those functions are usuallyused together and combined implementation is more efficient. Assignment of suchcombined services to tiers is somewhat arbitrary. For example, all services in the
Information Management Services tier can include some processing of the data retrieved.
Specifically, WMS, WCS, and WFS can perform coordinate transformation and format
conversion.

20

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

OGC 05-042r2

Annex C
(informative)
OWS architecture relationship to RM-ODP

This architecture description is organized for ease-of-understanding, not according to thefive viewpoints specified in the Reference Model for Open Distributed Processing (RMODP) [ISO 10746]. The concept of distributing computing functions across a network ina dynamic fashion has been addressed by this RM-ODP, which is a conceptual
framework for such systems, and implementation patterns or rules. Five standard
viewpoints are defined; these viewpoints address different aspects of the system andenable the ‘separation of concerns’:a) Enterprise viewpoint: articulates a “business model” that should be understandable by
all stakeholders; focuses on purpose, operational objectives, policies, enterpriseobjects, etc.
b) Information viewpoint: focuses on information content and system behavior (i.e. data
models, semantics, schemas)c) Computational viewpoint: captures component and interface details without regard to
distributiond) Engineering viewpoint: exposes the distributed nature of the system and provides
standard definitions to describe engineering constraintse) Technology viewpoint: describes where to apply the technologies/products of choice
and allows for conformance testing against the architectural specification
This architecture description currently says little directly about the Enterprise andInformation viewpoints. We think this OWS architecture is applicable to a broad range of
purposes, using a broad range of information. However, Tables 1 and 2 suggest some of
the types of information handled.
Many aspects of the Computation viewpoint are discussed in Clauses 5-7 of thisdocument. Clauses 8 and 9 discuss some aspects of the Technology and Engineering
viewpoints.

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.

21

OGC 05-042r2

Bibliography[1]

CGI, The Common Gateway Interface, National Center for Supercomputing
Applications, http://hoohoo.ncsa.uiuc.edu/cgi/[2]

IETF RFC 2045 (November 1996), Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies, Freed, N. and BorensteinN., eds., http://www.ietf.org/rfc/rfc2045.txt[3]

IETF RFC 2141 (May 1997), URN Syntax, R. Moats
http://www.ietf.org/rfc/rfc2141.txt[4]

IETF RFC 2396 (August 1998), Uniform Resource Identifiers (URI): Generic
Syntax, Berners-Lee, T., Fielding, N., and Masinter, L., eds.,
http://www.ietf.org/rfc/rfc2396.txt[5]

IETF RFC 2616 (June 1999), Hypertext Transfer Protocol – HTTP/1.1, Gettys, J.,
Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T., eds.,
http://www.ietf.org/rfc/rfc2616.txt[6]IANA, Internet Assigned Numbers Authority, MIME Media Types,
http://www.iana.org/assignments/media-types/[7]

ISO/IEC 10746-1:1998, Reference Model for Open Distributed Processing (RMODP)[8]

OGC 2001, Introduction to OGC Web Services[9]

OGC 02-006, OpenGIS Abstract Specification Topic 12: OpenGIS Service
Architecture[10]

OGC 03-025, OpenGIS Web Services Architecture[11]

OGC 05-008, OGC Web Services Common Specification, version 1.0.0[12]

OGC 05-010, URNs of definitions in ogc namespace[13]

SIDP (Spatial Interoperability Demonstration Project) 2004-2005, Notional
Architecture, http://www.sidp.com.au/[14]

W3C Recommendation 04 February 2004, Extensible Markup Language (XML)
1.0 (Third Edition), http://www.w3.org/TR/REC-xml[15]

W3C Recommendation 2 May 2001: XML Schema Part 0: Primer,
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/[16]

W3C Recommendation 2 May 2001: XML Schema Part 1: Structures,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/[17]

W3C Recommendation 2 May 2001: XML Schema Part 2: Datatypes,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

22

Copyright © 2005 Open Geospatial Consortium, Inc. All Rights Reserved.