Are Web Services receding?
by Simon St. Laurent
A lot of postings I've seen in the last week follow nicely on a "Web Services War Stories" session I saw at Foo Camp, suggesting that Web Services, while still important for some groups of developers, may have lost their broader promise.
I missed the first half of the war stories session, but arrived in time for plenty of negativity. A blog entry by Nelson Minar reflects both SOAP advocates' hope that SOAP isn't much harder than plain XML-over-HTTP and their concern that making SOAP interoperate - not just Java and .NET, but PHP, Python, and Perl - is difficult.
Another thread from that discussion I found echoed in this week's blogs is that SOAP and the WS-* family of specifications is trying to solve some really hard enterprise problems. Tim Bray's loyal opposition post conveys his amazement that WS-* work is continuing, and acknowledges that "the people writing these WS-things aren’t stupid." There are smart people with real hopes working on difficult problems here.
Bray's position for now is "to stay out of the way and watch the WS-visionaries and WS-dreamers and WS-evangelists go ahead and WS-build their WS-future" - there's some chance it might be useful for some class of applications.
Sean McGrath notes Bray's opinion and offers his own:
"I believe WS-YouMustBeJoking is doomed to collapse under its own weight. Good riddance to it. Why has this situation come about? Because smart people had neural spasms? No. Because smart people realise that this stuff is *real* important and commercial agendas are at work all over the map."
McGrath's discussion (and an older Python discussion) reminds me of something else that came up in the conversation: hard questions about what benefits SOAP and WS-* provide people whose needs aren't actually that complex.
(Update: I forgot to mention another blog entry that demonstrates this, Jeff Webb's excellent piece on how it's often easier to call HTTP from Microsoft Office than SOAP.)
At the War Stories meeting, I suggested that part of the reason we keep hearing about WS-* and SOAP was that it's far easier to sell complicated things rather than simple things, and I still hold to that opinion. At the same time, though, Mike Champion brings me back to thinking that maybe there's a market separation problem here:
"'Real' people building enterprise applications of the sort that the WS-* specs target work with objects, databases, transaction monitors, and reliable message queueing systems .. which they need to make more accessible via HTTP *gateways." They don't have the option of simply exposing these systems as stateless Web resources with whom one exchanges XML respresentations, without a massive amount of code rewriting or adapter building, and there is nobody writing books or selling tools to assist them. There are, however, reams of whitepapers, articles, and books explaining how to apply the WS-* approach to the problem, and a considerable amount of success to show for all this.
Web Services emerged at a time when some of us actually believed that XML was a uniform solution to disparate problems, and there was a long time when XML and Web Services were treated as synonyms. Maybe what's happening now is the result of recognizing that a large number of programmers and users aren't actually enterprise developers - we have no more need of WS-Transfer than we have of an S/390 running a dedicated message queue system.
For the most part, Web Services and the WS-* set of specifications address problems many people just plain don't have. I'm happy to report that I lack those problems in my own work, and I've been sad for years that Sun put the Servlets API into the J2EE side of Java, an area that I'd otherwise avoid entirely. As I haven't been poisoned by the promise of scalability, I prefer to avoid the complications that emerge in massively interconnected systems whenever possible. SOAP promised to bring those complications to my kind of work without redeeming benefits.
Ironically, the Web itself has demonstrated that it's possible to distribute computing widely using a relatively simple stack of interfaces. The HTTP-based Web is remarkable for making a lot of things possible by largely staying out of the way. Sure, the Web doesn't do what CORBA can do - but what share of the people, even the people programming for the Web, really need CORBA?
That makes me wonder if Web Services are on their way to a CORBA-like market: sort of interoperable, vendor-ridden, and critically important to a small number of people. If that's the case, then maybe the rest of us can return to vanilla XML+HTTP, sometimes known as REST.
Are Web Services the next CORBA? How?
Listen, I'm no arch-enemy of SOAP, I've coded my share of web services, but vendor compliance (read non-compliance) and just the overall "concept baggage" that comes with web services turns me off (see Apache Axis documentation). If you have control of both ends of the pipe, and you've discovered brainless ways to parse XML (i.e. Jakarta Commons Digester), then give SOAP a REST. (I couldn't resist).
Web Services RIP
REST and SOAP
First, a couple comments on this post, without going in too many details:
- To me, SOAP is really just a way for existing centralized platform vendors to maintain their existing concepts in place, as well as their market share: the avalanche of WS spec looks to me like a way to make competition impossible, except between IBM and MSFT, on the platform market.
- Standards are great, but most of the time, they get crazy by trying to put everybody's need into one document, bringing extremly complex abstractions along the way, or tons of optional fields to avoid semantic collision, that 99% of people don't need. This is true for tech and industry standards. In a way 90% of us need ultra-simple standards, and 10% have very complex needs that are too expensive to standardize.
- Simplicity drives adoption.
- Adoption drives change.