Back to the Transverse Technology Use Cases list. Brief descriptionRole and purpose: this use case describes the conditions and steps to test services for conformance and QoS.Testing may occur before or after services are registered. Preliminary condition is that the future Service Provider has developed his service following the appropriate standards and has made the service accessible through an URL via Internet. The Service Provider shall access first to the GEOSS Registry, searching the appropriate testing tools, then he makes access to the test environment, follows the instructions and test his service obtaining results from the tool. The access to the tool can be performed through the GEOSS Registry or through the WG Test Facility Proxy page for testing endpoint where optionally the test tool can be registered. In the following use case only the access through the GEOSS Registry is shown. Basic flow of events
|
|
Title |
Test Services |
|
|
Overview |
Service Provider wants to test its service (eg. a WMS service). It can access to the GEOSS Registry, searching the proper Test tool and going on the site associated to the test tool to test its service. |
|
|
Actors and Interfaces |
|
|
|
Initial Status and preconditions |
|
|
|
Evolution (basic flow steps) |
STEP 1: The Service Provider puts its service to be tested on a reachable and available server
STEP 2: The Service Provider access to the GEOSS Registry
STEP 3: Search of a Test tool in GEOSS Registry according to the proposed criteria (eg. WMS service) STEP 4: Browse the details of the Test tool on the result page STEP 5/6/7: (Optional) The Service Provider follows the link to reads the instructions to use the test tool STEP 8/9: (Optional, if necessary and not yet done) The Service Provider registers itself in the Test Environment as Service Provider STEP 10/11: The Service Provider follows the link to access to the Test tool from the GEOSS Registry STEP 12: (Optional, if necessary) The Service Provider logs into the Test Environment STEP 13/14: The Service Provider fills the WMS Form for the GetCapabilities request, providing the URL of the service to be tested and the other necessary parameters
STEP 15/16: The Test Tool sends an XML WMS GetCapabilities request to the service to be tested and receive back an XML response STEP 17/18: The Test Tool performs the analysis of the answer and provides results to the Service Provider STEP 19: (Optional) In case of problems on immature standards the Service Provider provides feedback to the Test Facility responsible STEP 20/21: (Optional) After a problem analysis the Test Facility responsible provides feedback to the GEOSS relevant Standard Authorities about immature standards |
|
|
Post Condition |
The following pieces of information about a Test must be available from the geosspilot2 testreports page :
|
Alternative flows of events
| Title | Access the test tool from the Test Facility Working Group Proxy view Endpoint |
| Overview |
Service
Provider already knows which tool it wants to use. In this case it has
the faculty to access directly the tool from the Test Facility Working
Group Proxy view Endpoint. |
| Actors and Interfaces |
|
|
Initial Status and preconditions |
|
|
Evolution (basic flow steps) |
STEP 1: as before
STEP 2: The Service Provider access to the Test Facility Working Group Proxy view Endpoint
STEP 3: The Service Provider identifies a Test Tool from the list proposed in the Proxyview Endpoint STEP 4: as before STEP 5/6/7: as before STEP 8/9: as before STEP 10/11: The Service Provider follows the link to access to the Test tool |
|
Post Condition |
The Service Provider has accessed the tool from the Test Facility Working Group Proxy view Endpoint. |