A good comment from Chui Tey over in Steve’s comments.
Interfaces defining many kinds of messages imposes unncessary [sic] coupling, when what is required is for documents to be thrown over the other side of the wall, leaving the other party to decide what order to parse and process the document.
So in the spirit of the Zero/One/Infinity rule, what is he saying? Is it a) services should not have interfaces, b) services should share a common interface, or c) services should have whatever interface they want?
Dave Orchard posted a pretty well argued treatise on what is, essentially, a defense of the right for Web services to not adopt the stateless interaction and more importantly, the resource identification constraints which are so important to the Web.
As I explained in my response, if Dave was arguing that Joe Architect should have the right to not follow these constraints (which of course, he already does), he’d have my full support, since in the small, that is often necessary.
However, in the large – when taking into account the value of participating in the information space that is the Web, and of leveraging rather than fighting its network effects – I cannot support him in his attempts to standardize known bad practice, even for non-Web systems.
I won’t bore you with yet another drawn-out description of “why”, since I think I’ve made that clear in the past; the Web is what Web services are trying to be, so why fight it?
But RPC is important, no matter what format is used, because it allows choices
In allows choices by rejecting an architectural constraint which has been the foundational constraint of large scale, loosely coupled, distributed systems, since there’s been large scale, loosely coupled, distributed systems … for about 40 years now.
you can replace a component with another one
Ah, substitutability. Note that you can only replace an XML-RPC component with another one that has the same interface, at least if interoperability is important. Compare that to a system where every component has the same interface, where you can submit a document to any component for processing. Now that’s what I call substitutability.
Not that I agree with everything James has to say about SOA, but he makes a good point about a couple of techniques/constraints commonly used in large scale systems;
Statelessness and idempotence are techniques that have been around for years (both appear, for example, in the design of NFS from 20 years ago) are usually considered key components of SOA architectures.
He’s absolutely right. Note how REST requires the former, and HTTP provides the latter. This is in contrast to Web services where idempotence isn’t core, and statelessness is explicitly eschewed (by more than one spec).
Very telling, I suggest.