I almost never listen to podcasts. I don’t commute, and just sitting in front of my computer, I tend to get distracted. But I did manage to hang in through all but the trailing couple of minutes of Jon Udell’s A conversation with Steve Vinoski about services, the enterprise, and the web. Since I’m called out by name, I think I should probably respond.
Jon dominates this conversation, and he has an agenda: the REST vs. WS-* dispute is pointless, there are places for both approaches, and Why Can’t We All Just Get Along? Steve is mostly ready to agree, but the discussion visits some useful and interesting places as they toss it back and forth. Steve is regretful that in the early days of WS-* a lot of the people involved didn’t really understand the Web. He points to Apache Axis2 (which actually I hadn’t been watching) as “the awakening of the enterprise crowd to the Web”. Interesting stuff.
I’m portrayed as the black-clad anarchist. Jon: “Tim Bray, for example, you know, you get the impression from Tim, ‘Let’s just tear the whole thing down, it was a complete waste of time.’” Uh, not so much. If you want to know what I think, read Pete Lacey’s It is Hard to be a Dove and my own SOA and WCF.
To wit: Don’t use WS-* unless you need to interoperate with existing WS-* deployments, in particular Microsoft WCF, which is the twenty-first century version of DCOM: the Windows network API they’d like you to program to.
So, no, I don’t want to tear anything down, but I also don’t want to just get along: I want to start building developer tooling around REST, or what Greg Papadopoulos calls RSWS: “Real Simple Web Services”. I think work to date on WS-* represents a sunk investment; use it when you have to (we at Sun are shipping the tooling to let Javaland talk to WCF) but not as the basis for anything new. Because the design of WS-* just has too many problems to be suitable for enterprise use, in the general case.
Jon presents the WS-* party line that REST is all well and good when you’re doing simple point-to-point stuff; but when you have sophisticated policy-based security that you need to manage across a network fabric rich with intermediaries, you need more, and that’s what WS-* is for.
Well yes, except for that kind of policy-driven intermediary-rich environment remains, more or less, science fiction; I personally have never observed such a thing actually working, and I have little faith that the WS-* theorists, meeting in their invitation-only back rooms, cooking up and superseding specs, are going to get it right first time based on zero real-world experience. Particularly with an abomination like WSDL in at the very core.
Hey Jon, our criticisms of WS-* are specific and have to do with issues of process and stability and technical quality and a demonstrated lack of interoperability. It is badly-engineered technology, using it will increase the likelihood that your project fails, and it is not suitable for use by conscientious IT professionals.
Unless you need to talk to DCOM 2006 WCF.
Contributions
Comment feed for ongoing:
From: Jon Udell (Feb 27 2007, at 16:16)
"I want to start building developer tooling around REST, or what Greg Papadopoulos calls RSWS: “Real Simple Web Services”."
I should probably get that conversation transcribed but until then, I'll paraprase a few of our points like so:
It's too bad that the WS-* thing happened as a big bang explosion that attempted to transfer a lot of pre-existing and valid enterprise software know-how to a new and not-well-understood domain.
It's also too bad that the colonization of that new domain did not happen in a more exploratory and iterative way. The early WSDL- and RPC-oriented tooling tended to obscure that possibility.
It's also true that, as Sam Ruby has elegantly shown, SOAP can be used in a RESTful way that does not markedly differ from any other kind of XML-over-HTTP scenario w/respect to payload, but that can inject various kinds of enterprisey bits into the header.
From that perspective I suspect that SOAP and RSWS wind up being roughly the same.
[link]
From: Jeb (Feb 27 2007, at 17:15)
I'm no fan of WS-* either, to put it mildly, but I've encountered it in the wild in situations where I believe a conscientious IT professional would reasonably choose to work with it and that were not WCF-oriented. Two cases spring to mind:
A lot of "enterprises" that jumped on the SOA bandwagon early on have already deployed reasonably large WS-*-based architectures, and sometimes, accessing a bit of this is critical to solve an immediate problem. Specifically, we've seen it with financial institutions. Things like security pricing functions get exposed as WSDLs that describe a set of SOAP operations to submit a security and get a price, e.g. We've encountered cases like this where the published service is the only way to access that bit of code, and that bit of code is critical and not going to get reimplemented or republished in the near future. In these cases, consuming the WSDL and communicating with the service(s) it describes is your only chance at non-failure, even if the failure probability is still high due to the insane non-interoperability of the various implementations.
Another huge, non-WCF place that WSDL (and I assume SOAP but I don't remember off the top of my head) gets used and makes sense to develop against is Salesforce.com (they also have the best architected for-mass-consumption WS-*-based services that I've seen). Salesforce.com is more a less a platform in its own right at this point, and for the time being, WS-* is the path of least resistance for building applications on top of it.
Tim, how much do you talk to those 'enterprise' guys? I met some guys from a certain large technology company recently that seemed to believe that somehow the world would converge on a WS-I-like set of features in SOAP and WSDL that were 'ok to use' and that would solve the bulk of the interop issues. Given that I definitely get exposed a lot more to the RSWS camp's opinions (and that I generally spend a few hours a week swearing while reading WS-* specs), I was really surprised by this; I'd taken it as a given that most thinking people had realized that WS-* is a mess but that some, like me, were resigned to dealing with it for practical reasons. These guys seemed like really smart and reasonable people, though. Basically, their attitude was similiar to that of people using C++/STL a few years ago: "MS doesn't support this, SUNWSPro doesn't support that, so don't use those features and you'll be fine."
My punchline is that the "WS-* vs. REST dispute" isn't going to change the fact that we'll be supporting WS-* stuff for a long time, and I'd like to think of myself and my coworkers as conscientious. Also, I just wanted to point out that there are other things a reasonable person may need to talk to via WS-* besides WCF.
Jon-- I don't follow how "SOAP and RSWS wind up being roughly the same." It seems to me that SOAP and the RSWS mentality are pretty far apart in some fundamental ways. I don't know if this is the appropriate place, but I'm curious to hear your thoughts if you care to elaborate.
[link]
From: Tim (Feb 27 2007, at 17:58)
Jon: Yes, text would be great, I suspect it would immensely increase your reach, which would be a good thing.
Jeb: I think you & I & Pete Lacey are pointing in the same direction: use WS-* when you have to talk to WS-*. Good data points, although at the moment my guess is that WCF will constitute the majority of the cases. Having a look at the Salesforce stuff has been on my to-do list for a while. The Enterprise people I talk to tend to be refreshingly non-religious: do what works.
[link]
From: Joe Gregorio (Feb 27 2007, at 18:56)
REST and WS-* are both tools that have strengths
at different scales:
http://bitworking.org/news/125/REST-and-WS
Jeb: "Basically, their attitude was similiar to that of people using C++/STL a few years ago"
I remember that time in C++/STL; when the complexity was high,
everyone was shipping implementations with incompatible subsets
of the spec, and interop was a nightmare. Just a point of
information: that was about the time, and one of the reasons,
that Java took off.
[link]
From: Jay Carlson (Feb 27 2007, at 21:43)
Jon: yes, please, more text. I'm about one NPR top-of-hour cycle from work, and at that level of granularity it's difficult to put anything useful in there besides Carl Kassel.
As much as I abstractly like the idea of podcasting, I've found that I just don't have the patience for it as a general habit. For people who have lots of eyes-unavailable time, I'm guessing it makes sense. All I see is producer/consumer cost tradeoffs not in my favor.
I think it was Chip Morningstar who said that the reason the Web worked was the hope that the link you're following will suck less than the page you're reading.....
[link]
From: Jon Udell (Feb 28 2007, at 06:39)
"The Enterprise people I talk to tend to be refreshingly non-religious: do what works."
Yes, they're intensely pragmatic. One of those pragmatists, TN Subramamiam, I found here:
http://www.tbray.org/ongoing/When/200x/2005/07/06/Route-One
and subsequently interviewed myself for an InfoWorld story here:
http://www.infoworld.com/article/05/09/12/37FEsoaevolve_1.html
An excerpt which make a claim for a non-science-fictiony use of intermediation:
"RouteOne is required to maintain meticulous audit logs and would prefer not to have to encrypt all of them. So it’s using DataPower’s XML router/accelerator to selectively encrypt only sensitive items such as gross pay and Social Security number. Because it’s a standards-based intermediary, the DataPower box can straightforwardly modify RouteOne’s XML message traffic in this way, and it could be swapped out for another appliance that did the same thing."
[link]
From: Anton McConville (Feb 28 2007, at 06:39)
Thanks for the great post and the links. It is helping to make the overall story clearer for me.
A couple of thoughts though ... for me as a developer, I value having any 'service' based interface at the moment ... I'm frustrated at this point in time that they're still in such short supply - 'service orientation' is still blossoming. Now that I've been routinely building and using services, it has become easy for me to expect them to be available widely - but they're not always there in places I'd value them. Whether it be a SOAP or REST type interface, I think ( as a developer ) I could consume it and would value the availability as a priority over type of interface right now. ( This is maybe just admitting impatience! )
Customers/consumers too have an important say ... maybe they have a hankering for a particular kind of interface and I think their wishes ( however guided or misguided ) obviously influence the choice.
And an observation ...
We've been offering document based SOAP services from our Java solution ( as RESTfully as we can ) largely because EJB3 makes it economical - and they've served us well for our immediate needs - lots of reuse of the services across several languages and distributed components.
However, we've found that tooling in ( C++ and PHP for example ) for the Oasis security standards that are built around SOAP are not consistently available. I kind of like the security ideas they propose - they work for our scenarios - but we have trouble offering them because it seems to counter productively restrict consumption of the services to basically Java and some expensive commercial tools for other languages.
Thanks again for the great content, Tim.
[link]
From: Paul Downey (Feb 28 2007, at 11:32)
Sorry you're not here: http://www.flickr.com/photos/tags/wsec
[link]
From: Steve Vinoski (Feb 28 2007, at 11:59)
Hi Tim, just a clarification: your characterization of me saying that Axis2 represents “the awakening of the enterprise crowd to the Web" isn't really accurate, so that part of the podcast might not have been clear. It's true that I would agree that toolkits like Axis2, or better yet, Apache CXF, display some of that awakening, but I've never used Axis2 and probably never will, and so I'd never claim that the enterprise awakening is so severely limited to just that particular piece of software. Also, I'm not a fan of the Java language in general, or Java-based toolkits like Axis2 and CXF, mainly because I believe Java contributes, at least indirectly, to preventing the enterprise from awakening even further because it blinds developers to superior possibilities.
Speaking of superior possibilities, you can look at Bruce Tate's "Beyond Java" to also see evidence of that enterprise awakening, for example. More generally, the rising popularity of dynamic languages and their slow but sure creep into the enterprise is clear evidence of the awakening. As I write this, coincidentally, I'm sitting in the W3C Workshop on Web of Services for Enterprise, which Jon and I talked about in the podcast, and there are people in attendance here who a few years ago spoke out against REST who now seem to see its value. You can also see the awakening in the fact that enterprise folks are starting to seriously look at AJAX, Atom/APP, Ruby on Rails, Yahoo Pipes, and other such systems. These technologies are obvious cases of Geoffrey Moore's Technology Adoption Life Cycle and Clayton Christensen's "Innovator's Dilemma," where they maybe don't have all the bells and whistles as typical enterprise software, but they're much cheaper, much more flexible, and just get things done faster. They will thus eventually "cross the enterprise chasm" and will displace a lot of the overweight and overbearing approaches currently in favor within the enterprise integration space.
[link]
From: Tim (Feb 28 2007, at 12:59)
I was wondering when someone would mention RouteOne. That's an interesting application. They didn't need any futuristic policy-driven network fabric, they just had a business requirement for *message*-level security, and they used WS-Security.
I suspect that WS-S is one of the few pieces of good solid work in the WS-trainwreck that may live on, and there were good products from DataPower (now part of IBM) to help them build out.
But there were some other approaches they could have taken. By using SOAP, they opened up the possibility of having to deal with all the other weird stuff that could show up in the header, for example a policy element with MustUnderstand on it. They could also have just used an ordinary XML digital signature. These days, they might want to use JSON, particularly if the volumes are high, and in that case SOAP isn't interesting at all.
Bottom line: I'm still unconvinced, first of all, that the kind of scenario you postulated-a policy-driven network fabric with lots of intermediaries-is all that common, and second, that if it is, that WS-* as it sits now will be very helpful in addressing the problem.
[link]
From: Tim (Feb 28 2007, at 13:15)
Ouch, Steve, sorry. My hand-scribbled notes from listening to the podcast had that phrase "the awakening of the enterprise crowd to the Web" as relating to an Apache project that I thought was Axis2; I seem to recall you saying that some Iona colleagues were involved. I just now went and skipped back and forth in the audio again and can't find it, so assuming I got that wrong, I apologize. (Jon: text, pretty please?)
Whereas I still like Java, I'm a big fan of dynamic languages in general and generally agree with your whole second paragraph.
[link]
From: pwb (Feb 28 2007, at 19:23)
Having deployed a SOAP-based API suite, I cannot exagerate my hatred for it. It has set us back 2-3 years and driven the vast majority of our constituents completely nuts.
However, REST will remain completely hopeless until someone explains, in plain english, *HOW* to do it! First, there remains a great deal of disagreement about how RESTful stuff should actually work. Further, the only guidance we have is a dissertation that really doesn't give any practical direction.
[link]