Tuesday, January 29, 2008

Namespace-Time: Unifying the SOAP/WS-* and REST Models

I have always believed that the SOAP/WS-* and REST models were duals, and I have a model to explain the seeming dichotomy. I wrote about it earlier.

Now here's the picture to provide the kiloword equivalent.

7 comments:

JJ said...

Ganesh:

I really like your concept of namespace-time model, but I am not sure the dimensions align with REST and SOAP/W-*.

- Namespace is where QBE and Navigation occurs
- Time is where interactions and events occur

I think the merit of your diagram is to show that WS-* views the world more in terms of time, and REST sees it more in terms of namespaces.

But REST and WS-* are not orthogonal, they are more isomorphic, since you build the solutions with one or the other. One model should emerge over time (not a winner but a combination of their concepts because indeed solutions are build in the namespace-time universe).

JJ-

Mark said...

Ganesh - the very first sentence is wrong. It follows that the rest will be too.

REST is a more loosely coupled version of SOA than WS-* provides. WS-* fails to separate interface from implementation, while REST does. See my article at infoq.com from last year. That's all you need to know about why REST is an improvement on the model inherrent in WS-*.

JJ said...

Mark:

I am not sure I understand your point about "failing to separate interface from implementation". Don't you think that:
a) WSDL supports both foward and backward compatibility
b) it supports routing and transformation intermediaries

would be impossible to achieve if it failed to separate interface from implementation?

Remarkably, REST has major issues in support forward compatibility: a URI is a URI and the implementation is tightly coupled to the URI.

JJ-

Ganesh Prasad said...

JJ,

To answer your initial point, this is not a perfect model. It's my initial attempt to make sense of two seemingly different ways of looking at the world. Both systems talk about nouns and verbs. SOAP/WS-* has verbs (predominantly), and they are user-defined. The nouns are subordinate to the verbs. REST too has nouns and verbs, but it's hard to say which is subordinate to which. The verbs, being standardised, drop down to the level of the wire protocol itself.

In any case, the model is a play on Einstein's Space-Time. The axes may have to be modified, once I get a better understanding of what the core differences are.

I don't think REST is an improvement over SOAP/WS-*, as Mark rather curtly asserts. I read his article and it did nothing to convince me. Either I'm dense or he's a poor communicator. Or he's wrong.

Ganesh

JJ said...

Ganesh:

no, I think your namespace-time model is a very valid view of looking at the world. It really shows that you can't think in one aspect only. At least that's what I conclude from it.

This is a great way to show that to shed some light in the debate about the "uniform" interface.

As I say multiple times, folding the time dimension and all the code that goes with it behind the URI is IMHO a mistake, at least I don't see the benefits. Mark and a few others continue to make antiquated statement reflecting their poor understanding of what Web Services technologies are, but I don't think they anyone is paying attention.

JJ-

Mark said...

I wouldn't have believed that myself many years ago, but it's quite obvious now. Just ask yourself the question, if I change the implementation of a component from a stock quote service to a weather report, does the interface have to change? If yes, then prima facie you haven't decoupled interface from implementation, have you?

It's all right there in the article. If it doesn't convince though, then I reckon I'm a poor communicator. There's worse things one can be. But I'm certainly not wrong. I used to be, when I was using CORBA and thought that using IDL was doing that for me. Then I learned how to *really* separate interface and implementation.

Ganesh Prasad said...

Mark,

I don't know what to make of the requirement you have of holding the interface constant while changing the very nature of the service. That's a far more radical sort of decoupling you've got there, and I'm not sure how useful that is in practice.

I've posted on this topic separately, because I believe it could be an important area of difference between the two approaches (SOAP/WS-* and REST), but as far as I can see, they're two ways of doing the same thing, and they're both equally valid.

Have a look at this model and see if you agree.

Ganesh