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 java.net
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:
-
The operation to perform, represented by
TLcdOWSOperation
-
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 java.net.HttpURLConnection
,
is the map of request properties that can be associated with a connection. See the method getRequestProperties
in java.net.HttpURLConnection
.
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 java.net.URI
.