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?
Dave points to his
original piece
on
XML-RPC
back in 1998. Item number 30 includes some, erm,
interesting claims;
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.
Hmm, is Omri more like Nero, the naked emperor, or both? 8-)
(
link) [
del.icio.us/distobj]
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.
“This is still interop-in-the-small… I think even CORBA was beyond this point five years ago.” Yup. You’d think reinvention would be faster, no?
(
link) [
del.icio.us/distobj]
Ted follows up on the discussion over at Steve Vinoski’s blog that I forgot to point to. I hate having the last word, because I don’t know if that means that Michi got my point or not.
(
link) [
del.icio.us/distobj]