Re: [service-orientated-architecture] REST and SOA
- Mark Baker wrote:
>On Mon, Dec 29, 2003 at 10:00:25AM -0700, David Forslund wrote:Please define "uniform" Who is one to know of a text string is a
>>>I disagree, for reasons that may be clear from my response to Mark. I
>>>think of REST as a very restrictive form of SOA in which services not
>>>only have to be accessible remotely via message invocation, atomic
>>>(i.e., they do one thing requested by the message and don't refer to
>>>any implicit state from a previous operation), relatively
>>>coarse-grained, etc. .... but also must be identified by URIs, be
>>>conceived as the manipulation of the state of a resource, use a highly
>>>constrained set of operations to perform that manipulation.
>>I think this is so generic as to be not useful in the definition of a
>>SOA. There actually
>>is no real constraint in the REST interface, since anything can be sent
>No, it cannot. I think REST is quite clear about this; that interface
>semantics must be uniform. Anything not uniform, like "getStockQuote",
>or "purchaseBook", is not RESTful.
"method" or a data element?
Where am I to find out what is being sent over the wire?
Michael Champion wrote:
Sure, but remember Netscape had an CORBA orb embedded in it for quite awhile which would have enabled
On Jan 3, 2004, at 2:17 PM, David Forslund wrote: I'll let someone more familiar with CORBA respond to the assertion that Prescod is "wrong" about it.
I understand the "simplicity" of the REST approach, but I believe its benefits are primarily illusory, largely because it is being used in rather simple transaction systems ("get me a catalog of a certain type", e.g.). It isn't clear how well it will work in a system with considerable more complexity.
I guess I agree, but would put it the other way around: If you have a simple transaction system a la Amazon (or Google, which is even simpler) leveraging the Web as REST does makes an awful lot of sense; CORBA isn't really even an option for such things (after all, the whole *point* is to make them universally accessible over the Internet),
people to use CORBA "over the web". M$, however, refused to do the same in its browser. Thus
this option, freely available, was cut off from the general community. The complexity of REST and CORBA
in this scenario are pretty much the same. A couple of calls pretty much provides what is needed.
I agree that SOAP/WSDL are overkill (for this problem) and much more complicated than REST (or CORBA for that matter).
SOAP/WSDL appear to be overkill, and the customers have voted with their feet against them. If you have considerably more complexity, well, the burden of proof is on the RESTifarians to show us real working examples, IMHO. People building real, cross-platform, complex enterprise transaction systems seem to be voting with their feet for the Web services stuff in my experience, and apparently for CORBA in David Forslund's.
I should say that my "vote" for CORBA is based on the fact that it works and works well in a very large
number of complex commercial environments, not simply based on my experience with it.
One issue that I've seen looking at REST, is that I can't get automatic code generation from a specification to
the mapping between a REST interface to an OO implementation of the code behind it. I can do this with CORBA
and seem to be able to do this with Web Services (The MindElectric's GLUE comes to mind).
This may not matter for a simple application, but is very important for a complex application to reduce the amount
of human-generated errors. I would be interested in work that takes a REST approach and lets one build
the basic structure of an application automatically (machine generated). This requires some way of formally
expressing the "interface" which can be translated by software.
I think that is a good attitude, with the possible caveat that without adopted standards, we will continue
Sorry if this sounds wishy-washy (I know I irritate partisans of both sides!), but as I put it in my Web Services Architecture summary at XML 2003, I think the choice of one approach or another to implementing SOAs is a matter for case-by-case engineering tradeoff analysis, not for general ideological debate.
to have chaos in distributed computing.