Daily Archives: February 13, 2007

WS-* vs REST is not the question

Update 2/13 5:10 pm. Apparently I initially missed this post from Jerome Louvel on the reconciliation idea…
Update 2/16. See also Stefan Tilkov’s summary of the workshop papers.
It’s nice to see the Workshop get some attention in the blogosphere (hope I constructed those Google and Technorati searches ok).
For a while there I wasn’t sure it was going to happen.
But it’s a bit disconcerting to see how much of the interest is sparked by the very critical papers that take a kind of “anti-WS-*” or “pro-REST” position. Not much has been blogged about the papers that take a more moderate, middle ground view, or those from the user side that state requirements.
In putting the workshop together we tried to solicit as many position papers from the user side as we could, since it is hard to really evaluate the fitness for purpose of any given technology unless you have a good requirements statement.
The big question isn’t whether WS-* is too complex, or REST is better. The question is “for what?” In the context of this workshop, the “what” is enterprise software standardization.
My original statement to the W3C was around the importance of enterprise software standardization, and the question that eventually led to the Workshop, is whether anyone is really doing anything about this problem. You could of course just buy all your software from one supplier, but I am not sure that’s such a great idea ;-).
By way of contrast, anyone can see how well standardization is working out for the Web. (And royalty-free standards, I should add, since Tim famously decided not to patent his invention.)
Here’s a diagram of the problem I’m trying to find a good standards based solution for.
Typical Back Office Spaghetti Mess
Most medium and large companies have some version of this diagram.
The reason for it is pretty simple: companies just went out and developed the applications they needed, more or less one by one as they went, to run the business using whatever technology was available, what someone decided to buy (*ERP*), or using whatever language the developers on the team knew. The result is a lot of “stovepiping” simply because most folks were not even thinking about IT in terms of an enterprise level asset – they were thinking about the ROI of the next manual process they wanted to automate.
So what do we propose to solve this problem?
Tim Bray’s blog entry includes an excerpt from Paul Downey’s workshop paper, which I actually took to be fairly neutral (althogh Tim of course, and famously, is not).
Tim also focuses on on the WCF reference implementation idea. Certainly there’s a lot of truth to this, given the large number of Windows developers. WCF may very well come to define what WS-* means, at least for many many developers. David Chappell has said something similar.
In an interview published last year, Tim O’Reilly gives the tools argument. It’s very possible that a overly strong focus on tools contributes to the difficulty to innovate here and really address the problem. For one thing, what is easiest for the developer is not necessarily the best thing for the enterprise. If the goal is to make a service easily reusable, for example, this might be harder on the developer than simply implementing the function in a standalone application.
Among the SOAP bashers there’s very little talk of alternatives. Nelson is one of the few to even bring up this topic.
So where are we on the enterprise software standardization question? WS-* has a lot of critics but no good proposals for alternatives.
This will no doubt be among the more important topics to be discussed at the Workshop. Mark Baker’s paper takes a view of it, and I certainly hope we can find a lot of time for it.
One perspective is that WS-* exists for the purpose of adding back into HTTP what was intentionally omitted, and of course this is a major reason for RESTians to object.
Consider the strange situation of WS-ReliableMessaging. Web services specifications are designed to be communications transport independent. But WS-RM only makes sense for an unreliable protocol, such as HTTP.
So where are we? The adoption of Web services is increasing year over year, and yet the opposition voices grow louder. Why is that?
An interesting Forrester report just came out that indicates very few vendors agree on what WS-* is. In fact only the basic specs are widely implemented. Maybe the basic specs are enough?
Also we have the news that the use of REST is on the rise for AJAX developers. Is that a surprise?
And what about this diagram?
Services “Standardize” or “Commoditize” the Problem
Adding services to the existing technologies can help solve the spaghetti/stovepipe problem by providing a standard interface to any application, so any application can be accessed the same way, regardless of its implementation technology. Can’t it?
Can the definition of Web services be influenced to solve this problem? Or is the Web a better place to start (again?).