Author: geoff

[This won’t make much sense unless you’ve read the original piece first….]
There are at least three issues packed up in this topic:

• An implementation issue, about whether the middleware even permits the sending or receiving of messages that do not conform precisely to a particular encoding and type/schema.
• The relationship between the type(s) of messages that can be exchanged and the description of the service.
• The extent to which message types are accessible, manipulable, and negotiable. Another way of thinking about it is how early or late message types are bound.

[DIGRESSION: For different distributed computing frameworks, we need to distinguish between feasibility (is it possible?) and idiom (is it a natural way of working within the framework?). For example, I can use XML to encode a rigid, unchanging message structure based on a well-known DTD; I can also use Java RMI to exchange opaque blobs that I interpret using some private mechanism; neither of these reflects the natural, idiomatic use of the technology.]
When we talk about “untyped”, we must recognize that it’s a relative term. Eventually there has to be a semantic match: the request must be expressed in a form that the service can interpret, and the response must be comprehensible to the requester. In that sense, the client and the server must structure their messages using mutually compatible formats, schemas, types, whatever.
Some mechanisms (e.g. CORBA, RMI or COM) bind the message type at design time. They depend on the use of software tools which typically generate client and server stub code that is, literally, incapable of handling messages that do not conform to this type. The client cannot generate invalid messages, and the service application logic never even sees invalid messages; they are rejected at a lower level. There are XML-based mechanisms that support this kind of model, using XML simply as an object serialization format.
In some cases it may be desirable to defer type binding to run time. This is particularly true if a service is identified by a persistent identifier (such as a URI) with no, or weak, type information. The most common example is a simple XML/HTTP web service: the client sends an XML message via an HTTP POST, and the service parses the message to determine whether it corresponds to a request that it can handle. In simple cases, the service only understands one type, and if the request doesn’t conform it will be rejected. Semantically this is similar to a classic RPC; however it is likely to be less efficient, and the failure modes are different. However we are not restricted to such simple cases. A service may, for example, delegate the request to another, more capable service; or it may invoke a translator to map the request into a form that it can understand. Such examples highlight an assumption that is not found in the RPC world: that type matching is not always a simple black-or-white, true-or-false proposition. This in turn requires [or is that too strong?] that the message be expressed in a language that supports some form of composition.
[DIGRESSION: I was trying to imagine how one might do this in Java. Given a blob that represented a serialized Java object, one could deserialize it into something like a Java bean that supported introspection so that for each property you could obtain both accessor methods and type information that could be used by a classloader. This feels convoluted, but maybe someone has done it.]
The interface type is also involved in service descriptions. In some cases, such as Jini, a service description is based on the annotated interface type: it makes no sense to talk about discovering a service independent of its type. At the other extreme, a service is simply a network addressable end-point, with no type information specified or even available. And then there’s WSDL, the web services definition language which is rich enough (or perhaps over-engineered enough) to describe a spectrum of service types. Although the specifications suggest that it can be dynamically interpreted at runtime, the complexity and (relative) rigidity of WSDL seems best-suited to design-time use. (Curiously, there is no standard way of retrieving the WSDL corresponding to a web service URI, although there are some common practices.)
So why is all this important? Well, as distributed systems scale in various ways – number of services, number of replicated component services, number of cross-domain service dependencies, lifetimes of services, and so forth – there is increasing interest in services that are relatively loosely coupled, with more flexible, less brittle, often asynchronous interactions. (Most of this is additive, not alternative: existing RPC-style services have advantages that are still important.) Maybe it’s a throwback to the Internet mantra of “be liberal in what you accept”, maybe it’s influenced by agent-style anthropomorphism, maybe it’s the result of overloading the simple HTTP protocol to do distributed computing, maybe it’s just a recognition of a world in which version skew is a way of life. In any case, one way in which we decouple these components is by deferring type binding, from design time to run time, and by making the type of a message accessible to the application rather than being hidden below the marshalling and serialization infrastructure.
Is this a dichotomy or a spectrum? I can certainly identify a number of styles which I can order in various ways, so it feels like more than just an XOR. But that’s all for now.

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….