Surveying, Mapping and GIS

In a recent blog post, Matthew Perry (PerryGeo) lashed out, reaffirming his reluctance to rely on spatial web services such as WMS. Given that the NASA JPL WMS server was evidently down, many users and applications which consume the JPL WMS services also had issues and outages.

Yes, certainly any distributed system can face issues with downtime, or worse yet, with services going away altogether. How to remedy this?

As a service provider, one of the things that providers can work toward is providing the users with some information with which the users can make informed decisions. Essentially, manage their expectations. In some arenas, particularly where commercial services are offered, this should be in the form of a formalized Service Level Agreement (SLA), as part of the contract.

Here, the provider can outline the parameters of the content itself (such as FGDC-compliant metadata, including accuracy, source, et cetera), and beyond each iterative data snapshot, provide information on data latency (how current is the data?) and how often will it be refreshed? From an infrastructure standpoint, some hosting parameters should also be set forth, such as availability and reliability - to set the ground rules on what kind of downtime is acceptable or unacceptable, what kind of data throughput can be expected, and so on.

This becomes a bit more of a challenge in other arenas, such as agencies where external budgetary, legislative and other pressures may impact how well an organization can support published services.

But nonetheless, if an agency is forthcoming and up-front with these constraints at the outset, it can allow its' users and stakeholders to plan and prepare accordingly - by writing their code to handle outages appropriately, by utilizing alternative services, and so on. It also can lead toward consolidation, augmentation, replication of valued services as external users and stakeholders lobby for support (via legislative initiative and budget) for these services. An agency might not be able to provide formalized parameters as a commercial service would be expected to, however providing users with some basic insight will go a long way.

As organizations gradually move more and more toward Service Oriented Architecture, and as variegated Web Services appear right and left, and increasingly become available lights-out, via a simple URL, it becomes increasingly easy to connect to and consume these services - however that ease of access and use is ultimately bound to cause some disappointment, when things change down the road. I suggest and recommend SLAs and service metadata toward managing expectations.