I haven’t been paying very much attention to the WS-* vs. REST debate for some time but this SD Times piece by WSO2’s Sanjiva Weerawarana was just insulting:
Which one is it? WS-* or REST? It turns out that both camps are lying through their teeth about how “easy” it is to build distributed business applications using their favorite technological approach.
Nice try. I've never heard anyone from the REST camp claim that building distributed systems was “easy”. Ever. It’s exactly what has separated the two camps, in my opinion. There’s a clear distinction in overarching goals. The WS-* folks have historically been obsessed with making things easy, usually for an imaginary business analyst who is nowhere near as technically adept as they. The REST folks, on the other hand, seem much more interested in keeping the entire stack simple, and for everyone involved.
This difference in priorities (easy vs. simple) often manifests itself in arguments about technological issues on the surface. Take the never ending debate about whether REST needs a description language like WSDL; which, incidentally, Sanjiva is largely responsible for. If building systems in your world can be made easier with the addition of a description language, then WSDL probably makes a lot of sense. If, however, building distributed systems in your world is a tediously hard pain in the ass whether you have these cockamamie description files or not, well, then you fight to keep the system as simple as possible by reducing the number of actors, dependencies, and concepts to an absolute minimum.
A lot of REST adherents, myself included, have come to appreciate REST only after believing and then eventually giving up on the notion that distributed systems design could ever be easy. You eventually find out that easy is not feasible and go for the next best thing: simple; manageable with reasonable effort and care.
But if you've never designed a large (or even small) scale distributed system, it’s not hard to believe that building them could somehow be made easy with enough technology. There are a million vendors peddling a million technologies that claim to make distributed systems design easy. Sanjiva’s one of them. There are magic quadrants and IPOs and really serious people at really serious companies writing in really serious magazines about tools that make distributed systems design as easy as falling in love. Why would anyone believe that building these things should be anything but easy?
I don’t think the WS-* vendors intentionally sold a product they knew could never be delivered – at least, not at first. It appears that they truly believed that they could make this stuff easy, eventually. It’s just sickening to see them get away with what probably amounts to billions of dollars in bad IT investment and all the while poopoo-ing the REST folks who were trying to inject some reasonable expectations into the discussion. It makes it extremely hard to swallow Sanjiva’s admission that …
In fact, there is no easy way to build distributed applications; it’s simply a hard problem. WS-* and REST (Representational State Transfer) each has its own strengths and weaknesses.
Once you cut through the cloud of hype, it becomes much easier for the confused enterprise architect to understand what to use and when. So let’s take apart the WS-* versus REST debate and clearly separate the facts from the myths and the lies.
Gee, it’s nice to know that REST will finally have a place at the table with the really serious crowd but it’s hard to understand how the same people who have screwed up so much of the past near-decade should be given the space in reputable publications to make these types of statements without them being attached to a letter of resignation.
Discuss
I read a lot of posts about how awful WS is and have always generally believed them, coming from the RESTful, do-it-yourself side of things myself. Although recently, for my java gig, I had to write a web service client that would talk to someones .NET-based service. It turns out that the existence of WSDL for this service made it such that I didn’t have to write any code at all; I just installed Apache Axis, ran their command line tool to generate java stubs from the WSDL, and I could continue developing against a perfectly-written API and not ever deal with a single line of network-oriented code, and it all worked the first time.
From that standpoint, how is that not “easy” ? It couldn’t be easier. Was so glad I didn’t have to write parsing code, HTTP request code, etc., the way I would have if I had proposed the whole system myself (i.e. restfully).
Admittedly, its total 80% land; a second task, which was to deserialize an XML file which looks like the WS’s response into a stub representation proved impossible since Apache Axis provides no API for that, way more source code than you'd ever want to dig into, and a good number of similar souls in their help forum asking for the same feature with their cries left unanswered. So thats where WS totally let me down and if had I written something homegrown, would have been trivial (but still homegrown).
So is it really “the 80% issue” we’re talking about here ? Because on the one hand, I'm really glad I didn’t have to write a parser and HTTP code to talk to this web service. On the other I can’t go “outside the lines” at all without major headaches.
All of that said, the WSDL file only made the experience better, and even my XML issue could be easily solved with a simple tool which would go off the WSDL as well. While the format of WSDL itself is certainly a nightmare, I don’t quite understand the resistance to having any sort of standardized definition language. Because you can argue that dependence on tools is a bad thing, but I'm not sure you can argue that tools shouldn’t be available (and you really need a definition language for tools to work).
— mike on Sunday, January 13, 2008 at 02:20 PM #
mike wrote:
That’s basically what I'm trying to get at, I think. If by solving the 80% you create another 81% or make the remaining 20% impossible then you’re at a net loss. It’s a problem of unintended consequences and there seems to be so many of them over there at this point that you have layers of tools on top of consequences on top of tools on top of consequences.
And although it was the only example I gave, I really wasn’t trying to dump on definition languages as a concept or anything. I've heard WADL described as being fairly useful while staying simple. I just think WSDL, being a requirement for doing anything useful in WS-* land, is a good example of the general mentality of “tools first” programming. For reasons I don’t completely understand, tools that attempt to abstract away fundamental parts of distributed systems programming have proven extremely hard to get right.
But, hey, if you’re doing simple RPC type stuff over a small, controlled network then WSDL-described services might really be the best way to go; although, I'd argue IDL based CORBA/DCOM has a lot of advantages in those cases.
— Ryan Tomayko on Sunday, January 13, 2008 at 04:51 PM #
Leave a comment