WS-Defense
Steve Jones has written a post entitled “Want to be cool? Learn REST. Want a career? Learn WS”. His argument is that while REST may be cool, it’s not what pays your rent — WS is.
How sad.
I don’t dispute that WS-* is a commercial reality, but if the last argument pro-WS is “we know it sucks, but everybody uses it, so we have to, as well”, the technical debate clearly has been won.
(And no, I don’t believe this is irrelevant — I’ve had this disagreement with Steve in the past: REST vs. WS-* is not an implementation detail.)
Wasn’t “we know it sucks, but everybody uses it” the clincher argument for HTTP+HTML 10-15 years ago? http://shirky.com/writings/evolve.html It definitely was the clincher for XML. http://xmlsucks.org/but_you_have_to_use_it_anyway/
This debate is taking on the tone of the “pure relational model” vs SQL permaflamefest, c.f. the ominously quiet dbdebunk.com website, or http://www.fact-index.com/r/re/relational_model.html. There too, it’s easy to argue that the technical debate was won by the pure relational model 30 years ago, but SQL - and even more impure horrors such as XML c.f. http://www.dbazine.com/ofinterest/oi-articles/pascal11 :-) — rulez in everyone’s Day Job.
I believe the argument is more along the lines of simple vs. complex, i.e. TCP vs. OSI, SMTP vs. X.400 … WS-* is certainly not a bad implementation of REST concepts (which would be the case for the analogy with SQL and the pure relational model).
OK, but the larger issue to me is one of pure technology principles vs pragmatic engineering principles. REST and True Relational Model have many abstract technical values such as conceptual elegance that give them geek credibility and create passionate advocates. WS-*, SQL, XML, etc. tend to rule the Real World because they have made pragmatic compromises that a) leverage what went before; b) can be implemented effectively with contemporary software technology; and c) don’t force end-users to grok an entirely new and more abstract paradigm in order to work with it.
For example, a pure REST or a True Relational application requires a rather rigorous normalization of application level concepts into unfamiliar abstractions (tuples in 5th normal form that require multiway-joins to be reconstituted into application objects, resources with representations that are manipulated with idempotent operations). SQL/XML or WS-* users tend to be able to stay in their own domains and leverage underlying technology that only incrementally advances over the previous generation (e.g. using denormalization or XML to avoid inefficient joins, “tunnelling” HTTP to send SOAP messages across Web applications as well as enterprise message queueing infrastructures.)
In other words, in the real world SQL and XML don’t beat the True Relational model, or WS-* beat the Pure REST model, because people are lazy and stupid or insufficiently aware of the Truth, but because they are pragmatic, evolutionary responses to the stimulus of new ideas (the RM or the Web) in the context of installed reality.
Taking some time off to follow increasingly weird dbdebunk links (your fault I’m wasting my evening ;-)) … let’s try another analogy: SQL is a bad implementation RM (so I’m told, and not being an RM or DB kind of guy, I have to accept that). Smalltalk and Java are both implementations of OO — in this case, Smalltalk, although being the “better” language (in the OO sense) did not succeed as much as Java did, for the kind of reasons you suggest.
But WS-* applications and RESTful HTTP applications are not instantiations of the same abstract concept, one good, one bad. They are incarnations of different concepts. So it’s really more like OODBMs vs. RDBMS, IMO.
OK, I agree that they are instantiations of different concepts. Which brings me back to the eternal question: Why the never ending debate if they don’t share enough to be compared side by side?
Well … because on a different level, they are alternative solutions for the same problem domain. I admit to being slightly schizophrenic on this issue; on the technical and architectural side, I’m convinced the two are different. But from a high-level, business view they of course address a similar problem …
I don’t necessarily agree that they are alternative solutions to the same problem domain. They are different architectural styles and have different properties and qualities, which makes one style a better fit for a particular problem domain. For CRUD type of web applications a REST style would be more appropriate. In a distributed environment where you need to federate resources, services, security and transactions I would be more comfortable with the WS-* approach since there is a body of work that is dealing with this domain (WS-BPEL, WS-CORD, WS-BA, WS-Security, Liberty Alliance, WS-*)…….of course I don’t have any practical large-scale practical experience to back this up.
I also don’t necessarily believe that one skill set is valued more over the other in the industry. Learn both.
Stefan,
I’m not saying that WS-* isn’t as good as REST (I’ve continually said that its like arguing about two different types of cup holder, when what people care about is what is in the Cup). My point is one that dates back to the Mythical Man Month and before, namely that consistency is more important than purity. WS-* will exist and you will have to do it.
What I’m trying to say is that arguments of REST v WS-* tend to focus on irrelevant questions of developer time (ignoring tooling) and not on the commercial value and opportunity that the various different approaches give. WS-* has strong acceptance in this commercial area, both from the major vendors and from the standards bodies that are commoditising interactions on the basis that the “how” of interaction isn’t the piece that delivers business value. REST has a few bits from “cool” sites and from certain classes of developers, but nothing major in terms of solving actual business problems.
The problem of IT isn’t that we aren’t pure enough, but that we care too much about technology and too little about the business.
Jim, I don’t agree with the point about REST being more suited for CRUD-style applications and WS-* for the more complex stuff. I used to believe that, but I have spent way too much time with WS-* to do so anymore. The fact that many, many people I respect, even those who co-autor the WS specs, are in fact strong believers in REST, helps a lot.
Steve, I agree with the notion that business is more important than IT, and many, many IT folks should work to learn a lot more about the actual business value and their part (or lack of) in it.
Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs. Smalltalk or Windows vs. Linux vs. OS X is relevant or not depends very much on the topic of the discussion we’re having. When we’re talking about business strategies for a telecommunications company, Java vs. Ruby doesn’t play a big role. That doesn’t mean that they’re the same — even if they’re both “just programming languages”.
Similarly, I refuse to agree with the assertion that when I look at the technical, architectural properties of a system landscape, it doesn’t matter whether its architecture is built around DCOM/MTS, J2EE, WS-* or REST.
But that’s all beside your original point, which IIRC was “even if it’s cool, it doesn’t matter because the vendors don’t do it”. I disagree: Witness the inclusion of (admittedly bad) REST support in Indigo/WCF and Axis2, or the Systinet 2 repository’s REST interface, or the fact that Google’s Nelson Minar now asserts he’d never choose SOAP and WSDL over REST again … on the Internet, it seems to me that SOAP/WSDL has clearly lost, and this does not bode well for its future in the enterprise.
I will continue to help build good WS-based architectures — I’m not as principled as Mark Baker :-) Whenever I can get someone to listen, I will try to convince them of the REST alternative, though, and I expect this to get easier over the course of the next few years.
“Google’s Nelson Minar now asserts he’d never choose SOAP and WSDL over REST again ” As I recall, it was Google’s clearly inappropriate adoption of SOAP as a solution for their problem that led to my own flirtation with RESTifarianism a few years ago. In retrospect, however, I’m not sure it says much about the overall REST vs WS-splat question: they don’t have the problems for which WS-splat purports to be a solution, since their information is public (no WS-Security needed), there is only one HTTP hop between client and service (no WS-ReliabileMessaging needed), the data is primarily human readable (no XSD and data binding needed), and so on. I’d be more impressed if Google uses a RESTful architecture on their back end to keep their numerous data centers sync’ed up. I’ll guess, however, that security/reliability/integrity are too important for them to leave this to HTTP.
I’m curious, Stefan, are there situations where you don’t TRY to convince your clients of a REST alternative because it’s clear that WS is the right solution for their problem … or do you find that your clients’ problems are generally amenable to a REST approach? How do you handle the problems that WS-splat supposedly addresses, such as multi-hop reliable messaging, integration with back end systems that don’t use URIs, etc.? I would love for this debate to morph into a pragmatic discussion of how to solve such problems, comparing the real complexity of the WS-splat stack to the application level complexity introduced if these concerns are not addressed in the infrastructure.
Just for the record, I’ve since learned that Nelson left Google earlier this year.
“Wasn’t ‘we know it sucks, but everybody uses it’ the clincher argument for HTTP+HTML 10-15 years ago?”
I think this is a different matter to an ad-populum argument. It seems to be more like - it doesn’t matter whether WS-* specs suck or not, big vendors are promoting them. Deal with it. Now while big vendors do not always succeed in this fashion, it’s a poor message to be sending into the market, given that these specs exist largely to address interoperability and technology concerns. I would certainly want to qualify it with the technical merits of the specs and implementations based on them.
Stefan: “Steve, I agree with the notion that business is more important than IT, and the many, many IT folks should work to learn a lot more about the actual business value and their part (or lack of) in it.”
Now this is something worth critiquing. It’s been very fashionable and responsible-sounding to say this since the 90s, but taking the business too seriously presents its own risks. For one it makes architecture and uniformity much more difficult to achieve - businesses processes are little more than collections of special cases. Businesses are also fluid; by the time you articulate the business as process/service/domain, chances are the business will have changed. If anything businesses don’t take technical and operational issues seriously enough and this introduces risks to projects, especially large works/multi-year ones. We’re not sufficiently commoditised as an industry yet to be entirely business driven.
Mike: “How do you handle the problems that WS-splat supposedly addresses, such as multi-hop reliable messaging, integration with back end systems that don’t use URIs, etc.”
I’d dispute multi-hop messaging is ‘addressed’ (good pun Mike) outside implementations. For starters, tracking data in a standard way - how do I implode the services and hops to provide a unified view? Links please, if I’m speaking out of turn.
As for non-uri identifiers this is a problem, but not a killer problem. Any serious enterprise integration involves id mapping - and URIs don’t introduce many (if any) new issues. It can be dealt with by labelling domain objects with URIs, or using a non-incrementing (distributable) pk as a component of the URI - eg I use md5 hashes in URIs as the’re very practical to use in any kind of storage backend.
Granted, the “business first” argument is often nothing more than responsible bullshitting, and it can be used to justify even the most absurd decisions. Still, I’ve more often than not seen IT decisions being made without any understanding about the overall purpose — which is, always, to contribute to the company’s short-term or long-term profit. To distinguish between what’s your core business and what’s a commodity, it helps an awful lot know what your core business actually is.