Please provide concrete user-centric use case descriptions to be used for defining the scope of the OWS QoS WG. Create a new wiki page for each use case description by editing this page and adding a use case title to the list in CamelCase notation.

Submitted use case descriptions

Use cases, user stores or workflows to consider for the OWS QoS WG:

• ServiceMonitoringSetup (Spatineo)
• ServiceLoadTestingSetup (Spatineo)
• ServiceMonitoringExecution (Meteorological Service of Canada)
• ServiceMonitoringReporting (Meteorological Service of Canada)
• UserAlerting (Ordnance Survey, GB)
• SDIStatusDashboard (Spatineo)
• GeoPortalServiceReliability
• ViewAWebMapService (NRCan)
• CreateAWebMapService (NRCan)
• CORSEnableAServer (NRCan)
• ServiceDescription (AdviceGEO)

Identified problem statements

Base on the use cases above, the following problem statements have been identified:

• It's unnecessarily complicated for the data/service providers' to enable service level monitoring of their OGC Web Services in monitoring software: declared service level criteria should only have to configured once for each service, and communicated in a machine readable, standardized format to any external client applications.
• It's very difficult for SDI level monitoring tools, sitiation maps or health dashboard to automatically identify of the monitored services are behaving as expected, because different services and operations may have very different response times in a normal situation.
• There is no standardized format or method for declaring the operating hours and scheduled maintenance or other expected downtime for an OGC Web Service instance. While 24/7/365 operation should be the goal in most cases, communicating the limitations for a service in this sense to the end users would improve the user experience.
• There is not standardized format or method for retrieving the operational status of a particular OGC Web Service instance. Declaring a service as "operative", "test", "experimental" etc. would clarify the general user expectation about the service (as long as these stata are well-defined and understandable).
• Crawlers, search engines, geoportals etc. interested in providing QoS information of the catalogued OGC Web Services may create biased availability results or unwanted strain to the monitored services by automatically enabling service availability monitoring for these services using operations and/or request parameters which are not typical for the service. It should be possible for the service to provide a list of operations and boundary conditions for request parameters used for creating representative requests for the particular service.
• The current InspireSDSMetadataForQoS within the ISO 19119/19139 service metadata as currently required by the European INSPIRE Directive is unnecessarily complicated and stretches the meaning of the DQ_ConceptualConsistency element: there should be a more straight-forward solution to provide this data.
• There should be a set of commonly agreed and well-defined metrics for measuring the quality of service or service level of OGC Web Services to enable comparisons both for the same service instance over time and between different service instances. Different testing tools should be able to to calculate similar, if not identical results for these metrics.

-- IlkkaRinne - 06 Jul 2016