Web Services discussion worth watching

Posted 25 Apr 2002 at 17:15 UTC by simonstl Share This

If you've been doing any work with SOAP/WSDL/UDDI, .NET, or related "Web Services" goodies, you may want to take a close look at an intense and often angry discussion about whether these technologies are as useful as promised, and (somewhat separately) whether they're a threat to the Web technology ecosystem.

There is a wide range of issues, often mixing questions about patents with questions of technological fitness, market acceptance, and political questions about vendors, open source, and the W3C.

As SOAP and Web Services percolate into open source projects like Mono, the various Apache implementations, and a variety of other tools, it may be a good idea to take a close look at the underpinnings of the technology, not just whether it feels good today. Distributed services have always been complex, and it's not clear that SOAP has cleaned away the long-term complexity.

Developers who focus on Web-related projects may also want to keep a close eye on the W3C. Whether or not the W3C stands up to member claims that Web Services are its work may have a substantial impact on the shape and perhaps the cost of the Web.

If, on the other hand, you just care about whether things mostly work today, you can find plenty of comfort from a variety of "everybody's doing it" arguments. (1 2 3)

Online Storage: Risky Move For Your Files, posted 25 Apr 2002 at 19:45 UTC by goingware » (Master)

Here's why web services is a really bad idea.

One of the main advantages of web services is that your data storage will be on the service provider's server. That way you can access your application from anywhere.

But it also means that if the service provider goes out of business, or decides your critical application is no longer profitable, you're screwed.

The photo and remote backup hosting providers have so far escaped liability, so I imagine the providers for critical services will too. And anyway, provider liability is not what you want - it's your data back, which so far many people have been unable to get.

Loss of data stored on hosting provider's servers is already happened. It's a reality. It will only get many times worse when Web Services is widespread.

Imagine that it's not the only copies of your photos of your dead brother that you lose, but the payroll history for a medium sized company.

I will have more to say on this topic.

ad.doubleclick.net NOT FOUND, posted 25 Apr 2002 at 20:46 UTC by sye » (Journeyer)

i'm only guessing. Does this discussion have anything to do with that annoying "ad.doubleclick.net not found" message?

Pragmatism versus idealism, yet again, posted 26 Apr 2002 at 05:31 UTC by braden » (Journeyer)

I imagine that simonstl can only be depressed by the first two responses to his article, and may be seriously reconsidering the value of his participation at Advogato.

C'mon, people... Get with the program.

I suppose there is a significant faction here that will not or cannot do Deep Architectural Thinking about big systems like the Web. (I knew they were here; I just didn't expect them to be quite so vocal about their ignorance.)

Enough venting...

To boil the Web Services conflict down to one of pragmatism versus idealism is perhaps somewhat unjust, but not entirely, IMO. The REST camp suffers from the same problem that plagues the Semantic Web camp (though not to the same degree): a failure to present their ideas in a way that is accessible to The Average Web Developer. Part of the reason people understand SOAP (or at least think they do, which is arguably more important) is precisely because it doesn't have all the philosophical and intellectual baggage that is needed to justify the constraints present in approaches like REST. Valid or not, the relevance of these constraints is only as great as the number of people who understand why they're there.

At this point we are stuck with SOAP for a while, for better or worse. Those who prefer a different approach should let SOAP go its own way, and make it part of their job to ensure that the SOAP camp is equally accommodating to alternate approaches. And the REST folks should take this experience to heart: this is what happens when, in pursuit of lofty goals, you lose touch with the needs of the average developer. Keeping him happy is key to the realization of those goals.

pragmatism, danger, posted 26 Apr 2002 at 14:23 UTC by simonstl » (Master)

The first two replies weren't so bad - "Web Services" still means a lot of different things to different people.

As far as the pragmatism vs. idealism angle, there's a lot more depth to this than "REST is aesthetically more pleasing and SOAP appeals to the average Web developer."

REST _is_ what most Web developers do every day, without really pondering it that hard. I don't see anyone building Web sites, for instance, that use a single URI and expect users to send POST requests to get back different pages. (I may have to build one now, just to be perverse.)

As stupid as that sounds on its face, that's precisely what SOAP does for program-to-program communication. I don't mind request-response for developers - I just want it done in a context that makes more sense. that could mean switching to a different framework, like BEEP, or it could mean considering how this works within the framework of the Web, and that's probably REST.

I'm happy to see SOAP go its own way. I'd just like it to:

  • stop calling itself "Web Services", since it ain't
  • find a different transport mechanism. Microsoft's proposed DIME already.
  • Find an appropriate home for the specs, and let the W3C focus on the Web.
  • Clarify the intellectual property issues around SOAP itself, WSDL, and UDDI, so average developers know what they'll be paying for

    That last one seems well-covered in patent issues. Even if you don't like REST, it may be the freest option.

  • Selling REST, posted 26 Apr 2002 at 15:58 UTC by braden » (Journeyer)

    I guess I was excessively cranky starting my last response. Still, it's not like you, simonstl, haven't provided context for the points you're making. Of course the term "Web Services" is deliberately vague/misleading because it gives the marketers the greatest leeway in their... ahem... projection of the concept's potential.

    REST may be what most developers are doing now, but that's a matter of technical convenience rather than ideological following. Where a SOAP-style approach is more convenient to implement, it will win.

    What factors might make the SOAP approach more convenient to implement? How can the W3C make it a more attractive proposition for implementors to stick to the REST model? Have any vendors made a commitment to support the REST model with REST-friendly tools? I bet the answer is "no".

    If REST is to succeed as a dominant Web design philosophy (rather than just another way to go about doing things), get Sun on board. Alienated from the WSI, they may find the prospect of a Better Way attractive. Sun needs an acronym (from somewhere other than Microsoft) to demonstrate to the trade rags that they are serious about playing in the same space as the WSI; REST needs tool support that validates its concepts explicitly.

    Do we need to manufacture a movement?, posted 26 Apr 2002 at 16:20 UTC by simonstl » (Master)

    Your questions about selling REST are well-taken, but there's some serious irony to them.

    REST isn't a "thing" in the same way that SOAP is or even BEEP is. SOAP is an explicitly specified protocol framework that has XYZ processors for XYZ environments. These toolkits are labeled "SOAP" or "Web Services" explicitly.

    REST is pretty much riding on existing Web practice to get work done, not an explicitly specified new-and-different framework. There are hundreds, probably thousands, of REST toolkits out there, but they have names like the Apache HTTP Server, Java XML data binding, XML::Parser, etc.

    Asking people and vendors to support REST is kind of like asking people to support air. We all breathe it all the time, and sometimes do other things with it. I see SOAP as polluting that air, but a lot of people don't mind smog as long as they can drive their SUV to the mall.

    I suppose it's possible to create toolkits around these things, but it's pretty much development-by-accumulation, rather than coming up with new conglomerations to market and heck, maybe patent.

    Would you like some oxygen with that nitrogen?

    For people to care about REST, they have to be able to spot it, posted 26 Apr 2002 at 17:09 UTC by braden » (Journeyer)

    I realize the relationship of REST to existing practice. But of the tools you mention, how many can be used to subvert the REST philosophy as well as implement it? It seems to me like such subversion could occur relatively easily, and thus naively. What I'm getting at is that REST proponents need to find a way of highlighting those practices that are REST-kosher, and those than aren't. And then see to it that the tools make it easy to do the Right Thing, or at least difficult to do the Wrong Thing.

    what was it ? again ?, posted 26 Apr 2002 at 19:03 UTC by sye » (Journeyer)

    Benjamin C. Pierce did a talk "Global Computing: Some Questions for FOOLs". I can almost guess what he is slicing with his pie-calculus.

    REST and the Semantic Web (for Average Web Developers), posted 26 Apr 2002 at 19:21 UTC by aaronsw » (Master)

    The REST camp suffers from the same problem that plagues the Semantic Web camp (though not to the same degree): a failure to present their ideas in a way that is accessible to The Average Web Developer.

    It's funny you say this, because just this week I gave a talk and write a paper trying to solve this problem. It's called The Semantic Web (for Web Developers). I'd appreciate your feedback.

    Meanwhile, I agree that we need tools to make writing REST code easier. I know that mnot and amk are working on some.

    Thanks for the links, and my opinion, posted 28 Apr 2002 at 04:53 UTC by piman » (Journeyer)

    As someone who's been watching "Web" services evolve in the background for a while (my experience with XML/HTML is mostly in the document rather than data areas), this was an interesting read.

    My feeling, after reading all this (and thinking I have a pretty good handle on it) is from the point of view of a content creator, REST is the better solution. I believe you're right when you say it's what we've been doing all along. Having only passing knowledge of SOAP-RPC, I was surprised to learn it has a single URI interface to everything - I thought it was just a formalization of some data structures in XML, but apparently it's also a new "HTTP" interface that neglects unique URIs, which I think is anathema to the structure of the web as it is now.

    Upon reading the above paragraph, I find it extremely trite, since obviously this was your point all along. But I guess it might be good for me to say that as a "user" rather than "developer" of these things, I prefer the REST approach over the SOAP one.

    (I also think it's hardly an idealism v. pragmatism issue; in fact, I think this really isn't much of a factor at all, except that ideally technologies are perfect, and practically they often end up not being so. What's "easier to implement" doesn't seem to be an issue here, since REST doesn't need to be implemented per se.)

    REST tools, posted 28 Apr 2002 at 04:58 UTC by piman » (Journeyer)

    braden, it seems most REST tools can easily be used to "subvert" REST, in the sense that REST is still XML, as is SOAP. REST doesn't seem to need much more than a web browser, web server, and XML parser/generator. SOAP needs all that, plus the SOAP layer. IMO, it's already difficult to DTWT, since it requires an additional layer of software. The problem is more many programmers are looking at HTTP + XML and thinking "Wow, this provides a nicer layer of data transfer abstraction", then looking at SOAP and going "Another layer of abstraction can't hurt", when in reality since no more semantical data is actually contained in SOAP than REST interfaces, the layer of abstraction only hurts (and damages the web infrastructure via poor URI handling in the process).

    My 0.02p, posted 29 Apr 2002 at 08:47 UTC by TheCorruptor » (Master)

    Well, I'd have to agree with Dave Winer for once; I'd rather see Google and Amazon offer these interfaces - - regardless of implementation method in the short-term, than not have them at all...


    From my experience it's been tricky to dodge the SOAP bus, not only because of the platforms we're deploying on, but due to the Microsoft press that our local PHBs have been buying into. It's an unintuitive framework in many senses, and seems overly verbose for some of the uses we've been toying with in recent months. However, technical arguments don't always win with marketing pushes... ;-)

    The larger problem from my perspective is trying to pick a solution for both in and out-going feeds that is consistent accross the board, supports our client's needs, yet remains "clean" in implementation (for argued values of "clean"). Given our client's tendancy to not be fond of XML in the first place, and that they are often running legacy systems, I am at least lucky in the short-term; we're pretty much working with a REST philosphy here atm, yet I have the breathing space to look around and follow the arguments whilst keeping my eye on our future direction. Somehow, given the type of clients we have, I think that future direction will be dominated by SOAP.

    I am however, desperate to see some concensus of opinion on the matter. edd's thoughts echo much of what I, and many of my collegues have been feeling for a while, but I'm not too sure I'd like to see XML/ Web services develop outside the W3C either. That's a beast that won't be tamed when it's wild. However, if it's in the zoo...?!

    At least with traditional HTTP I know *all* our clients will be able to integrate with their existing systems in some shape or other, and that's enough of a reason to watch the discussion for a while longer IMO.

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

    Share this page