Chaining GIS Web Services
This paper explores three basic alternatives for efficient and practical dialogs that occur
among the chained services as well as between the services and the calling client. As
expected, a number of issues surround the design and implementation of such dialogs.
The section below highlights the subset of these issues that are considered to be the most
relevant to the specific case of chaining GIS Web Services. This subset covers
- The degree of transparency to the client of the service chaining complexities and the
amount of coordination required by the client to construct, execute and manage
service chains.
- The alternatives for keeping track and relaying to the client the sources of geographic
data used in a service chain and the transformations that were applied to the data
along the chain. Keeping track of metadata is particularly important in the case of
GIS as typical GIS data users often cannot use that data unless they have some
information about its resolution, ortho-rectification parameters, remote sensing origin,
etc.
- The alternatives for handling and reporting errors along a chain to the client. Precise
error reporting is critical when one or more services along a chain break or return an
exception.
Chaining Alternatives
This section discusses three basic alternatives for chaining GIS Web Services: clientcoordinated,
static and mediated chaining. Each option is examined with respect to the
issues presented above.
Client-Coordinated Service Chaining
In the simplest case, service chaining is fully transparent to the client: The client defines
and controls the order of execution of individual services in a chain. Although the client
does not necessarily have to know a priori the syntax of each service request (see section
on WSDL), this type of chaining still requires the client to know about the types of
services needed for a particular operation. Using this a-priori knowledge of the types of
services needed, the client can access one ore more registries to find service instances to
use for a certain request (Nebert 1999).
A practical way for a client to chain various services is achieved by having the client
directly embed, in the input of one service, a request to the following service. The
quintessential example (shown below) is that of a WMS which symbolizes feature or
coverage data stored in a remote WFS or WCS using an SLD specified by a URL. The
request to the underlying WFS is embedded within the WMS request.
http://yourfavoritesite.com/WMS?
VERSION=1.0.5&
REQUEST=GetMap&
SRS=EPSG%3A4326&
BBOX=0.0,0.0,1.0,1.0&
SLD=
http%3A%2F%2Fmyclientsite.com%2FmySLD.xml&
WIDTH=400&
HEIGHT=400&
FORMAT=PNG&
REMOTE_OWS_TYPE=WFS&
REMOTE_OWS_URL=
http%3A%2F%2Fanothersite.com%2FWFS%3F
While nesting calls may simplify some of the client’s coordination responsibilities, it
nevertheless introduces complexities in the areas of error and metadata propagation as
well as the client’s ability to control certain details. Consider for example the case of the
WFS service issuing an exception in response to an erroneous call from the client. This
exception will in turn trigger the WMS to signal an "invalid input" exception. With larger
chains, a domino effect ensues, as the same problem occurs over the remaining links of a
chain. Consequently, a mechanism is needed to embed the source and/or cause of an
exception as delivered to a client. One alternative mechanism consists of allowing a
service to automatically forward a received exception input, as is, to the next service in
the chain; while appending to the forwarded exception any of the service's own error
messages. In this context, representing exceptions in XML is particularly useful as it
makes it easier for services to detect and add to incoming exceptions.
Moreover, consider the issue of an unexpected delay occurrence in one of the chain’s
services. The serial nature of the chain implies that the delay propagates through the
chain, and all the way to the client. In the scenario where the client directly accesses each
service, the client can abort the operation if a specified time-out period for a service
expires. The client may then find a substitute for the timed-out service. However, with
nested calls, a global time-out, controlled by the client and communicated to every
service, is needed. At any point, if a service takes longer than this global time-out, it
aborts and returns an appropriate exception to the preceding service in the chain.
In order to hide some of the complexity of service chaining, many service providers
provide complementary services as one aggregate service.
