The transport layer is a representation of the communication infrastructure used to access an OGC Web Service (OWS). It defines the underlying mechanism that is used by an OWS client, like a WFS or WMS client, to connect with a service. As such, an OWS client can make abstraction of the communication mechanism and delegate all communication requests to the transport layer.

The transport layer is represented by the interface ILcdOWSTransport in the package com.luciad.ogc.ows.model. The interface implementations determine which communication protocols are supported, and how communication is performed. A default implementation exists with support for HTPP GET and HTTP POST, based upon the package available in the JDK. You can create other implementations that support different HTTP protocols, or make use of other libraries to implement the communication.

The following sections describe the responsibilities of the transport layer.

Performing requests

An essential capability of the transport layer is the ability to perform requests. For this purpose, ILcdOWSTransport defines the method performRequest, which either returns an input stream containing the result or throws a TLcdOWSTransportException when an error occurs in the transport layer.

To fully define a request, two parameters are needed:

  1. The operation to perform, represented by TLcdOWSOperation

  2. The request, represented by ILcdOWSRequest

Defining an operation

The operation to perform, TLcdOWSOperation, is identified by a unique name, and should correspond to an operation supported by the OGC Web Service, GetFeature for example. This information is listed in the capabilities of an OGC Web Service.

For the WFS version 1.0.0 and the WMS, you can find the operation information in the 'Capability/Request' section, and in the 'OperationsMetadata' section for WFS version 1.1.0 and 2.0.0. Programmatically, you can find the list of operations in the TLcdOWSOperationsMetadata object retrieved from the WFS/WMS capabilities. Use the method getOperationsMetadata in TLcdWFSCapabilities or ALcdOGCWMSCapabilities. These classes provide the necessary methods to iterate and retrieve the supported operations.

For the WCS, you can find the operation information in the 'Capability/Request' section for version 1.0.0. Programmatically, you can find the list of operations in the TLcdWCSOperationsMetadata object retrieved from the WCS capabilities, through the method getOperationsMetadata in TLcdWCSCapabilities. This class provides the necessary methods to iterate and retrieve the supported WCS operations.

Next to a name that uniquely identifies the operation, a TLcdOWSOperation contains additional metadata about the operation. This includes:

  • A list of one or more Distributed Computing Platforms or DCPs (see Distributed Computing Platform) supported for the operation. For example, an operation can be defined that only supports HTTP GET requests, but no HTTP POST or other HTTP request methods.

  • A list of parameters associated with the operation. For example, a parameter defining the supported output formats.

  • A list of constraints. For example, a constraint defining a maximum width and height for a requested map.

Defining a request

The request to send to the OGC Web Service, ILcdOWSRequest, fully defines its representation and encoding. A request can be encoded as a key-value pair (KVP) map, as an XML fragment or as a REST URI. Implementations can decide which encoding is supported, by implementing the methods getKVPEncoding, getXMLEncoding or getRestEncoding. If an encoding is not supported, null must be returned.

A transport layer implementation is responsible to retrieve an encoding and send it to the OGC Web Service. To be able to associate transport-specific parameters with a request, the method getTransportData is defined. Because there is no restriction possible at this level as to how these transport parameters should look like, the return type is java.lang.Object. The actual type of object and the data contained in it depends on the transport layer (ILcdOWSTransport) that is used, and should be documented there. An example in the case of a HTTP transport mechanism based upon, is the map of request properties that can be associated with a connection. See the method getRequestProperties in

Distributed Computing Platform

To model a communication platform, the OGC defines the concept of a DCP or Distributed Computing Platform. A DCP represents an infrastructure that allows objects to interoperate across computer networks, hardware platforms, operating systems and programming languages. At present, only the HTTP DCP is defined, with the possibility to have GET and POST request methods.

As discussed in the previous section, an operation itself defines one or more supported DCPs that are to be used when sending requests. The transport layer should use one of these as communication infrastructure. However, no operation information is available initially, since that would require a GetCapabilities request. In order to define a DCP for an operation when the service metadata is still unknown, a transport layer can be asked to create a DCP, through the method createDCP.

URI compatibility

To refer to an OGC Web Service, a Uniform Resource Identifier or URI reference is used. A transport layer implementation must decide which URI references are supported, by implementing the method isCompatibleURI. Given a URI reference, a boolean is returned indicating whether it is supported or not. For example, a transport layer that only accepts URI references that use the HTTP communication protocol, shall only return true if the URI scheme corresponds to http. For more information, see getScheme in