Run-time composition of services: like a swan?

Web Services are a fairly amazing concept, when I think about it. You have a service, running on a server somewhere in the world, that accepts requests from other places and then returns information to them. This could be as simple as getting a request for the temperature in a particular city and returning it, or as complex as being asked to search a database for, say, hospitals near a given location, and return their details as an XML document.

Other people can then build onto that, combining different web services in various orders to get more and more detailed and crazy applications. This is what makes mobile development so exciting - there are so many possibilities open to creative designers that the sky isn't even the limit anymore.

What really begins to shake things up, though, is when there's more than one service offering the same results. There are likely to be a few factors separating them - one might cost more, yet one might be more reliable, and a third might return results more quickly.

So we start creating systems that look at the alternatives available when they query these services, in order to optimise the return of results - and that's not an easy task. And then we have to consider what happens when a particular service is unavailable - do we just wait and hope that it sorts itself out sooner rather than later, or do we try to recompose the rest of the service and attempt to get round the problem.

It's only as I dig deeper and deeper into the bowels of service composition that I realise how staggering a task it is - so many variables and so much frantic querying, estimating and processing, and all of this has to be hidden from the end user. It ends up like a swan: perfectly serene and stable on the surface, but flailing around like a mad thing underneath!