I enjoyed Matt Perry's post of ten favorite WMS services some months back, he is back today with a nice observation on (lack of) reliability. Many of the solutions proposed in the comments focus on the service aspect of the problem ...

• data replication
• tacking status for a quality of service estimate
• cache the results (ie tile schemes)
• and the ever present request for metadata

Some of these are very attractive - a tile cache helps reliability and performance for example. But something is askew with these approaches ... the problem of service availability needs to be recognized and handled by those effected by it - the clients.

Client Solution One: Use more WMS Servers

One of the the things I noticed when meeting up with GeoTango (and most commercial offerings) is that they offer WMS support, but never in isolation. When setting up their "basemap" layer they will make use of several WMS services, often switching based on availability and zoom level. This is not something I am doing currently - much to my regret during a few demos.

This solution of ganging up on WMS Servers also provides a "lazy" solution to the Quality of Service "metadata" question. Rather then track service performance brute force the problem. Make two requests of different servers, the one that comes back first is the one you keep (and obviously performing better that day). While such an approach lacks finesse I can always appreciate the easy solution.

Client Solution Two: Sharing a Vision

As part of a recent project uDig was responsible for producing a common operational picture for disaster relief. Mr Perry's original point is well taken that WMS services are not reliably available for use this sort of situation.  But there is still an advantage to their use.  Because the various parties involved are making use of standards to collect a shared vision, when a service goes down one *can* make use of another.

In the OWS-3 project we automated the process of posting a "Open Web Service" context document to a wiki page for use with other applications. Needless to say that when most our services *did* go down (and they did I was mortified) we were able to quickly build up and publish and distribute a revised picture made up of working services.

While this may be a case of fighting a standard with another standard (almost the definition of an integration project), it was a great example of being able to quickly respond to service availability and demonstrate interoptibility under pressure and on the fly.

Building the a list of  "alternate" Open Web Services directly into the OWSContext document would provide us the best of both worlds.

Client Solution Three: Get Tricky

Recently, under a bit of collaboration pressure, the uDig catalog has started to get some attention.  We have finally defined an extension point by which you can "associate" data sources together. Being by definition a friendly application this extension points is friendly.xsd (yes I need to publish out the human readable version and write docs).

Implementations of this net.refractions.udig.catalog.friendly will make use of a couple kinds of "metadata":

• prior knowledge: simple pattern matching can account for GeoServer and MapSever WMSLayer to FeatureType association
• included metadta:  the description of a WMSLayer can point off to an external data URL, if we recognize that as a WFS link ...
• external metadata :given an interesting CSW2  profile to hit we can make use of associations tracked by a third party

At a implementation level this means that uDig now sees a small cluster of data resources that refer to the same content, allowing us to provide fail over as needed. While not as slick as tracking data that is "good enough" or "similar" the first steps are being taken.

What is Next?

So handling missing services is a well understood problem - that you always need to take into account. For something really difficult we need to look at the problem the other way around - how to handle a missing client!

The difficulty with having your client lose the Internet is the aspect of disaster relief that is most troubling for an open web services like WMS.  There are a couple of approaches to consider, although neither are available out of the box right now.

Stay tuned next time for the Low/No Bandwidth WFS story.