What’s the difference between these two loosely coupled, distributed document
Scenario 1; an agent sending a document to another agent for processing.
Scenario 2; an agent invoking a “ProcessThisDocument” method, with the same
document as in #1 as an argument, on another agent.
Perhaps REST versus WS is really about private and public interfaces.
That’s exactly right, but exactly opposite of what he suggests; that
SOA is better for public interfaces, while REST is better for private.
REST’s uniform interface is superior for public interfaces because
its semantics are, well,
public. Each new
interface that is presented to a customer via SOAP/WSDL introduces a
barrier to entry because the customer has to learn the semantics of
that interface. Reusing a pervasively deployed one presents no such
I have the utmost respect for
and his work, but I have to wonder whether he’s pulling my chain, or just honestly
missing the point about the value of architectural constraints when
BTW, while I do claim that you can solve the majority of the world’s problems using an arbitrary handful of operations, I never claim that actually requiring (or even recommending) the world to do so is a good idea. It’s a wonderful thought experiment, but trying to evangelize that the world only requires a fixed number of verbs is quite odd.
How to put this respectfully, and without sounding condescending, hmm…
It’s tough, because as I see it, the fundamental theorem of software architecture
(and design in general, for that matter) is that only through constraint is
utility generated. This is what the work of luminaries such as
Dewayne Perry and Alex Wolf,
taught us (for software architecture, at least – others such as
have done it in other fields). How do you tell somebody like Don that, without getting
his knickers in a twist? I’m stumped. But it’s something that needs to be said, and
as my regular readers will know, it’s not a task I shy away from. 8-)
So IMO, there’s really two separate fundamental misunderstandings going on here,
and until the first – the role of constraints in design – is understood, the second
– the value of the uniform interface – can probably not be fully appreciated.
It seems that well-intentioned efforts such as
are trying to bridge the divide via incremental progress; if only we tweaked
this, or hacked that, we’d have something which could have the best of both
worlds! Sorry, but successful design just doesn’t happen like that. You need
the big picture, and to have the big picture you need to fully
understand the architecture of the two systems you’re trying to bridge.
P.S. Peter Lindberg
a James Fallen poem relevant to this topic;
Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, structures, though they bind,
Strangely liberate the mind.
Here’s a whopper of a bad start from the
latest from Dave Orchard;
We need another WS- spec […]
Heh, ok, low blow, but seriously, I think we need another
WS-spec like we need another Web. 8-) On to the beef …
WS-MetadataExchange is a perfect example of a spec that could use WS-Get. WS-Mex can’t really refer to WS-Transfer because there’s too many extra verbs. With WS-Get, WS-MEX could define GetMetadata and refer to WS-Get, and WS-Transfer could define Create/Update/Delete and refer to WS-Get. Cool.
Too many verbs, eh? The whole point of the uniform interface is that all
verbs are meaningful to all resources; “Put” makes perfect sense to metadata,
as does “Delete”. You’d presumably just get an authorization fault back if you
tried it in the context of the canonical application described in WS-MEX, but
let’s not preclude them from being used in the future please!
Happy World Standards Day!