At the recent [Architects Summit](http://www.looselycoupled.com/blog/lc00aa00127.html) there was a brief discussion on the idea of a *Service Google*, i.e. the ability to search for software components that offer a service with a particular behaviour. How might such a Service Google work?
### Google vs the Semantic Web
The [Semantic Web](http://www.semanticweb.org/) folks will tell you that we should define [ontologies](http://www.w3.org/TR/owl-features/) for service descriptions, and add meta data to our services that describes their behaviour in terms of these ontologies. That is *not* how Google works, and it is [the wrong way to go](http://www.shirky.com/writings/ontology_overrated.html), requiring a-priori agreement on how to express service behaviour and not permitting any change in the notion of service behaviour over time.
A Service Google that works like the current Google would not require any up-front specification of service semantics. Instead all notion of meaning is deferred to indexing & search time. There is one important difference though: for the Service Google to be of any use for *automated* service discovery and binding the meaning must be *exact* and *verifiable*.
Note that ontologies do not have anything to offer us here. Firstly, they are not grounded in anything that could be called exact or precise. Secondly, they *impose* meaning on an artefact without providing any mechanism to verify that the artefact does in fact comply with that meaning.
So, if ontologies aren’t the answer, what is?
### Behavioural Types
Behavioural types are mathematically precise definitions of the behaviour of services, including SLA, performance characteristics, cost, security etc, with proofs that the actual services do indeed exhibit that behaviour. Searching for behaviourally typed services is done by formulating queries as expressions in some suitable logic. Matching is the satisfaction relation and hence exact. Verification is type checking.
Types *express* the meaning of an artefact, rather than imposing it. Following Google’s lead, we ideally would want to avoid any explicit, upfront specification of types. Instead types should be *inferred* by the indexer. Unfortunately, type inference limits the expressiveness of
types and, to a degree, the artefacts (i.e. code) – a minor tweak to a programming language can break type inference.
Thus there is a real challenge here for the research community: devising behavioural type systems that capture interesting properties and are inferable for a large class of practical programs. The beauty of the inference approach is that we can evolve the notion of type, just like Google can evolve its indexing & search algorithms.
Another challenge for a Service Google based on behavioural types is that a large part of the value Google is delivering is *ranking*. A prerequiste of that, in Google’s case, is the inexact nature of its
indexing/search. The satisfaction relation, otoh, is exact. As a result a Service Google would only find exact matches, i.e. services that exactly meet the criteria we have specified. We can, of course,
relax the criteria, but then we’d just get more hits – we do not get any ranking of them. What is the Service Google equivalent of page rank? Is it perhaps the notion of simulation, i.e. the more other
matching services a service can simulate the higher its rank?
An alternative is to come up with a distance measure of behaviour, i.e. the more one service behaves like another the closer it is to that service. This allows us to keep our queries precise and let the
search engine worry about digging up non-exact matches and ranking them. The problem then is how to bind to service obtained in this way, since it matches our criteria only closely but not exactly.