Doug, anticipating my response,
promptly responds.
He brings up the “identification vs. location” issue, which I agree
remains a point of contention between many (though the Web wizards
are all in agreement on this one, at least 8-). But we’ve
already been there,
and I don’t think I could explain my position much better than I did there. So
I’ll concede that point for the moment so we can move on to an aspect of
architecture which I feel is more important in determining the degree of
loose coupling; late binding.
REST uses late binding, as REST clients are developed to a system-wide
abstraction; the resource. As an example of what this enables, a RESTful client
can get data from any RESTful server. SOA cannot do this; a constrained
interface is required for this, whether in a RESTful manner or not.
FWIW, in these terms, one can look at REST as the natural evolution
of SOAs on the Internet; SOA + late binding => REST
Another excellent piece
by Adam, this time on disconnected operation. He writes;
This model is profoundly different than the normal browser.
Well, different, but not “profoundly” different. But keep in mind that REST
is more than just what is seen through a browser. It’s simply data transfer.
What he describes there is an architecture which sounds an awful lot like
REST and “REST + additional constraints” to me, where the additional constraints
would include things like resources are queues.
Obviously not all resources would be queues in the system Adam describes, which is why
you’d need two styles; vanilla REST, as well as REST with the queue constraint.
Doug Kaye writes,
in reference to a list which places REST before SOA;
It also tracks the scales of tight-to-loose coupling and the availability of supporting technologies.
(suggesting that SOA is more loosely coupled than REST)
I don’t have much of a feel about how loosely coupled “Orchestration” is, but
I do know that REST based services are more loosely coupled than SOAs. Whether
or not you believe that REST can be used for machine-to-machine communications,
I think it’s pretty clear that REST uses late binding, while SOAs do not, since
REST constrains the interface. Amoungst other things, this means that any agent
can exchange data with any service, past, present, or future. You can’t do that
with SOA, because you don’t know the interface that future services might use to
exchange data.
An interesting question would be, what would a late bound version of an SOA
look like? And wouldn’t this be worth pursuing?