Progress in OGC Web Services Interoperability Development

Abstract

Decision makers in business and government have historically depended on geomatics experts when they have sought to benefit from Earth observation systems. Similarly, scientists in fields other than geomatics have had to either learn about geomatics or team with geomatics experts to benefit from these systems. Fortunately, as Earth observation technologies and markets have progressed, standards have steadily advanced, which, along with other benefits described below, allows geomatics experts to establish reusable services for routine decision-making.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

4.1 OGC Vision for Geospatial Interoperability

Decision makers in business and government have historically depended on geomatics experts when they have sought to benefit from Earth observation systems. Similarly, scientists in fields other than geomatics have had to either learn about geomatics or team with geomatics experts to benefit from these systems. Fortunately, as Earth observation technologies and markets have progressed, standards have steadily advanced, which, along with other benefits described below, allows geomatics experts to establish reusable services for routine decision-making.

The Open Geospatial Consortium, Inc. (OGC) is the organization that has most prominently and successfully created and promoted Web services standards for geoprocessing and geospatial decision support. OGC’s vision is the realization of the full societal, economic and scientific benefits of integrating electronic location resources into commercial and institutional processes worldwide. Is support of this vision, OGC’s mission is to serve as a global forum for the collaboration of developers and users of spatial data products and services, and to advance the development of international standards for geospatial interoperability (http://www.opengeospatial.org/ogc/vision)

4.1.1 OGC Overview

The OGC is a not for profit, international voluntary consensus standards organization founded in 1994. The core mission of the OGC is to develop standards that enable interoperability and seamless integration of spatial information, processing software, and spatial services. Spatial information and processing encompass geographic information systems (GIS), remote sensing, surveying and mapping, navigation, location-based services, access to spatial databases, sensor webs, and other spatial technologies and information sources.

Spatial information and processing play an important role in business, government, and research applications and workflows. However, the benefits of using spatial information and services are often limited by the inability to effectively share information between different vendors’ solutions and different types of systems. In the OGC’s consensus process, over 360 government, private sector, and academic organizations cooperatively define, develop, test, document, validate, and approve interface and encoding standards that overcome the interoperability problems.

The OGC baseline of adopted standards includes these implementation specifications (http://www.opengeospatial.org/ogc/standards):

• Web Map Service (WMS)

• Web Feature Service (WFS)

• Web Coverage Service (WCS)

• Catalogue Service for the Web (CSW)

• Sensor Observation Service (SOS)

• Sensor Planning Service (SPS)

• Sensor Alert Service (SAS)

• Geography Markup Language (GML)

• Web Map Context

• KML

The OGC standards baseline allows for service-oriented architecture as shown in Fig. 4.1.

Fig. 4.1

Geospatial Web services based on open interfaces and encodings enable users and software to access diverse data and processing resources on the Web

Specific interoperability requirements are brought into the OGC process by government agencies, vendors, and universities, and by integrators working on behalf of their customers. In OGC testbeds, interoperability experiments, and pilot projects, sponsoring organizations pool their interoperability requirements and arrange incentives for technology providers to work together to make their systems work together. Sometimes technology developers submit interoperability requirements to meet anticipated needs in the marketplace.

4.1.1.1 Benefits for Technology and Content Providers

Competing technology and content providers collaborate in the OGC because they recognize that lack of interoperability is a bottleneck that slows market expansion. Interoperability enabled by open standards positions them to both compete more effectively in the marketplace and to seek new market opportunities. In the OGC, technology and content provider members:

• Position themselves early to influence definition of new open standards.

• Reduce costs through cooperative standards development with other OGC members.

• Shorten time to market by using OGC standards rather than custom interfaces.

• Can enter new markets and find new customers because of “plug and play”.

• Have a convenient forum for discussion of industry issues and solve shared problems.

• Form customer relationships and business partnerships.

• Deliver solutions more quickly and at lower cost.

• Can mobilize a range of products across open interfaces, rather than performing resource intensive custom integration.

• Provide precise solutions to meet specific needs, solutions that plug and play.

The development of these standards does not require the member to give up any intellectual property or trade secrets. The use of open standards to connect components, applications, and content – allowing a white box view on the components’ functionality and interrelationships without revealing implementation details – fulfills the industry requirement for protection of intellectual property as well as the user requirement for transparency. Such transparency supports both interoperability and the credibility of the enterprise, or federated solution.

4.1.1.2 Benefits for Technology Consumers

Technology consumer members can:

• Voice their interoperability needs directly to a broad and global industry, academic and government community. In this setting, vendors, integrators, and platform providers build interoperability interfaces far faster than is possible with traditional system integration contracting. And the benefits are shared globally.

• Be assured that reusability of software is achieved. This is often cited as the single greatest benefit anticipated from complying with standards or helping to establish them.

• Work with other users in the OGC process to demonstrate the need for and potential market appeal of new requirements for specifications.

• View OGC programs as a form of technology risk reduction. Small resource investments in the OGC industry consensus processes often result in industry willingness to address and then broadly implement OGC specifications in their products. Standards help users maximize the return on their current and future technology investments, while reducing the time and cost of customized integration.

• Mobilize new technology solutions quickly, and adapt easily to the rapidly changing information technology world, policy changes, and new and emerging requirements.

• Leverage existing investments in legacy content and applications. The use of standards provides a fulcrum to leverage IT investments and create liquidity. Standards provide a platform for realizing opportunities that would otherwise remain hidden.

• See the OGC process as a method for procurement reform. Users benefit by expressing their interoperability requirements first in the OGC specification process, then by adopting procurement language that calls for OGC specifications in the geospatial and location based services products to be considered for purchase and deployment.

4.1.1.3 Policy on Intellectual Property

The OGC offers its specifications free of charge to all, and adheres to a rigorous process to ensure that OGC standards remain free of royalties for use. The OGC strongly supports royalty-free standards, a position also taken by the World Wide Web Consortium and other prominent standards organizations. The OGC believes that standards consortia play a major role in maintaining a free and open Web, and that open geoprocessing standards are an important part of the free and open Web.

The sections below provide more detail on OGC Web Services (OWS) standards.

4.1.2 OGC Standards Overview

The OGC consensus process for defining, developing, and approving a standard generates a number of documents. These documents are typically first developed in testbeds and interoperability experiments managed in the OGC Interoperability Program. Then the draft standards work their way through the approval process in the OGC Specification Program, which includes the OGC Technical Committee and the OGC Planning Committee. Approved OGC standards detail the interface or encoding structures that, when implemented, enable interoperability between systems.

Standard interfaces, protocols, and encodings enable different software and application products to communicate, whether they are running on the same computer or they are exchanging instructions across the Web. These standards also enable much easier integration of complex systems. Standards are necessary ingredients for designing and implementing “open architectures” and for “service oriented architectures (SOA)” that need to be accessed by various clients and server processes running on diverse and unknown computing platforms across the Web. Standards also reduce dependence on single point solutions, reduce risk, reduce software lifecycle costs, and create new business opportunities for technology providers. Providing “open” access to data and services on the Web and making it discoverable through a spatial catalog exposes those data and services to a much larger set of potential users, and thus increases the data’s value.

Below we describe some of the adopted OpenGIS Implementation Standards and other documents that are most relevant to Earth observation. The full set of OGC adopted standards are available online (http://www.opengeospatial.org/ogc/standards).

• The OpenGIS ® Web Map Service (WMS) Interface Standard supports the creation and display of registered and superimposed map-like views of information that come simultaneously from multiple remote and heterogeneous sources. The servers can be servers of raster or vector data, or even scanned maps. The maps are delivered to the browser or other Web-based viewing application in simple Web graphic image formats. The OpenGIS® Styled Layer Descriptor (SLD) Implementation Standard extends the WMS specification to allow user-defined symbolization of feature data.

• The OpenGIS ® Web Coverage Service (WCS) Interface Standard interface allows client and/or application query and access to geospatial “coverages”, such as imagery and digital elevation models. The result of the coverage query (the actual data) is made available to the client, service, or application. The WCS operations allow for access to imagery including subsetting requests in space, time and parameters.

• The OpenGIS ® Web Feature Service (WFS) Interface Standard enables a client or service that implements the interface to retrieve and optionally update geospatial feature data from any server that implements the WFS interface. The WFS interface does not “care” how the feature data are stored. The interface is content and storage model independent. The result of a WFS query is typically returned as a GML document.

• The OpenGIS ® Web Map Context (WMC) Interface Standard is a companion specification to the Web Map Service Standard and allows an application to store “state” information. The XML-encoded Context document includes information about the WMS servers providing layers to the overall map, the bounding box and map projection shared by all the maps, and so forth. This is sufficient metadata for any client software to reproduce the composite map, and ancillary metadata used to annotate or describe the maps and their provenance for the benefit of human viewers.

• The OpenGIS ® Web Image Classification Service (WICS) Interface Standard deals specifically with classification of digital images. This draft specification provides a web based interface to image classification services of any type. This specification does not specify a particular classification algorithm. The interface allows a client to request that the service perform a classification on a source image resulting in a grid coverage feature with the attributes being categories. This specification allows for clients to request classification from a variety of algorithms. This document is currently a Discussion Paper, which after further development may become an implementation specification.

• The OpenGIS ® Web Coordinate Transformation Service (WCTS) Interface Standard defines an interface to request transformation of geospatial data from one coordinate reference system (CRS) to another. Geospatial data including imagery are often stored in different CRSs. For an application to use data stored in different CRSs, such data must be transformed or converted into the same CRS. This service inputs digital features or coverages in one CRS and outputs the same features in a different CRS. This document is currently an OGC Discussion Paper, which may become an implementation specification.

• The OpenGIS ® Catalog Services Web (CSW) Interface Standard defines common interfaces to discover, browse, and query metadata about data, services, and other potential resources. Once substantial numbers of data sets and geospatial Web services have been registered in such catalogs with metadata that conforms to ISO/CD TS 19139 (XML schema implementation), users (and automated processes) will have a far greater ability to find data and services.

• The OpenGIS ® Geography Markup Language (GML) Encoding Standard is an XML-based language for encoding geographic information to be transported over the Internet or other transport environments. GML encodes both the geometry and properties of objects that comprise geographic information. GML allows the data to be controlled in the client by the user who receives geometries and geographic features and customizes how the data is to be displayed. Profiles and application schemas of GML can be defined to meet the requirements of specific information communities. An example is the new OpenGIS GML in the JPEG 2000 Implementation Standard, which defines the means by which the GML can be used within JPEG 2000 images for geographic imagery.

• The OpenGIS ® CityGML Encoding Standard is an open data model framework encoding standard for the storage and exchange of virtual 3D urban models. It is an application schema of GML3. Computer Aided Design (CAD)/geospatial convergence is necessary because the architecture/engineering/construction industry and other domains often need to use building information in the context of diverse geospatial information. The use of CityGML can be of significant relevance to the IEEE GRSS research in urban settings. (See the section regarding current developments in CAD/Geospatial integration.)

• The OpenGIS® Web Processing Service (WPS) Interface Standard provides rules for standardizing inputs and outputs (requests and responses) for geospatial processing services. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The goal is to provide consistency among the various types of geoprocessing services, to ensure the success of complicated service chaining and workflows involving multiple types of services.

• The OGC Reference Model is a document that describes all the OpenGIS Specifications, how they work together, and how they work in various distributed computing environments. This is a good place to begin a study of OGC’s technical baseline and standards framework (http://www.opengeospatial.org/standards/orm).

4.1.3 Sensor Web Enablement (SWE)

Sensor technology, computer technology, and network technology are advancing together while demand grows for ways to connect information systems with the real world. The OGC’s Sensor Web Enablement (SWE) standards enable developers to make all types of sensors, transducers, and sensor data repositories discoverable, accessible, and useable via the Web.

SWE standards are developed and maintained by OGC members who participate in the OGC Technical Committee’s Sensor Web Enablement Working Group. OGC members have reached agreement on the most of the issues involving digital communication about the complex location, motion, and optical parameters involved in satellite-borne imaging systems and photogrammetry as well as virtually all aspects of other types of sensors and sensor data. SWE standards offer developers:

• Open interfaces for sensor web applications

• “Hooks” for IEEE 1451, TML, CAP, WS-N, ASAP

• Imaging device interface support

• Sensor location tied to geospatial standards

• Fusion of sensor data with other spatial data

• Opportunity to participate in an open process to shape standards, in cooperation with IEEE and other standards organizations

Below are listed the main adopted OpenGIS Standards in the SWE framework:

• The OpenGIS(R) Observations & Measurements (O&M) Encoding Standard provides general models and XML encodings for observations and measurements.

• The OpenGIS(R) Sensor Model Language (SensorML) Encoding Standard provides standard models and XML Schema for describing the processes within sensor and observation processing systems.

• The OpenGIS(R) Transducer Markup Language (TML) Encoding Standard provides a Conceptual model and XML encoding for supporting real-time streaming observations and tasking commands from and to sensor systems.

• The OpenGIS(R) Sensor Observation Service (SOS) Interface Standard provides open interface for a web service to obtain observations and sensor and platform descriptions from one or more sensors.

• The OpenGIS(R) Sensor Planning Service (SPS) Interface Standard provides an open interface for a web service by which a client can 1) determine the feasibility of collecting data from one or more sensors or models and 2) submit collection requests.

SWE was one of the main focus areas in OGC’s 2005 OGC Web Services 3 (OWS-3) testbed activity. Important progress was made in harmonizing the SWE services listed above with the IEEE 1451 standard for plug-and-play sensors.

Other SWE standards are under discussion or in various stages of development.

4.2 Current Developments

The interfaces described above have been implemented in hundreds of commercial products, custom systems, and open source applications. (See http://www.opengeospatial.org/resources/?page=products.) But much work remains, and many other specifications are working their way through OGC’s processes. Below is a summary of the main technology domains in which there is ongoing specification development activity:

• Geospatial Rights Management (GeoRM) – Efforts to manage data ownership and data rights in the digital environment are of great interest to geospatial data providers who need to control access to their data and how it is used. This is of concern to data sellers, to organizations whose data is for internal use only, and to those whose data distribution follows a library model. GeoRM involves persistent management of a geospatial digital object under a set of rights and conditions. GeoRM is now an approved OGC reference model.

• Access control is a necessary complement to rights management. The adopted OpenGIS® Geospatial eXtensible Access Control Markup Language (GeoXACML) Encoding Standard defines a geo-specific extension to the XACML Policy Language 2.0 (eXtensible Access Control Markup Language (XACML) Version 2.0), as standardized by the Organization for the Advancement of Structured Information Standards (OASIS). GeoXACML is likely to become one of the standards registered in the GEOSS Standards and Interoperability Registry. It is a key technology for enabling institutional interoperability.

• Geoprocessing Workflow – Geoprocessing creates geospatial information specific to a user’s specific decision-making needs. In some cases, a chain of OGC Web services is needed to produce the specific value-added products needed. OGC Web Services can be chained together using the OASIS Business Process Execution Language (BPEL) specification. For example, the OGC Web Coordinate Transformation Service (WCTS) and the OGC Web Image Classification Service can be “chained” into an integrated workflow.

• The Geo-Processing Workflow (GPW) thread in the sixth OGC Web Services testbed, OWS-6, aims to develop and demonstrate interoperability among geo-processes through service chaining, workflow and web services, with emphasis on implementing security capabilities for OGC web services, including SWE services. Work in this thread builds on the results from previous testbeds, including authentication/authorization and Simple Object Adaptor Protocol (SOAP)/ Web Services Description Language (WSDL) recommendations. The workflow and security tasks involve three operational security environments: 1) internal to a single trusted domain; 2) between two trusted domains; and 3) between a trusted and non-trusted (or temporarily-trusted) domain.

• Decision Support Services: In the past “decision support systems” have been monolithic applications that helped managers find solutions to difficult management problems. With the advent of the Internet and distributed web services it is now possible to define decision support as the coordination of various services that transparently convert geospatial data from other communities into terms familiar to the user. A decision maker is able to sit down at a single workstation, identify any geospatial resource anywhere, access that resource, bring it into the user’s operational context, and integrate it with other resources to support the decision process. (See section on SOAP and REST.) The focus for DSS in the OWS-6 testbed builds on portrayal, WMS Tiling, integrated clients, and 3D visualization and integration of the built environment and landscape.

• Data portrayal requirements are often complex and largely based on feature attribution as opposed to simply feature types. To address complex symbology requirements, participants in the OWS-6 testbed are exploring ways to integrate the OGC’s OpenGIS® Styled Layer Descriptor (SLD) Standard, a profile of the OpenGIS® Web Map Service (WMS) Encoding Standard, with the ISO standard for portrayal (ISO 19117 v.2.0) and the International Hydrographic Office (IHO) S52 symbology for maritime features.

• CAD/Geospatial Integration: Through Building Information Models (BIM) supported by various software vendors’ products, professionals in the architecture/engineering/construction industry and related domains seek to make it easy to integrate building information of all kinds, including diverse geospatial information. To standardize BIM, the International Alliance for Interoperability (IAI) has provided Industry Foundation Classes (IFC), consensus-based open standards that support communication of project lifecycle data about a building (http://www.iai-tech.org/products/ifc_specification). But IFC is essentially a transfer standard or batch file conversion standard, analogous to the Spatial Data Transfer Standard (SDTS) introduced into the GIS industry in 1992 by the US Geological Survey (USGS). Like SDTS, IFC is cumbersome, and vendors have had little guidance or incentive to ensure that their implementations are consistent with other vendors’ implementations. To address this problem, the OGC and the buildingSMART alliance (bSa) have joined forces to develop candidate BIM standards in the joint bSa-OGC Architecture / Engineering / Construction / Owner / Operator Testbed (AECOO-1).

• Another current development in CAD/Geospatial integration is the OGC’s Web 3D Service (W3DS). W3DS specifies a Portrayal Service and is a relatively new OGC discussion paper. In its current form, it provides a 3D representation of geographic data. The advantages of using visualization-centric formats are that they support a wide range of features for controlling the visual appearance (e.g. textures, surface properties, animations, lighting, atmosphere) and that they can be more efficiently transmitted and encoded.

At every OGC meeting, new requirements for interoperability are discussed. If there is sufficient interest and resource, work begins and the participants report the results of their work at the next meetings. Initiatives such as Testbeds and Interoperability Experiments are planned and executed. The scope of the work keeps expanding, and so do the number of adopted specifications, the number of implementations, and the number of people who are benefiting from the implementations.

4.2.1 OWS Architecture

In the early 1990s, the OGC defined a vision for network-based geospatial computing. This vision has come to fruition using Web services. This section describes the vision and the OGC Web Services architecture.

The widespread application of computers and use of geographic information systems (GIS) have led to the increased analysis of geographic data within multiple disciplines. Through advances in information technology, society’s reliance on such data is growing. Geographic datasets are increasingly being shared, exchanged, and used for purposes other than their producers’ intended ones. GIS, remote sensing, automated mapping and facilities management (AM/FM), traffic analysis, geopositioning systems, and other technologies for Geographic Information (GI) have entered a period of radical integration.

Standards for geospatial interoperability provide a framework for developers to create software that enables users to access and process geographic data from a variety of sources across a generic computing interface within an open information technology environment. To elucidate:

• “a framework for developers” means that the International Standards are based on a comprehensive, common (i.e., formed by consensus for general use) plan for interoperable geoprocessing.

• “access and process” means that geodata users can query remote databases and control remote processing resources, and also take advantage of other distributed computing technologies such as software delivered to the user’s local environment from a remote environment for temporary use.

• “from a variety of sources” means that users will have access to data acquired in a variety of ways and stored in a wide variety of relational and non-relational databases.

• “across a generic computing interface” means that standard interfaces provide reliable communication between otherwise disparate software resources that are equipped to use these interfaces.

• “within an open information technology environment” means that the standards enable geoprocessing to take place outside of the closed environment of monolithic GIS, remote sensing, and AM/FM systems that control and restrict database, user interface, network, and data manipulation functions.

4.2.1.1 OWS Fundamentals

The fundamental principles of the OGC Web Services (OWS) architecture include:

• 1. Service components are organized into multiple tiers.

  • a. All components provide services, to clients and/or other components, and each component is usually called a service (with multiple implementations) or a server (each implementation).

  • b. 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.

  • c. Services can use other services within the same tier, and this is common in the Processing Services tier.

  • d. Servers can operate on (tightly bound) data stored in that server and/or on (loosely bound) data retrieved from another server.

• 2. Collaboration of services produces user-specific results.

  • a. All services are self-describing, supporting dynamic (just-in-time) connection binding of services supporting publish-find-bind.

  • b. Services can be chained with other services and often are chained, either transparently (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 [ISO 19119]

  • c. Services are provided to facilitate defining and executing chains of services.

• 3. Services communication uses open Internet standards.

  • a. Communication between components uses standard World Wide Web (WWW) protocols, namely HTTP GET, HTTP POST, and SOAP.

  • b. Specific server operations are addressed using Uniform Resource Locators (URLs).

  • c. Multipurpose Internet Mail Extensions (MIME) types are used to identify data transfer formats.

  • d. Data transferred is often encoded using the Extensible Markup Language (XML), with the contents and format specified using XML Schemas.

• 4. Service interfaces use open standards and are relatively simple.

  • a. OGC web service interfaces are coarse-grained, providing only a few static operations per service.

  • b. Service operations are normally stateless, not requiring servers to retain interface state between operations.

  • c. One server can implement multiple service interfaces whenever useful.

  • d. Standard XML-based data encoding languages are specified for use in data transfers.

• 5. Server and client implementations are not constrained.

  • a. Services are implemented by software executing on general purpose computers connected to the Internet. The architecture is hardware and software vendor neutral.

  • b. The same and cooperating services can be implemented by servers that are owned and operated by independent organizations.

  • c. Many services are implemented by standards-based Commercial Off The Shelf (COTS) software.

4.2.1.2 OWS Services Tiers

Except for clients, all OWS architecture components provide services to clients and/or to other 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 chapter.

Clients are software packages that provide access to a human user or operate as agents on behalf of other software. Software that provides access to a human user can range from a web browser to a monolithic application with specific tailoring to the users needs.

All services (or components) are loosely organized in four tiers.

• Client tier

• Application Services tier

• Processing Services tier

• Information Management Services tier

This organization is loose in that clients and services can bypass un-needed tiers. Services can use other services within the same tier, and this is common especially in the Processing Services tier. (This is further described in the previous section OWS Fundamentals section 1b and 1c.) Also, some services perform functions of more than one tier, when those functions are often used together and combined implementation is more efficient. Assignment of such combined services to tiers is somewhat arbitrary.

This 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 (loosely bound) 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 other services and servers.

4.2.1.2.1 Application Services Tier

The Application Services tier contains services designed to support Clients, especially thin client software such as web browsers. That is, these Application Services are designed 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, and can use other services in the Application Services, Processing Services, and Information Management Services tiers. The specific services included in this tier include (but are not limited to) the services listed in Table 4.1.

Table 4.1 Some specific Application Services

4.2.1.2.2 Processing Services Tier

The Processing Services tier contains services designed to process data, sometimes both feature and image (coverage) data. The services in the Processing Services tier are used by clients and by services in the Application Services tier. These services can use other services in the Processing Services and Information Management Services tiers. The specific services included in this tier include (but are not limited to) the services listed in Table 4.2.

Table 4.2 Some specific Processing Services

4.2.1.2.3 Information Management Services Tier

The Information Management Services tier contains services designed to store and provide access to data, 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 Services tier are used by clients and by services in the Application Services and Processing Services tiers. These services can use other services in the Information Management Services tier. The specific services included in this tier include (but are not limited to) the services listed in Table 4.3.

Table 4.3 Some specific Information Management Services

4.2.1.3 Service Trading (Publish – Find – Bind)

All OGC architecture services are self-describing, supporting dynamic (just-in-time) connection binding of servers using service trading. Service trading addresses discovery of available service instances. Trading facilitates the offering and the discovery of interfaces that provide services of 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 depicted in an equivalent manner as the “Publish – Find – Bind” (PFB) pattern of service interaction. The fundamental roles are:

• 1. Trader (Registry) – registers service offers from exporter objects and returns service offers to importer objects upon request according to some criteria.

• 2. Exporter (Service) – registers service offers with the trader object

• 3. Importer (Client) – obtains service offers, satisfying some criteria, from the trader object.

In the OWS architecture, a Registry is implemented using the OpenGIS® Catalog Service for the Web (CSW) Interface Standard.

A trader plays the role of “matchmaker” in a service-oriented architecture. The interaction pattern is:

• 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.

• 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, and responds to the importer with the information required to bind with a server. Preferences may be applied to the set of offers matched according to service type, constraint expressions, and various policies. Use of preferences can determine the order used to return matched offers to the importer.

• To bind a service, an Importer applies information received from the Trader to bind to a server. The Client then proceeds to use that server.

4.2.1.4 SOAP and REST

OGC anticipates ongoing changes and evolution in the distributed computing platforms (DCPs) in which the OGC standards are based. Geospatial operations and information concepts are not directly affected by the change in development DCPs but the implementation specifications must be written for specific platforms. OGC’s strategy is that the abstract models for geospatial services are mapped onto the various DCPs.

Currently for web services, the most important DCP discussions involve SOAP and REST, which define different approaches to implementing services in a web environment. SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of web services. Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. Development and initial adoption of OGC’s web services standards predated the development of SOAP and REST approaches.

In July 2006, OGC members agreed on a strategy that future revisions of existing and new OWS interface specifications must include an optional SOAP binding. Several OGC Interoperability Program initiatives developed approaches to using SOAP with OWS specifications. Recently SOAP profiles have been added to several OGC standards.

At the July 2007 OGC meetings in Paris, the members agreed to form a REST Subcommittee that would work on developing best practices guidance related to the use of OGC web services in a RESTful environment.

The consensus is that there is not an either/or decision related to “REST vs. SOAP”. Instead, we need best practices and guidance for both architecture patterns. There is agreement that both REST and SOAP have their strengths and weaknesses and that the real question is when to use either approach – or at times a blended approach.

4.2.1.5 Service 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 such chaining is frequently 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 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, ISO 19119].

To facilitate service chaining, some services support defining and executing chains of services. Also, some Processing Service interfaces are designed to support 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. This approach separates the flow of control from the flow of data.

4.2.1.6 Service Communication

Communication between clients and services, and between services, uses only open non-proprietary 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 SOAP. Specific operations 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.

4.2.1.7 Service Interfaces

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. One server can implement multiple service interfaces whenever useful.

The OGC web service interfaces are usually stateless, so session information is not passed between a client and server. Clients retain any needed interface state between operations.

The OGC web service interfaces share common parts whenever practical, allowing those parts to be specified and implemented only once. For example, all OWSs have a mandatory 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.

Standard XML-based data encoding formats and languages are used in many server-to-client and client-to-server data transfers. The formats and languages specified include (but are not limited to) those listed in Table 4.4. In these formats and languages and elsewhere, the geographic data and service concepts are closely based on the ISO 191XX series of standards.

Table 4.4 Some standardized encoding formats and languages

4.2.1.8 Server Implementation

Servers and client implementations are not constrained except for supporting the specified 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.

All OWS services and clients are implemented by available standards-based Commercial Off The Shelf (COTS) software. This commercial software can sometimes be used without requiring major software development, or can be adapted to specific needs with limited software development. Software may be developed as proprietary or open source code.

4.3 OWS Testbeds

Earth observation interoperability requirements are a critical underpinning of OWS standards. These standards are usually developed and refined in the OGC Interoperability Program’s testbeds, pilot projects, and interoperability experiments. Sponsoring organizations fund these activities in which participating organizations develop specifications and software components, test interoperability with other components, and produce documentation. Documents include Discussion Papers, Engineering Reports, Best Practices, Specification Profiles, Change Requests, and Reference Models as well as draft standards. These are reviewed and approved (approval is often contingent upon submitters completing specific improvements) by the Technical Committee and Management Committee.

Most new OWS standards have come from the OWS testbeds – OWS-1, OWS-2, OWS-3, OWS-4, OWS-5, and OWS-6. Other testbeds have been sponsored by organizations or teams of organizations with specific interoperability needs or particular needs for a separate initiative. (A full list of current and past initiatives is available online http://www.opengeospatial.org/projects.)

In a testbed, the design, development and testing of components and specifications is typically conducted over a 6-month period preceded by a call for sponsors, a request for quotations and a participant selection process. A testbed usually concludes with a demonstration of interoperability involving a variety of commercial and prototype products and components in a realistic scenario. Most of the demonstrations have been captured in multimedia, and videos are available on the OGC website. OWS-1 and OWS-2 results are available on the website.

4.3.1 OWS-3

The OWS-3 initiative, in 2006, was organized around the following threads:

• 1. Common Architecture: The Common Architecture (CA) thread addressed issues, infrastructure and requirements necessary to integrate services implemented using OGC specifications into an operational Web Service enterprise. For OWS-3, the emphasis of the Common Architecture thread was on capturing best practices, extending the scope and capabilities of catalog services, and maturing OWS workflow.

• 2. Sensor Web Enablement (SWE): The Sensor Web Enablement (SWE) thread matured the existing set of SWE work items to enable the federation of sensors, platforms and management infrastructure into a coordinated sensor enterprise. This enterprise will enable the discovery and tasking of sensors as well as the delivery of sensor measurements regardless of sensor type and controlling organization.

• 3. Geo-Decision Support Services (GeoDSS): Geo-Decision Support Services (GeoDSS) built on the Information Interoperability work from OWS-2 to explore ways to tailor geographic information for different information communities. GeoDSS refined and extended the OGC Portrayal encoding and services through application to symbology encodings from two communities. In addition, GeoDSS developed the new capability of a Geo-Video Service (GVS). Finally, GeoDSS explored extensions/enhancements to the underlying OGC services to address a greater extent of emergency response scenarios.

• 4. Open Location Services (OpenLS): OpenGIS Location Services (OpenLS) comprise an open platform for position determination and location-based applications targeting mobile terminals.

• 5. Geo-Digital Rights Management (GeoDRM): The Geospatial Digital Rights Management (GeoDRM) thread in OWS-3 was the first step of adding digital rights protocols to the existing OWS architecture. The GeoDRM thread in OWS-3 extended the “click-through” licensing concept for web sites to geospatial data services. In particular, click-through licensing techniques were developed for the Web Map Service and Web Feature Service.

4.3.2 OWS-4

The OGC Web Services, Phase 4 (OWS-4) Testbed (June to December 2006) had 11 sponsoring organizations who responded to a January 2006 Call for Sponsors and defined a set of requirements. Seventy two (72) organizations who responded to an April 2006 Request for Quotations (RFQ) and Call for Participation (CFP) participated in some aspect of OWS-4. Fifty nine (59) components were implemented and deployed in interoperability testing in seven threads:

• 1. Sensor Web Enablement (SWE): The implementation and testing of SWE components reached a level of maturity sufficient to support the adoption of SWE specifications as standards by the OGC Technical Committee at the level of Version 1.0, i.e., O&M, TML, SensorML, SOS, SPS.

• 2. Geo Processing Workflow (GPW): A baseline approach for OWS Workflow using BPEL was established and demonstrated in several scenarios. Several processing services were defined as profiles of the Web Processing Service, e.g., Topology Quality Assessment Service, Model Output Processing Service.

• 3. Geo-Decision Support (GeoDSS): An open-source GML Client Application was developed and released as part of the OWS-4 DVD and through Source Forge. While this application is limited in GIS functionality it provides geospatial browsing, supporting the visual integration of GML with WMS and WFS services. Guidance for mapping domain models to the ebRIM (electronic business Registry Information Model) model for CSW was developed. Progress was made on techniques for developing GML Application Schemas. The OWS approach to Portrayal was refined including separation of the SLD specification into two parts: Symbology Encoding (SE) and SLD profile of WMS. Also clearly identified were the two services of Feature Portrayal Service (FPS) and the Integrated SLD-WMS. The WCS was extended to accommodate a response using JPIP (JPEG 2000 Interactive Protocol) image streaming, i.e., geo-enabling JPIP. The WCS parameters for requesting geospatial coverages provided an enhancement to the efficiency of JPIP data transfer.

• 4. An initial architecture profile of OGC Web Services for the National System for Geospatial-Intelligence (NSG) was developed.

• 5. Geo-Digital Rights Management (GeoDRM): Implementation of GeoDRM and Security components consistent with the OGC GeoDRM Abstract Specification was accomplished. The implemented architecture was captured in an Engineering Viewpoint architecture.

• 6. CAD / GIS / BIM (CGB): OWS-4 was the first web services implementation of a set of CAD-GIS-BIM requirements; initial discovery and access to CGB data was achieved by extending existing OWS specifications. An architecture for further development was defined.

• 7. OGC Location Services (OpenLS)

• 8. Compliance Testing (CITE): Compliance Test Scripts and Reference Implementations for SDI 1.0 were developed, as well as a new open source test engine (the TEAM engine)

At the OWS-4 demonstration, held at an Emergency Operations Center (EOC) in the New York/New Jersey metropolitan area, high level disaster managers from state, federal and local agencies saw live Web-based information systems being used to find, access and integrate diverse geospatial resources, just as these managers’ systems might be used in a real disaster. The information flowed from many different data sources, most using commercially available off-the-shelf software implementing OGC standards. In the demo, the following capabilities were shown:

• The OGC’s SWE Standards made it possible to find and control online sensors as diverse as radiation counters, anemometers, security cameras, and NASA imaging satellites. An operator in the demo accessed NASA’s Earth Observation-1 (EO-1) satellite ground system, instructing the satellite through an open interface to provide images of the New York/New Jersey area over the next several days. The acquisition request was accepted by the EO-1 planning systems and the image was acquired on December 8th during the OWS-4 demonstration. NASA satellites are in fact being fitted with the open SWE specifications to make such use possible.

• Commercial weather data sources and weather forecasts were also accessed. Using information from these and from wind sensors, a radioactivity dispersion plume was calculated, and within less than 1 h managers at the EOC had begun a fictional evacuation of areas that had been or would be impacted.

• Service chaining for decision support made it possible to, in effect, create “macros” or packaged sets of services hosted on multiple remote servers, in order to streamline the delivery of information to decision makers.

• Proposed geospatial digital rights management (GeoDRM) standards enabled emergency access to sources of data that were either private and proprietary or public but under legal constraints.

• Geosemantics applied to metadata in catalogs played a role in discovering the best available data and services.

• Multi-lingual data and map services allowed participants with different native languages to collaborate more effectively.

• Building information models (BIM) integrated computer-aided design (CAD) data with geospatial data and text made it possible to review and compare different buildings to choose the one most suitable for an emergency field hospital.

4.3.3 OWS-5

OGC Web Services, Phase 5 (OWS-5) Testbed (July 2007 to April 2008): 7 Sponsoring organizations who responded to a Call for Sponsors defined the requirements and developed the scenario for OWS-5. Thirty five 35 organizations who responded to a May 2007 Request for Quotations (RFQ) and Call for Participation (CFP) participated. Fifty two (52) components were implemented and deployed in five threads:

• 1. Sensor Web Enablement (SWE): Participants demonstrated implementation and integration of IEEE-1451 TIM (Transducer Interface Module), NCAP (Network Capable Application Processor) and STWS (Smart Transducer Web Services) components and refined the integration of IEEE-1451 sensors into the SOS framework. A BPEL script was developed for SWE GeoReferenceable workflow. This workflow established a standardized means to allow the user to interactively access a subset of pixels from a coverage service stored in the compressed JPEG2000 and preserve the image relationship with the associated “sensor” model parameters such that precise geopositioning capabilities could be realized in a dynamic, interactive and networked environment. The OGC specifications used in this scenario included: JPIP enabled WCS-T 1.1, CS/W, WPS, SPS, SAS, and SOS.

• 2. Geo Processing Workflow (GPW): Participants developed SOAP and WSDL interfaces for four foundation services: WMS, WFS-T, WCS-T, and WPS, allowing these services to be integrated into industry standard service chaining tools. Service Implementations for WFS-T, WCS-T, WMS and WPS were deployed to demonstrate SOAP and WSDL binding patterns. They developed a BPEL script for SWE GeoReferenceable workflow. This workflow establishes a standardized means to allow the user to interactively access a subset pixels from a coverage service stored in the compressed JPEG2000 and preserve the image relationship with the associated sensor model parameters such that precise geopositioning capabilities can be realized in a dynamic, interactive and networked environment. The OGC specifications used in this scenario included: JPIP-enabled WCS-T 1.1, CS/W, WPS, SPS, SAS, and SOS.

• 3. Geo-Decision Support (GeoDSS): Participants demonstrated feasibility of the draft Web Coverage Processing Service (WCPS) standard by implementing use cases (sensor time-series, oceanography, remote sensing imagery.) A Conflation workflow process and BPEL script were designed and implemented to demonstrate service chaining and workflow, web processing services, and service interoperability using a variety of OGC service standards. There was successful design, implementation. and testing of data view models harvested in a catalog. The UML (Unified Modeling Language)-GML Application Schema (UGAS) tool was enhanced to include: utilization of OCL constraints; schema generation based on ISO/TS 19139 encoding rules; and capability to integrate existing XML grammars based on XML attributes.

• 4. Agile Geography: Participants specified how KML could be output from a geospatial database using three existing standards: WMS for the overall information request, WFS Filter for the query, and SLD for styling rules. They completed a proposal for a new OGC standard for Federated Geo-synchronization and developed an abstract core WFS module and a series of other modules that instantiate Web-based data provisioning.

• 5. Compliance Testing (CITE): The Compliance and Interoperability Test and Evaluation (CITE) thread developed 6 compliance test suites

4.3.4 OWS-6

The OGC Web Services, Phase 6 (OWS-6) Testbed Call for Sponsors took place in July 2008. The testbed was just getting underway at the time of this writing and was due to complete in April 2009. The five planned threads are:

• 1. Sensor Web Enablement (SWE): OWS-6 will focus on integrating the SWE interfaces and encodings into cross-thread scenarios and workflows to demonstrate the ability of SWE specifications to support operational needs. Emphasis will be on:

  • Integrating CCSI-Enabled CBRN Sensors into the SWE Environment

  • Harmonizing SWE-related information models: SensorML, GML, UncertML, MathML

  • Applying GeoRM, Trusted Services, and security models in SWE environment

  • Events-based architecture including WNS

• 2. Geo Processing Workflow (GPW): This GPW thread aims to build on the progress of previous testbeds with particular emphasis on service security issues. To satisfy mission-critical goals, the architecture must ensure authenticity, integrity, quality and confidentiality of services and information. The following task areas have been identified:

  • Asynchronous Workflow and Web Services Security

  • Data Security for OGC web services

  • Data Accessibility

  • WPS Profiles - Conflation; and Grid processing

  • GML Application Schema Development and ShapeChange Enhancements

• 3. Aeronautical Information Management (AIM): The Aviation Information Management (AIM) subtask is a new thread within OWS to develop and demonstrate the use of the Aeronautical Information Exchange Model (AIXM) in an OGC Web Services environment. This thread will focus on evaluating and advancing AIXM features in a realistic trans-Atlantic aviation scenario, devising and prototyping a Web Services Architecture for providing valuable aeronautical information directly to flight decks, Electronic Flight Bags (EFB) and hand-held devices (such as PDAs and Blackberries) while the airplane is at the gate or en-route to its destination. AIXM was developed by the Federal Aviation Administration (FAA) and Eurocontrol as a global standard for the representation and exchange of aeronautical information, enabling the transition to a net-centric, global aeronautical management capability. It uses the ISO 19100 modeling framework and has two major components: a conceptual model presented in the form of an UML class model and a data encoding specification which was developed using the OGC Geography Markup Language (GML). Both have been tailored for the representation of aeronautical objects, especially the temporality feature that allows for time-dependent changes affecting AIXM features. The OWS-6 AIM thread shall perform tasks in the following areas:

  • Use and enhancement of Web Feature Service and Filter Encoding specifications in support of AIXM features and 4-dimensional flight trajectory queries,

  • Prototype of Aviation client for retrieval and seamless visualization of AIXM, Weather and other aviation-related data, emphasizing time and spatial filtering in order to present just the right information into a given user context anytime, anywhere,

  • Architecture of the standards-based mechanism to notify users of changes to user-selected aeronautical information.

• 4. Decision Support Services (DSS): Decision Support Services involving geospatial and temporal information has been a recurring thread in OWS testbeds. This thread focuses on presenting and interacting with data obtained from the sensor web and geoprocessing workflows to support analysis and decision making. The focus for DSS in OWS-6 builds on portrayal, WMS Tiling, and integrated client work from OWS-4, with additional work on 3D visualization and integration of the built environment and landscape. This thread will encompass:

  • ISO 19117 and OGC SLD Portrayal

  • 3D Portrayal of GML with Fly-through

  • Hosting CityGML data with WFS

  • Outdoor and indoor 3D route and tracking services

  • WMS performance (tiling)

  • Integrated Client for multiple OWS services

• 5. Compliance and Interoperability Test and Evaluation (CITE): The major geospatial industry consumers require verifiable proof of compliance with OGC specifications in order to reach the desirable outcome of interoperability. The CITE threads in previous OWS projects have made significant progress towards having a complete suite of compliance tests for this baseline of interfaces. A major focus of OWS-6 CITE will be in clearly documenting the approach to defining Abstract Test Suites. In addition, OWS-6 will expand the usability of the existing OGC compliance tests by “tailoring” these tests for specific schema profiles and/or data.

4.4 Conclusion

Existing OGC specifications are widely implemented in Earth observation software and the larger geospatial technology marketplace. The specifications for the Information Management Tier (WMS, WFS, WCS, CSW) are mature with multiple implementations. Emphasis in the OGC development activities is focused on developing Processing Services and best practices for service chaining, e.g., workflow. The OWS architecture is also the basis for the recently approved OGC Sensor Web Enablement (SWE) set of standards for accessing any type of sensor as a web service. Approaches for managing digital rights in the OWS environment are being developed, which will help overcome many of the institutional and commercial obstacles to data sharing and market growth. Concepts are under development for applying the OWS architecture and services in a mass market environment, which puts technically sophisticated services in the hands of non-technical users and opens up a much larger market for geospatial technology and data providers. This progress depends on cooperation among technology users and competing technology providers, and OGC’s function is to foster and manage such cooperation.