Tag Archives: soa

REST is pro-contract

So that whole “contract thang” has popped up again in the echo chamber. I’m going to pick on Steve Jones a little (more 8-), specifically something he says in his latest piece;

Where I do disagree though is whether this is a good or a bad thing to have these camps. Now I’m clearly biased as I’m on the contract side […]

Hold it! Let’s make sure we’re having the right conversation here. It’s not “pro contract” vs. “anti contract”, it’s simply “many contracts” vs “one contract”.

Resume!

New voices

I’m absolutely thrilled that Tim has finally grokked REST. AFAIK, he’s the first die-hard Web services type with a strong public persona to realize REST’s (and the Web’s, of course) benefits over WS/SOA/RPC. Bravo, Tim!

I’ve long thought that what was needed in this discussion was new perspectives on the relationship between REST and WS/RPC/etc… that would permit the message to reach more people. Tim’s ably doing his part along those lines with his followup posts. I would never have thought to describe things this way.

So, who’s next?

That human-targetted argument again

I wanted to expand a little on my dismissal of Sanjiva’s argument that “The Web is necessarily human centric”.

Sanjiva, in his support for – and authorship of – WSDL, presumably wants to permit developers to publish their own service-specific interfaces, such as ones supporting methods like the canonical “getStockQuote”, or even “getRealtimeStockQuote”. And I’m certain he’d claim that these are very much machine-facing interfaces, since that’s supposed to be the whole point of Web services. So far so good?

So why is a system built around GET suddenly not machine facing? I’ve said before that the one thing that most distinguishes SOA and REST is the uniform interface of the latter; it says , in part, that the more general the operation, the more reusable the interface. In other words, using the example above, getStockQuote is more reusable than getRealtimeStockQuote. Moreover, GET is more reusable than getStockQuote.

By following that logic – that more general means more human-targetted – then one can only conclude that the methods most suited for machine-targetting will be the most specific ones. So never mind getRealtimeStockQuote, we’d need getRealtimeStockQuoteForGOOGonNASDAQ.

Of course, that’s silly. So is the argument that the Web is only for humans. I hope (hah! 8-) that this finally puts that argument to rest (pun intended).

Questionable content

I tried to post this comment to Jorgen’s latest blog entry;

Perhaps if SOA were defined, we’d be able to tell you whether there’s a problem that had a decent SOA based solution! 8-O

All I know is that REST is an *improvement* upon SOA for multi-agency, data-oriented systems. The big win is that REST far better separates interface from implementation than SOA, and is therefore far more loosely coupled.

Unfortunately I received this error in response;

Your comment was denied for questionable content.

8-)

Dave Orchard takes another crack at defining SOA

Personally, I like his previous attempt far, far better. Why go for loosey-goosey principles – few of which, AFAICT, are testable – when we all know that constraints define architectural styles? Come on Dave, give people the information they need to be able to say “That is SOA”, and “That isn’t”.

A couple of years ago, Dave pleaded for technical arguments in the REST vs. SOA debate. I’d urge him now to do the same. As an example, perhaps he can explain, in technical terms, how he is able to defend a principle such as “Software should be as loosely coupled as possible to the interface” as well as service-specific interfaces. As I’ve pointed out, those two goals are at direct odds with each other because service specific interfaces fail to separate interface from implementation, and we all know that loose coupling is gained only by separating concerns.

REST, misrepresented

Sanjiva gave a talk at Google on Web services, which also touched on REST. Unfortunately there’s a lot of misinformation in there about REST, including a statement to the effect of “If you want to sign your message, you can’t use REST” (I don’t think I’m taking that out of context), plus a slide (@ 25:00) that includes the following;

REST vs. WS-* is the wrong battle
- WS-* is used to create Service Oriented Architecture
- REST is used to create Resource Oriented Architecture

When taken together with some other comments, it appears as though Sanjiva sees REST as an alias for HTTP (or perhaps HTTP/URI), which it isn’t of course. He’s certainly entitled to his own beliefs, but I think he would do well to spend a couple of days with his nose buried deep in Roy’s dissertation… and not just chapter 5. Until that happens, I’d personally avoid trying to make conclusions about how these different approaches may or may not relate, or may or may not compete.

The unsittable fence

Mark Little explains why he’s a proud fence sitter in the REST vs. WS-* debate;

I’ve never believed in the one-size fits all argument; REST has simplicity/manageability to offer in certain circumstances and WS-* works better in others. As far as distributed internet-based computing is concerned, REST is probably closer to Mac OS X and that makes WS-* the Windows. For what people want to do today I think REST is at the sweet spot I mentioned earlier. But as application requirements get more complex, WS-* takes over. We shouldn’t lose sight of the fact that they can compliment each other: it need not be a case of eiher one or the other.

Ah yes, more of the inaccurate trucks vs cars-style comparisons. In truth, SOA no more complements REST than a musket complements an M4, or an Edsel complements a BMW. REST is an improvement upon SOA in the general case, plain and simple.

Snake oil on the Web

Jorgen tries to convince us that Web 2.0 Needs WS-*. But he’s going to have do a lot better than arguments like this;

And, as if to underscore why I don’t see the REST / POX / AJAX “religion” achieving too much traction among enterprises, try explaining the phrase “The Web is All About Relinquishing Control” to any corporate security manager!

Well, if Jorgen had read what Alex was saying about relinquishing control, he might not think that such an insurmountable task;

This is possible because no one owns the web, and consequently no one can control it. The web is everyone’s property, and everyone is welcome to join in. It’s the world of sharing. The need for control has been relinquished, and it is left to the participants to sort their discrepancies out. The web as a medium and as a technology is not going to offer any assistance in that regard.

In other words, relinquishing control is largely about adopting public standards in lieu of pursuing proprietary interests, in particular the public Web standards that make inter-agency document-oriented integration (relatively) simple to achieve. If you are responsible for securing an Intranet, it should be your first and primary consideration to trust messages which are based on publicly vetted agreements, like most Web messages, and similarly, to distrust those messages whose complete semantics are not publicly vetted, like most SOAP messages.