Service Google

By: on December 6, 2005

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.

### Ranking

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.

FacebookTwitterGoogle+

3 Comments

  1. matthias says:

    A nice example of type-based search is [Hoogle](http://www-users.cs.york.ac.uk/~ndm/hoogle/), which alllows you to find functions in the Haskell API that match a particular type signature. Obviously this is a long way from a general Service Google, but it’s impressive nevertheless.

  2. francis says:

    Are service-providers expected to publish their source code? If so, I suspect that we’re more likely to see everyone agreeing to one ontology than everyone agreeing to publish the sources to their services.

    Also, wouldn’t type inference reveal more information than most providers would want to publish? A specification can be viewed as an abstraction of an implementation; a behavioural type derived from the implementation might be too concrete.

    Also, what if I were to ask google to “find me all services with a SQL-injection vulnerability”?

  3. matthias says:

    > Are service-providers expected to publish their source code? If so, I suspect that we’re more likely to see everyone agreeing to one ontology than everyone agreeing to publish the sources to their services.

    Google doesn’t index all content. It only indexes what is publically available. Having your content indexed by Google and other public search engines is one incentive for making it public. Also, making the content publically visible doesn’t imply that one has to sign over all rights over it. There is no difference between traditional content and code in this respect, so if Google works for the former then a Service Google should work for the latter.

    Furthermore, there is a place for a Service Google inside organisations, just as there is for the current Google.

    Finally, only the *indexer* needs to have access to the content. Hence one could come up with some scheme by which only it can see it, and the content remains hidden from the public at large.

    > Also, wouldn’t type inference reveal more information than most providers would want to publish? A specification can be viewed as an abstraction of an implementation; a behavioural type derived from the implementation might be too concrete.

    There is nothing stopping service providers from publishing specifications. Service Google will happily index those too.

    > Also, what if I were to ask google to “find me all services with a SQL-injection vulnerability”?

    Being able to do that would be marvellous, don’t you think?

Post a comment

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>