The Korean Conflict... and why SOAP and REST were never a "war"

David Chappelle, a man I greatly respect and admire, recently blogged that

... the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side--it's Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.

While I agree with his conclusion (that both technologies have a place and can we please just move along here?), I think the analogy is a bit misplaced. I'll get to that in a second.

Elliott Rusty Harold, never one to let a conclusion go by without putting his name on it somewhere, then tries to take David's conclusion and, in his own unique and partisan style, subvert the discussion and David's conclusion entirely:

That’s a nice analogy. Take it one step further though. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty+ years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.

The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails because it believes massive central planning works better than the individual decisions of millions of economic actors. WS-* fails because it believes massive central planning works better than the individual decisions of millions of web sites. It’s no coincidence that the WS-* community constantly churns out volume after volume of specification and one tool after another. The WS-* community really believes that developers are too stupid to be allowed to manage themselves. Developers have to be told what to do and kept from getting their grubby little hands all over the network protocols because they can’t be trusted to make the right choices.

By contrast you don’t see a lot of complicated REST frameworks or specifications. You could read all the relevant REST specifications in a slow afternoon (mostly the HTTP spec and a couple of subsidiary RFCs, plus XML and Namespaces in XML. Maybe Atom syntax and Atom-pub too if you feel ambitious.). REST/HTTP sets up a simple economic system based on a few clear rules, and then pretty much gets out of the way to let people do their own thing. It doesn’t even get too upset when people break the rules, and start tunneling everything through POST or deleting items with GET. The main people harmed by such bad decisions will be the sites themselves, and they will be dealt with by the RESTful market.

Let's get a few things straight: as any student of modern political theory will tell you, communism is a political system built around an economic model. The economic model, in many ways, is an idealistic one, somewhat reminiscent of the open source model: everybody produces what they can, contributes it to the whole, and partakes of that collection only as much as they need to in order to meet their needs/requirements. "From each, according to their abilities, to each, according to their needs". In a perfect world, it's a far more sensible system than this capitalistic system in which we find ourselves--it's a system that's predicated on cooperation rather than competition, looking to avoid the extremes of the capitalistic system: no poverty, and no blindingly rich.

The political system, however, is where communist theory breaks down completely. The governing body, as any group invested with absolute power will, in Hobbesian fashion, becomes corrupt and looks to ensure that it receives the lion's share of the benefits. This distorts the entire basis of the system, leaving those who are producing at their fullest potential to wonder, "What's in it for me?" and look to get away with doing as little as possible in order to obtain the maximum possible. In short, the commonly-attributed failure of communism is "human nature".

(Sort of puts a rather dark horizon on the whole open-source community, if you ask me.)

I don't think anyone is going to hold up North Korea as a model Communist society; in fact, of all those governments still following the communist political doctrine (of which the current count, by most sources, is two: Cuba and North Korea), it's fair to say that none of them are exactly winning admirers either among their populations, the political watchdog groups, or the academics. So drawing any kind of analogy in which "communists" are one end of the analogy is almost guaranteed to make your partisaned point of view pretty clear. In fact, politically, the problem with North Korea isn't so much with its economic system as its totalitarian form of government, which is almost entirely orthogonal to its centrally-planned economy; several European states--Sweden being one of them--have high degrees of central planning and they seem to get along quite well with the rest of the world. So let's put the "North Korea is bad because it's communist" argument on the shelf, shall we? It's the fact that (a) they're totalitarian, and more importantly, (b) their leader doesn't like us, that makes them one of the "Axis of Evil" states. Saudi Arabia is also totalitarian, and their populace doesn't exactly rank at the top of most standards-of-living charts, either. In fact, the Saudis (76) rank below Cuba (50) on one measurement of standard of living. (Data drawn from the Human Development Report 2006.)

All that said, it's probably obvious that (a) I don't think the communistic argument here is relevant, and (b) I don't think the WS-* set of agreements are at all communistic or totalitarian. In fact, I'd argue they much more closely follow the model of the European Union, rather than communistic practice at either the economic or political levels.

Look at it this way: the WS-* set of documents intend to provide points of agreed interoperability, not a set of practices that platform developers must follow. Assume you, a Ruby shop, and I, a Java shop, want to integrate systems. Assume we need to ensure that the communication cannot be hijacked, must have certain atomic guarantees, and can't just "disappear" into the ether of the Internet. I don't particularly care how you write your code, and you don't particularly care how I write mine, but in order for us to get our work done between us, we have to agree on how the stuff across the wire will look.

Consider, for a moment, the issue of security: We can certainly agree on using HTTP/S, which requires that we both establish digital certificates that will be validated by code every time the communication is established. (We can't rely on the Web's traditional one-sided certificate approach, because that only verifies that the client knows who the server is; the server has no mathematical guarantees that the client is who they claim.) HTTP/S also means a new shared session key must be exchanged between the principals, meaning that no intermediaries (a fundamental feature of TCP/IP, and of the RESTful architecture itself) are possible, since now the intermediary has to have its own certificate, if it's going to be able to influence the communication somehow. That means now that you and I don't trust each other directly, but a third party, which is a wholly different set of discussions.

WS-Security (or, more appropriately, WS-SecureConversation) addresses this.

On the issue of reliable communication, we can either assume that the TCP/IP "best delivery" semantics are sufficient, but given how many of us have seen the "ghost request", the HTTP request that gets sent from the browser but never gets a response, or the "phantom email" that get sent and never received, most of us are going to be somewhat skeptical about the idea of our bank using TCP/IP for transfers and deposits without some degree of additional reliability requirements. Using REST, then, we build our own ACK system, identifying messages with unique values and requiring recipients to respond when a message is received, just to make sure the message was received.

WS-ReliableMessaging addresses this.

These are not requirements, by the way--you do not have to use these facilities if you are building a SOAP-based service. They are opt-in, if your payload is wrapped in an SOAP envelope (which consists of two additional elements around your POX data, by the way). In fact, if you build your own REST/POX service, chances are you're going to end up re-designing something very similar to the SOAP envelope anyway, when you build in some kind of structure for handling out-of-band data (like authentication information). You're free to use HTTP headers, but they're limited to simple name-value pairs, which can be somewhat constraining at times. (Look at what cookies look like sometime; clearly they could benefit in a big way from some larger structure.)

The key thing here is, when you want these facilities, people have already agreed on how they should look so that you don't have to work out all those details for yourself. In this way, it's something like the Euro: a nation doesn't have to use the Euro as its currency (look at Great Britain), but it benefits from doing so. Or, for a different analogy, the WS-* set of specifications are like NATO: an agreed-upon set of protocols and understandings designed to allow for maximum interoperability during a time of crisis (namely, the presumed invasion of Germany by the Warsaw Pact nations). It didn't mean that each nation wasn't able to purchase whatever arms it desired, or train their soldiers in whatever fashion they desired, it was simply an established logistical structure to help everybody "get along" and work together effectively in the face of the crushing numbers of Soviet, Polish, and East German (among others) tanks and soldiers.

In essence, the goal of REST was to create a loose-as-possible coupling between client and server for the purpose of distributed hypermedia. Fielding's thesis makes this eminently clear from the beginning. Trying to create a generalized distributed communication system was never part of the goal, at least according to the thesis itself. More importantly, there are numerous places where tighter coupling, or greater interaction, or some kind of transactional capability, are necessary. Not in all situations, but as Michael Nygard points out in Release It!, a lot of the integration scenarios that developers face aren't across HTTP boundaries, but across departmental boundaries.

Oh, and it's not just the big vendors who get to propose these SOAP-based standards (though if you want yours to gain traction with the industry as a whole, you're obviously going to have to elicit their support); you're more than welcome/free to use the SOAP Envelope/Header area for your own purposes, just as we do with HTTP headers. Just make sure your tags don't conflict with anybody else's (ah, yes, that's what XML namespaces were for), and party on.

Put that way, the WS-* stack doesn't seem so bad, does it? Clearly the Euro and NATO function a lot better than communism does...

Meanwhile, back to Korea.

It may seem odd to many that I'm criticizing the use of a war as an analogy to Computer Science; after all, I was the one who let the genie out of the bottle in the first place. My issue here isn't with the use of a war as an analogy to what we do (I think there's a lot more analogy to war in what we do than there is to building a house, in fact), but with the particular analogy in question. The SOAP-vs-REST debates helped frame a large part of how we view distributed systems. Korea, "the forgotten war", gave us a legacy of...

... well, nothing.

Apologies to all who served in Korea (as did my uncles), but the basic fact was that Korea really didn't change anything. At the close of World War Two, the Koreans, who'd lost their national independence to Japan in the mid-30's, were eager to re-form their nation and resume governance. Unfortunately, the two superpowers had their own ideas: the Soviet Union (and, more notably, China) refused to consider a united Korea under Western influence, and the US refused to consider a Korea under Communist influence, regardless of what the people themselves might have wanted. (Truthfully, it's hard to tell now what the general populace wanted at the time--sources are pretty biased and partisan and entirely conflicting.) This was how things were left, the Korean peninsula split at the 38th parallel, until 1950.

On June 25th, 1950, the North invaded the South in a surprise attack, pushed the ROK (Republic of Korea) and allied forces back down the peninsula until General MacArthur, the Pacific War hero of World War Two, dared an amphibious landing at Seoul, far to the rear of the front lines, and the Allies were able to push the North's forces back up the peninsula. Then, pursuing a strategy of "total war", MacArthur chose to continue north, pushing the Communist forces all the way back to their border with China. MacArthur, in fact, wanted to push even further, taking the war into China if necessary, to achieve the kind of total victory he'd been able to create in World War Two. President Truman, mindful of the fact that the Soviet Union was presumably willing to go to war globally to prevent the fall of its (presumably) close ally, refused to allow Truman to slip his leash, and ultimately dismissed him, an entirely unpopular move with the US population. (MacArthur was widely supported in the US, and there were very real fears he would stage a coup and remove Truman from office. MacArthur turned out to be more patriot than populist leader, however, and wrote one of the most stirring speeches ever delivered instead.) China then dispatched troops to aid the North, pushing the Allies back to the 38th parallel, where things remained until an armistice (and later a peace) was signed in 1953.

Militarily, nothing much changed. The front lines remained as they are today, fifty years later, and the war did nothing to change the balance of power in the region, or in the world. The US still feared and distrusted Communist China and Communist USSR (who were in fact very dubious allies, though it wasn't known at the time), ultimately leading in part to the Red Scare and the Committee on Un-American Activities, what came to be known as "McCarthyism". For most of the domestic US population, once the troops came home, the desire was simply to "go back to the way things were", and forget that the conflict ever happened.

This is why I disagree with the analogy: for many of us who've participated in this debate, the "REST-vs-SOAP" discussion (which really was more of a "REST-vs-RPC" discussion) helped frame several key concepts: the idea of coarse-grained communication, the desire for loose coupling, the discussion around XML as a lingua franca for data, and so on. Clearly the REST-vs-RPC debate helped frame a great deal of the conversation around distributed systems for decades to come, and in that sense, it makes zero sense whatsoever to analogize that debate as being similar to the Korean War.