ICE/SOA vs REST

[kwaclaw]

Interesting article by Steve Vinoski, "REST Eye for the SOA Guy":
http://dsonline.computer.org/portal/...l=article.xsl&

Its the first time someone explained REST in a way that made me understand that it does have strengths compared to SOA (Steve means SOA *not* in the SOAP/WS-* sense, but in a sense that includes CORBA/ICE).

Mostly, it is the "uniform interface constraint" that appeals to me, since it allows for easier interface evolution, as only the data contract is affected.

I think he is also right when he says that often a typical SOA interface (RPC style) can reveal too much about the underlying implementation, therefore violating the principle of separating interface from implementation.

Nevertheless, even with REST, the actual communication problems that arise from interface evolution are not eliminated, but only shifted from the interface contract to the data contract. The advantage of REST - it seems to me - is that it is easier to deal with that issue in the data contract alone.

Have I been convinced too easily?

Karl

[ganzuoni]

Interesting article by Steve Vinoski, "REST Eye for the SOA Guy":
http://dsonline.computer.org/portal/...l=article.xsl&

Its the first time someone explained REST in a way that made me understand that it does have strengths compared to SOA (Steve means SOA *not* in the SOAP/WS-* sense, but in a sense that includes CORBA/ICE).

Well, not bad, but, IMHO, some parts are incredibly obvious, like this one:
....
SOA encourages several critical development practices, but the most important ones are establishing and adhering to service contracts and splitting interface from implementation.
...
I never heard anyone saying the contrary.
And this:
...
A service contract tells its consumers what the service expects as input data when invoked and what form of data it returns. Splitting interface from implementation means that the service’s consumers know only the contract and remain blissfully ignorant of its implementation details
...
This can be true even for 'C' functions.
The following is a mistery to me:
..
A significant advantage of the uniform interface constraint lies in the area of scalability.
..
Some comment on this:
...
Interestingly, some of the architects and developers I know who work on large SOA systems (such as those in telecommunications and financial enterprises) figured out the uniform interface constraint on their own, without ever hearing of REST.
...
I am not sure if it was an article from Martin Fowler, Grady Booch or someone else, reporting a code inspection experience on an object oriented system.
The number of classes look adequate wrt the complexity, but they all contained
one method: doIt()

Mostly, it is the "uniform interface constraint" that appeals to me, since it allows for easier interface evolution, as only the data contract is affected.

I think he is also right when he says that often a typical SOA interface (RPC style) can reveal too much about the underlying implementation, therefore violating the principle of separating interface from implementation.

I think that is not a problem of style but rather of the stylist

Nevertheless, even with REST, the actual communication problems that arise from interface evolution are not eliminated, but only shifted from the interface contract to the data contract. The advantage of REST - it seems to me - is that it is easier to deal with that issue in the data contract alone.

I think that for POC and simple cases dealing with simple "entities" (I don't
want to call them objects, services or components) REST can really speed-up
development.
I am afraid that when things get more "real", you will face with the same problems.
I am not really sure you have the right weapon

Have I been convinced too easily?

Karl

[kwaclaw]

The following is a mistery to me:
..
A significant advantage of the uniform interface constraint lies in the area of scalability.
..
Some comment on this:
...
Interestingly, some of the architects and developers I know who work on large SOA systems (such as those in telecommunications and financial enterprises) figured out the uniform interface constraint on their own, without ever hearing of REST.
...
I am not sure if it was an article from Martin Fowler, Grady Booch or someone else, reporting a code inspection experience on an object oriented system.
The number of classes look adequate wrt the complexity, but they all contained
one method: doIt()

Well, the way I understood it - if there is a uniform interface, the client can communicate even if the data contract was changed. It can then potentially use some dynamic smarts (or even a new dynamically downloaded plugin) to make sense of the changed data.

With the interface itself changing, the client would not be able to do anything until updated with the appropriate knowledge. Of course, this could be done by providing some special (again uniform) discovery interface to learn about the interface changes (sort of like IDispatch in COM/DCOM).

Seems with a large scale deployment, uniform interfaces have some advantage there.

Karl