Are Web Services receding?

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.

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.

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:

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?
You must be logged in to the O'Reilly Network to post a comment.

Showing messages 1 through 3 of 3.

REST and SOAP
2004-09-23 09:47:46 glebleu [Reply | View]

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.

From this last perspective, REST is great. It is based on existing web concepts: URLs, etc.

But, at the same time, since I haven't really got into the details of REST, I have a few questions about it. To me REST is very library oriented, if you see what I meean, very publishing oriented, or database-centric.

How does REST would handle distributed transactions, does it have to? how does REST handle event-driven, asynchronous (notification) integration ? does it have to? can we live without all this?

Is there a good book/starting point on how REST can be put to work in an enterprise environment?

Thanks

Guillaume Lebleu
Brixlogic

Web Services RIP
2004-09-22 21:19:33 kurt_cagle1 [Reply | View]
Hi, Simon!

Excellent post, and one that to a great extent compromises my avowed statement not to gloat when the web services hype bubble collapsed around us.

SOAP (and WSDL and UDDI) emerged out of three main priorities:
- Salvaging the diminishing returns that certain companies had in trying to get DCOM working across disparate platforms and networks,
- Bypassing the "difficulty" that application developers had in getting their apps to work past port 80 firewalls (which were put up in order to keep developers from getting past port 80 firewalls in the first place), and
- Pushing the model of centralized servers as giant object classes in which anonymous people would get their daily dose of advertising, read company phone directories, and bypass protections set on databases.
For some bizarre reason, Web Services didn't quite work out that way. Web Services are cool for handling asynchronous messaging architectures - there's enough useful information contained within the headers for that - but as mechanisms for RPCs, they are usually overkill backage at best, adding significantly to transaction and processing costs and complexifying application development as a process.

XML is more than just a convenient envelope; RESTful systems where state is encoded within the messages actually DO work better in a distributed network, surprise surprise. Autonomous interface discovery is a cool concept when designed right, but WSDL is complex enough to make a guru master's head spin, and unfortunately still doesn't have enough semantics to be useful at the level it needs to be.

I knew web services were in trouble when I applied the Use Case test to it: put together a selection of use cases to illustrate how it is superior to existing restful situations.

For some reason, what I found was that synchronous web services seem to work best only with highly volatile, reasonably large data structures that still required a great deal of parameterization - in layman's terms, stock quotes and weather forecasts. Outside of that realm, people have had to really stretch to find useful places for SOAP, and the resultant performance hit has often driven them either back to a more RESTful form, or has driven them back into the realm of COM or CORBA.

Ten years from now, we'll be slinging our XML around using the open standards that are just coming to fruition now, and the WS-* "standards" will show up, spoken in snickering tones by a Septagenarian Alex Trebeck, in the $1000 column of Jeopardy. Just my two cents worth.

-- Kurt Cagle

REST Amen
2004-09-22 18:58:12 Tim O'Brien [Reply | View]

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

Showing messages 1 through 3 of 3.

Contact Us \| Our Mission \| Privacy Policy \| Advertise With Us \| \| Submissions Guidelines
Copyright © 2008 O'Reilly Media, Inc. \| (707) 827-7000 / (800) 998-9938