Quality of Service

OK, so today we're going to be thinking about the way you can look at Quality of Service, as regards Web Services. This is a pretty cool area, and can get kinda complex when you start chaining together services, too, so it's worth thinking about.

Right, when we're looking at Web Services (WS), we don't necessarily just mean the easy ones like OpenStreetMap, where you just send out your command (where's the nearest coffee-shop?*)to their server, and get back a bunch of data in return. Nope. What we're looking at is the wider world of WS, where instead of sending a command to OpenStreetMap, we could look up a directory of different services, and see that perhaps a whole selection them offer searches for nearby coffee shops. Brilliant! We have a choice! So, how do we choose which service to query?

This is where quality of service comes in. In that directory service, all those WS that are listed will have given their quality of service attributes - how much the service costs, how quickly the service will guarantee to respond to your request, any security standards they can support for data transfer, and so on.

This is all well and good and relatively simple - you just pick the service that matches any criteria you have, and if it's unavailable, you choose another one. Simple. But it gets more complicated, as I said, when you start chaining services together. Let's say that you want to know how much the coffee at the nearest coffee chop costs, and we'll imagine that there are webservices which (a) locate the nearest coffee shop and (b) keep track of the prices at coffee shops. Let's even get carried away and imagine that there are several services which do both of them.

Now we have to look at both services put together - the service composition - and total up the quality of service for both of them. So if we want the reply to come back within 10 seconds, we'll need to make sure to pick two services whose response times, when added together, come in below 10 seconds.

This is still pretty simple stuff, but let's now imagine a situation where this service composition contains ten or more services, all chained together to form one super-service. Each of those ten services that make it up might have ten or twenty different options to choose from out there on the web, which means that we end up with a variability in the overall quality of service that, frankly, makes your head spin.

In the algorithm I'm writing to try and help pick out the best combination of services to chain together, I'm going to have to come up with some kind of method to measure quality of service in some kind of meaningful way.

To start with, I'm going to be limiting the QoS factors I'm dealing with to the basic few: cost, response time and service availability. This gives a nice balance between positive and negative factors, but limits the complexity to something that should be easy enough to handle. So the next step is to try and decide how to store these. Obviously an array will give nice fast data access, but is it flexible enough to survive in the real world, where we might end up dealing with hundreds of QoS factors? Time for another thinking cap, I guess!

* I'm trying to cut down on my coffee intake. Does it show? ;-)