If you’ve heard me discuss Internet scale systems, you’ve certainly
heard me talk about the necessity of interface constraints
for those systems. What hit home with me today was that this term is
probably unfamiliar to a lot of folks, so it could be of value to
attempt to relate it to other things that they might be more familiar
What other names does “interface constraint” go by? “Component
model” is one you might recognize. The value of component models like
derives entirely from the generality of the common interface they define.
In the case of Beans, that interface isn’t complete (it’s more akin to a
CRUD interface) but it remains useful.
Hmm, I wonder what a complete distributed component framework
might look like? 8-)
for clarification of my
about how, IMO, REST proponents generally like SOAP and dislike SOA. He writes;
I consider myself a REST convert, to the extent I think I understand it and its incarnation in HTTP. Though I don’t understand the position above. Is there even a concrete definition of SOA with which to make this statement?
I thought SOA was a fairly innocuous term, being so vaguely defined that an SOA could be built using REST and HTTP.
“innocuous”? I wouldn’t say that. I think it’s actively harmful as a name for an
architectural style. As I see it, “SOA” means different things to different people. As such,
it’s almost entirely useless since it does nothing to constrain how
one might go about building distributed systems. That’s why I don’t like it.
It’s for the same reason that I wouldn’t recommend the
null architectural style
as a guide from which to design
an architecture; all REST and SOA based architectures are instances of the null
style too! 8-)
I was flabbergasted to discover that I was the only subscriber to
The Now Economy on
If you’re interested in a weblog that can discuss
mesh networks in one post, and
pasture management soon thereafter,
and just generally cover the gambit of what decentralization and instant
(modulo latency, of course 8-) gratification might mean to business in
the coming years and decades, you should be subscribed.
are the brains behind
and are both now at
Update; it seems Bloglines has a bad URI comparison
algorithm, since I heard from somebody else that they see 9
subscribers, yet I still only see 3. This jives with two other
things I’ve observed about the service; that it recommends feeds I’m
already subscribed to, and that it doesn’t permit publication of URIs
ending with “/” (which could very well explain all these problems, I
According to Michael Curry,
Forrester has a
report on REST vs. SOAP
which concludes saying basically that SOAP is a better long-term bet.
First of all, the debate isn’t REST vs SOAP, it’s REST vs. SOA. SOAP can
be used in the context of many architectural styles, and the SOAP spec
itself says basically nothing about which should be used; though it does
have explicit support for RPC and REST (by virtue of some design decisions
made regarding the HTTP binding, thanks to yours truly). Also, Forrester’s
claim that REST proponents rag on SOAP is backwards; we like SOAP, mostly.
We just don’t like SOA.
Also, apparently the principle argument against REST is
that it lacks standards support. Seriously?! Ever heard
of URIs and
HTTP? You know,
two of the most wildly successful standards in the history of
distributed computing? How one can compare WS-* with 100s of millions
of deployed and currently-interoperable servers and clients, and then
conclude that the latter suffers from a lack of standards
support, boggles my mind.
Michael also adds his own critique;
Randy makes some good points on the standards issue that I failed to bring up. He doesn’t bring up the fact that REST breaks the MVC paradigm, however.
Who knew that MVC was a benchmark by which large scale distributed systems
are evaluated? Back to the drawing board for me! 8-)
Omri Gazitt has a
Web/REST gestalt moment
and doesn’t even realize it. In talking about how
might integrate with
WS-Transfer, he writes;
In order to “dereference” the MetadataReference EPR, you may issue a “Get” message (which is defined in WS-MetadataExchange), but logically this is exactly the same operation as the WS-Transfer Get operation. Now it all starts to hang together…
Erm, yah, it does, doesn’t it? Of course, the Web has been getting
things to hang together in exactly that manner (modulo s/EPR/URI, s/Get/GET)
since day one.
Progress, in a regressive kinda way. I don’t know whether to jump for joy, or cry. 8-/
I did it, I converted from the
blosxom combo to
yesterday. A tiny awk script converted my blog list to OPML, and
that was that. So far, so good, though
to crash when the list of entries gets large.
I also wish that browsing the entries didn’t automatically mark them as
all-read (side-effects on GET = bad!); a simple “done” button would
be far better, I think.
I made my
Further to my
I have a question that I’d like to ask
or any other Web services proponent that wants to chime in;
what’s the simplest task that cannot be coordinated using a uniform interface?
Perhaps such a Q&A will help explain the 97% figure I mentioned.
Here’s a neat idea from Mike
about how to bridge the divide between WS/SOA advocates, and Web folks;
What I’d really like to see here is the application of a well-known conflict management technique in which each side has to state the other side’s position, to the other’s satisfaction, before discussing the disagreement.
So, why don’t the Web standards suffice for computer/computer interactions? People have been talking past each other on this topic for years now. How about it? Maybe Mark Baker could re-state his understanding of why Don Box thinks they don’t … and vice versa … before wrapping this permathread around the blogosphere one more time.
Hang on there … I thought my task was to attempt to state
Don’s position, no? You seem to have done an adequate job at that when you
stated “Don Box thinks they don’t suffice”, which I agree with. Though I
could probably take a stab at explaining why Don believes this, it
would really just be conjecture, and doesn’t seem to be required of me by
And just to clarify, I don’t think “sufficiency” is necessarily the right test;
on occasion, even me – yes, yours truly, the REST fanatic – has used non-uniform
semantics. I just happen to think that uniform semantics suffice for, oh, say,
97% of stuff you might need to do when integrating applications over the Internet
using document based messaging. “uniform” is the ultimate in generality, after all.