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?).

4 responses to “WS-* vs REST is not the question

  1. Asbjørn Ulsberg

    At my previous employer, we built a communication bus (built in Python, running on Apache) based on HTTP and REST principles, which was able to transmit messages to any entity in the network based on a standardized XML envelope format that you could cram basically whatever you wanted into. Almost like BizTalk, only unimaginable faster, simpler and more useful. And not to mention, cheaper.
    That solved every interoperability and communication problems we had between any of our systems. All we needed was a “plug” in producer systems that would transmit information to the bus and a reverse plug on the consuming end that would attach itself to the bus and receive content from producers.
    The bus was a single point of failure, but since we used HTTP, we were able to do HTTP redirects to a backup server if server #1 had too much work (all incoming messages was queued in a thread pool and executed as soon as there were available resources). We supported POST, PUT and DELETE, and consumers would respect these and act on the resources to create, update or delete them.
    No magic required. Just a little Python script (~600 lines of code) sitting on a couple of Apache servers. HTTP defined the protocol, we defined the wrapping XML envelope and creating a producer and a consumer took nothing more than an hour.
    A typical message (~500k in size) took no more than 0.5 seconds to complete from point A, through the Bus and to C. A consumer could subscribe to messages based on XPath queries so it wouldn’t receive messages not matching the query. It was very flexible and in tests, it outperformed BizTalk with 10 to 1.000 orders of magnitude, depending on the message and the work involved.

  2. I remember when I was working as the VP engineering for our Web services integration products, one of the developers stopped by one evening to tell me the bad news.
    All of this can be done using Perl, he said. You don’t really need all the rest of this stuff we’re building (adapters, process engine, transformation engine, JMS messaging bus, etc.).
    Actually in those days Microsoft viewed the product we had as competitive with BizTalk, kind of an interesting coincidence.
    Eventually we had to cancel that product line because of the industry downturn, but I understand other vendors continue to build stacks in that direction.
    Our current product lines (Artix and Celtix) exist because someone doubted the “Web services solve every problem” approach and tested the idea with dozens of customers (current IONA customers and non customers). What he found was that yes, Web services had a role to play, but so did a number of other technologies.
    We had a long debate after that about whether or not to use WSDL as the common interface. I think it’s worked out ok, but this is certainly another area of investigation in the future, whether other technologies have a role to play.
    Personally, I believe HTTP has a larger potential role within the enterprise, but I think it will take a long time before HTTP achieves the level of adoption inside the enterprise that it enjoys in the Web.

  3. New and Notable 142

    Data/ADO.NET Orcas Two from the ADO.NET team: Entity Client and Nulls – LINQ to DataSets Part 3 Software

  4. New and Notable 142

    Data/ADO.NET Orcas Two from the ADO.NET team: Entity Client and Nulls – LINQ to DataSets Part 3 Software Architecture/SOA/CAB Udi answers, Can or should SOA be implemented without Web Services? David Chappell on The Three Faces of SOA Eric Newcomer:…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s