2004/10/21
Add your comment
2004/10/19
2004/10/18
Congratulations to the Web on its first Full Standard! You don’t see those every day.
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2004/10/14
What’s the difference between these two loosely coupled, distributed document exchange scenarios?
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 barrier.
I have the utmost respect for Don Box 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 he writes;
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, and Roy Fielding taught us (for software architecture, at least – others such as Christopher Alexander 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 Dave’s latest 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 spotted 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!
2004/10/13
A fascinating question. Almost as fascinating as why anyone would want to know! 8-)
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]