Cascading and Brokering in Geospatial SOA

Cascading WMS from USGS, ESRI, NASA on the "Cloud" - using Gaia 3.4, CubeWerx Cascading WMS and Web Services Security software

Open-Geospatial Web Services were developed around the concepts that 1) it's easier to reuse existing services than deploy new ones, 2) if you want to reuse services interoperability is needed, and 3) if you have interoperability you can broker many services to create applications. The advantage is simple - it's much easier to reuse and chain existing services than deploy new ones.

In this environment the ability to "cascade" services is vital. What does it mean to cascade? The OGC standards say a Cascading Web Map Server (WMS) is a WMS that behaves like a client of other WMSs, and behaves like a WMS to other clients. For example, a Cascading WMS can aggregate the contents of several distinct map servers into one service. Furthermore, a Cascading WMS can perform additional functions such as output format conversion, coordinate transformation and role-based access control on behalf of other servers. The cascading feature of the WMS specification is optional but for those vendors like CubeWerx who support it there are a lot of things to consider and which make the cascading WMS and WFS very valuable.

A Cascading WMS works like this - an SDI Broker defines the layer resources accessible by the WMS as part of the standard metadata requirements of a WMS server - but can also refer to a WMS service as a remote resource. When he/she runs a Get Capabilities request against the Cascading WMS the data resources defined in the remote WMS are included with a cascading indicator (cascaded attribute). The nesting level is recorded in the cascaded attribute in the Capabilities XML document and, given that the remote service could also be another cascading service which could in turn refer to local and remote data services, cascading could theoretically continue indefinitely. So the originating cascading WMS server can access all the layers defined in the local services as well as the remote or cascaded layers via the cascading WMS.

When a Get Map request (OGC WMS operation) is processed by the WMS server, the requests are sent to the appropriate resource such that any request for a cascaded data layer is handed off to the remote WMS to respond. To the remote WMS server, this is a just another WMS request which it fulfills and returns the resultant map image back to the calling WMS server. This requires no additional provisions at the standard WMS level to support a cascaded request. The Cascading WMS will then make sure that the returned image is compatible with its client request and return it to the client integrated with all the other data layers.

One of the really nice features from vendors like CubeWerx is that they support all OGC WMS versions. This means their Cascading WMS can cascade to ANY version of an OGC WMS server - and they correctly translate the incoming request to the version of the cascaded OGC WMS server. This allows a client tool to not worry about the WMS version of the cascaded servers.

Cascading opens up many other efficiencies like reusing remote services and applying a security layer - and a Cascading WMS can be deployed on a "Cloud" server so it's fully techno-buzzword compliant. But what users see is simple - you point an application like Gaia 3.4 at just one service and get the benefit of many.

- Jeff