For the last few weeks I’ve been trying to figure out how to write up an idea that’s been bugging me. I think it’s an interesting idea, but until I can actually write it up I won’t be sure. So today I just decided to blurt it out into the blog, relatively unformed, certainly unfinished, definitely half-baked.
There seems to be an expectation today that distributed computing means web services – or that it will do, just as soon as the various standard bodies and corsortia get their acts together. I’m unconvinced. I see three ways – three axes, if you like – in which there are strong arguments for widely differing and incompatible positions; when you combine these, you get a 3D design space which is much bigger than what web services aficionados would claim. (And just to be even-handed, it’s also way beyond what we can do naturally with things like Jini and RMI.)
I’m just going to describe these three axes, without attempting much justification. Zealots can argue all they want….
- The first axis is interface typing. At one extreme, a service can only accept a message of a single type, encoded in one way; if the request doesn’t match exactly, no interaction is possible. (Think CORBA or RMI.) At the other extreme, a service will accept any type of message, although of course it may have to reply “Sorry, I don’t understand”.
- The second axis is control. At one extreme, the behaviour of the client and the service is rigidly specified, and the binding between the two is explicitly controlled and predictable. (Choreography languages, workflows, message exchange patterns, protocol FSMs come to mind.) At the other extreme, components are substantially autonomous; a client can search for a service at run time, a service can choose to delegate a request to a third party, and parties can renegotiate their interaction patterns on the fly.
- The third axis is synchronicity. At one extreme is the traditional synchronous request-response style, which is directly derived from the procedure call paradigm. The service is essentially passive; indeed we usually draw this interaction with a single thread of control running from client to server. There are other synchronous interaction patterns, typically described by state machines. At the other end of the spectrum, messages may be sent between the parties without temporal constraints. Partners may repeat messages, “interrupt” each other, or even “change the subject”. (I don’t want to get into the definition of [a]synchronous right now – that’s a whole blog piece on its own. Let me just say that it’s about the pattern, not the implementation technique; I’m not interested in dependency on a transport connection or blocking i/o.)
To summarise, we have:
Interface typing, from strongly typed to untyped
Control, from choreographed to autonomous
Synchronicity, from synchronous to asynchronous
Now strongly typed, choreographed, synchronous is very familiar: it’s the classic RPC style. Untyped, choreographed, synchronous is what we find in the WWW today. At the other extreme, untyped, autonomous, asynchronous corresponds to the Holy Grail of the agents and semantic web community; it’s also a pretty good description of human beings, which should come as no surprise.
What I find interesting is that I can think of really compelling use cases for both ends (and some middles) of each of these axes. One size will certainly not fit all. And in some cases we want to have our cake and eat it too:
- On control: I want the elements in my distributed system to be substantially autonomous and self-organizing, to improve scalability and avoid single points of failure. On the other hand, I want to be able to define policies that will influence the self-organization, and to have ways of observing and measuring what’s going on.
- On typing: I want the safety and efficiencies that arise from working with predefined types with efficient encodings. On the other hand, I’d like to be able to refactor my distributed system by introducing generic facades for brokering without having to teach my broker about every service type that it might have to support.
Anyway, that’s what I’ve been thinking about. Now to see if it makes any sense in the cold clear light of blog….