<< Statistics on Microsoft Internal IT | Home | Enterprise Architecture: Foundation of Execution >>

SOA and REST, the interoperability conundrum

Thursday, November 08, 2007 5:16 PM

Rich Seeley recently interviewed John Michelsen, chief scientist at iTKO Inc who said ...

"the service-oriented architecture (SOA) testing and governance provider, believes developers do not have to chose between Web-oriented architecture (WOA) based on a simple Representational State Transfer (REST) approach and SOA following the WS-* standards. "It's not an either/or question," he says in the following interview from Integration World 2007 this week in Orlando, Florida. However, he does argue that the advocates of WOA with REST have gone too far in simplification and advocates of SOA with the WS-* standards have gone to far in regulation. He believes both sides need to find a middle road that uses practical governance."

I 100% agree with this statement and couldn't have put it better myself ! Sense at last in this debate.

The only thing I would add is why not use both? Pick WS-* or REST in a certain situation on it's strength. One thing the IT industry has taught us and that is one size/type does not fit all. What are the options? Battling with the wrong standard to meet a principle or not? Frankly life is to short to aim for perfections when the standards obviously aren't, good old uncle pragmatism must play it's part if you want to keep your hair.

My advice would be that don't level the WS-* or REST to be the absolute physical replesentation of a layer of abstraction, have the interface sit on-top of abstration, this allows you choice in your communication interfaces, hey you could even have both!

However, there is a great deal of talk about REST but for my mind it is still to early doors to use this technique in anger unless the developers you have are keen and technically strong. Normal rank and file dev's aren't going to be interested in making their lives more complex just to support something that 'isn't quite here yet'. It's the old conundrum of, do you write production code using a BETA dev tool argument? Some developers will be up for that, others won't. Not to mention risk etc. So to my mind, let the those who want and can play with REST do so, I will watch the standard and use it when it is ready, and by that I mean pretty much mainstream.

Feedback

# re: SOA and REST, the interoperability conundrum

Dave, thanks for your comment on that Rich Seeley article.

I like where you've taken this. I'm trying to advocate services middleware and governance to an abstraction layer myself. Trouble is people are convinced they need to build web services so they can be SOA :)

Yet if we could take a page from the Spring crowd we would realize that we could add on all the goodies we want as needed and do so without offending the more elegant design of the business logic, even as you say, leveraging it for multiple governance models, persistence moles, remote protocols, etc.

I've seen REST used with success, but usually in what almost anyone would consider a non-SOA: homogenous consumers and producers in that they are using the same development stack and usually built entirely by the same team.

We'll see maturity over time I'm sure, and I think we'll start to right-size soon. Despite being a vendor in this space, I have to admit much of this polarization comes from tool vendors on the too-heavy side and open source frameworks on the too-light side.

Again, thanks for contributing to the dialog. 11/12/2007 6:50 PM | John Michelsen