Service Description for Discovery or Function?

One thought that occurred to me last week was that when people are looking to locate services we use a different method of describing their discovery than we do to describe their function. Thus while we may ask for a hairdressers, the reply will come back in terms of routes, colours and individuals and its by this association that we will find the actual hairdresser described.

This got me wondering as to whether a similar challenge exists with technical services, paticularly when numbers get large. Is there one description of service that defines its functionality, what WSDL and WS-* try and do (badly) and another that tells us how to find the "right" service? In the real world these elements are done to make discovery easier, thus someone is described not by what they are good at, but by their features as its fairly unlikely that in a room full of people you will spot the one "who knows all about Linux". With services there is a similar challenge, namely one of recommendation. If there are multiple similar services, either internal or external, how do you refer someone to the right one?

With services this description is liable to be part of the many documents that relate to the service ("its the payment service that uses the penguin example") this can even lead to services being used in ways that the original writers hadn't thought about ("There was a service about payment that talked about penguins, but it had a cracking currency converter on it"). Thus the ancillary descriptions help the service be discovered for another, and originally unintended, use.

This is why when you are looking at registries, or service repositories its vital that they should index not just the functional elements, but also the myriad of other information that relates to it. By increasing the information footprint of the service you increase the chance of there being some unique information that people can use to describe it to others. These "soft" information sources are also often the most valuable to people trying to re-use your service as they help provide much more context over the standard WSDL approach. They will include the business context, the technical context and the examples that you've used to demonstrate its use, its as important to find all of this information as it is to find the functional definition.