Monitoring the Availability of Web Services

Many of the current Web Service repositories suffer from outdated data. We at seekda avoid this by regularly verifying the connectivity of all services in our repository. Additionally, our long term monitoring database allows us to provide you with a useful service ranking and helps you to pick the right service for your purpose.

Instead of showing you just the current status, we record and show the status for every single service from the time we found it. For example, take a look at the RuleReasoning service a research related service offered by University of Innsbruck, Austria.

Explaining all peculiarities of this service would exceed the scope of this post, but for those who are interested in, should take a look at: http://www.wsmo.org/wsml/wsml-syntax and http://tools.deri.org/wsml/rule-reasoner/ which explains the research conducted behind it. I chose this particular service as an example of many free and useful services, which can be found through seekda!, which do work, but just not all the time. So if you are interested in integrating them into your application, it is utterly important to have a failsafe in place.

Let’s have a look at services provided by a company, like the spell checker service offered by cdyne. It has an availability of more then 99% and basically failed only once since we have been tracking it. Our monitor facility might not replace a service level agreement, but it gives you a pretty good idea of what you can expect. Also you need to consider that we do our monitoring from a single network location, so it could be the case that a services could not be reached by our monitoring system, however still reachable from other network locations.

Some Technical Details

At present we verify if a service is up once a day. We do not only check if the server is reachable, but also if it correctly implements the SOAP protocol by triggering a SOAP fault (see our help section for more details). Resultantly, we have a fine-grained view that provides more information in comparison with a simple up/down confirmation:

The coloring of the lower bar in the graph indicates certain properties of the response during a particular availability check.

• invalid host: we have been unable to connect to the host either because we could not resolve the domain name or because the IP address specified was not a public one.
• connect error: we were unable to establish a connection to the server.
• connect timeout: we have been able to contact the server, however within 20 seconds we could not establish a connection.
• read error: we were able to connect the server, however for some reason we failed to read the response data.
• read timeout: the server took more then 20 seconds to send its response.
• forbidden: we have been unable to contact the server, either because the Web Service was password protected or it’s robots.txt settings disallowed availability checks.
• malformed response: the server did not respond according to the SOAP protocol specification. Please not that the service still might provide some functionality, but it is likely that there exists some problems – it is a common case that it returns a HTML error page.
• not found: the server responded with a 404 message indicating that the resource requested is not available.
• OK: We verified that the server correctly implements the SOAP protocol, however this does not mean that we have verified its actual functionality (such as a weather service).

A note on green – a service is available

One more thing on how to interpret the “OK” when we report it. You can imagine that we are not capable yet to check all 20 000 services if they are actually delivering what they promise. Take the example of the weather service that is published by deeptraining.com. It seems perfectly fine from a technical point of view, however from a functionality point of view it is pretty useless since it returns Sunny, Partly Cloudy, Rain, etc in a random fashion independent of the input string.

Another note on the times displayed

You probably wonder what all the lines mean in the diagram? We measure the time it takes for our monitoring system to establish a connection (light blue) and how long it takes until we have received the complete answer (dark blue). We are not sending any real request but a harmless one, which will already be disregarded on the SOAP protocol level, thus these times do not necessarily reflect how long an average request in your final application can take. Take a look at this OCR service which performs text recognition on a picture:

It has a pretty nice service connection and responds much faster then the average of all services (the two gray lines indicate the average across all services, the upper one is the average total response (~800ms) and the lower line (~180ms) is the connect time. Though I have not yet tested the text recognition service (it is actually free and requires only a quick sign-up to get user name and password), I imagine when doing the OCR on large images it will in fact take longer then 200 ms.

Second to considering the missing payload when interpreting the response times is network topology. Our network location is different from yours and thus you might have different results when doing your tests. Regardless, our values give you an idea of how well a particular service is connected.

The time slider

The last thing for this post: I want to mention this nice little slider below the image. Ever tried to move it? It allows you to select any sub-period in which a service was monitored and also to adjust the number of days displayed (it defaults to show the last 2 month).