More dark clouds gather; storm signals include the general trashing of the whole WS-* stack by Gartner’s Nick Gall, the continuing broadsides (latest here) from Pete Lacey, and Give It a REST, a solid piece of argument from Larry O’Brien. But I think the real take-away, while a little subtler than “WS-* is broken”, is becoming pretty obvious.
Start with Services on the Web and Web Services, a position paper from British Telecom. I quote:
So the SOAP “stack” is a mess, and currently only the simplest of services are able to interoperate. However we believe this situation is likely to improve long term, in part due to the adoption of profiles published by the WS-I, but mainly due to the emergence of a reference implementation in the form of Microsoft’s WCF.
More evidence: Our Robin Wilton recently asked Can Sun do WS-*?, which is about our “Project Tango”. The idea is to work with Microsoft to shake things down so that Java’s WS-* interoperates with WCF, their implementation.
It’s not as though there’s a lot of choice. Basically every .NET-centric developer now has WCF in their hands, and the tooling is good, so it’ll be easy for them to expose things via WS-*, so they will. Because of the basic brokenness of WS-*, it’s silly to expect this to just interoperate with other implementations; you need a fairly major bipartisan effort to get any two instances of this booger to play nice. Microsoft’s customers and Sun’s customers are pretty well the same people, and they expect these things to work the way the architecture astronauts claim they will.
If there were any startups betting their future on WS-* they’d pretty well be toast, because they’d have real trouble getting attention from either the .NET or Java teams. But that’s OK, because startups are generally too smart to bet on this kind of crock.
WS-*? In the real world, it’s about being able to interoperate with WCF, and while that’s a worthwhile thing, that’s all it’s about. It’s not like HTTP or TCP/IP, truly interoperable frameworks, it’s like DCOM; the piece of Windows’ network-facing surface that Microsoft would like you to code to. For now, anyhow; it’ll be at least as easy as DCOM to walk away from when the embarrassment gets too great.
Contributions
Comment feed for ongoing:
From: Davanum Srinivas (Feb 05 2007, at 02:32)
Tim,
I guess you have not heard about us (http://ws.apache.org/axis2/ and http://wso2.com/). Hmm, i wonder why on earth the JAX-WS RI is publishing data w.r.t Apache Axis2? (http://weblogs.java.net/blog/kohsuke/archive/2007/02/jaxws_ri_21_ben.html)
thanks,
dims
[link]
From: Paul Downey (Feb 05 2007, at 07:02)
Cool! I've been citated by ongoing. Well almost ;-)
I worry at the amount of good money being spent after bad on WS-*, but mostly the way the "Web" in "Web services" is still misunderstood by your average Joe Soap.
Shame Sun didn't submit a paper, but hopefully Marc will be there to impart some much needed sanity to the discussions.
[link]
From: Mike Champion (Feb 05 2007, at 09:01)
I REALLY have no dog in the WS-* fight, so please take this as a plea for help understanding the world we all live in and not advocacy. I agree with most of Nick Gall's piece about the mismatch between WS practice and Web theory. People such as Don Box who helped launch WS-* seem to be spending more time worrying about the Web these days. On the other hand, I'm not so sure that the Web in practice is as averse to RPC-think as many in the REST camp believe. Don't many "Web 2.0" apps tunnel HTTP as shamelessly as WS-* does? Clearly what we have is a primordial soup with lots of critters swimming around evolving their little memes away. I'm not going to predict what emerges out of the goo.
What I do wonder about is why, if this is such a mess, it is that so many big companies are spending SO much on it? One might argue that MS and IBM are doing it out of pride, or an arms race mentality. But if there is no "there" there, why is Sun working so hard in this area? As Robin Wilton's post makes clear, Sun's work is very solid, succcessful, customer focused engineering.
OK, maybe WS really is a mess that is perpetuated only by fear of embarassment. A rival hypothesis is that it addresses -- still imperfectly -- a deep need among that common MS - IBM - Sun customer base. Consider an analogy: It took the "XML stack" close to a decade to *really* meet its interop promises; it also has an embarassing glut of non-implemented or non-interoperable "standards"; there were plenty of steps in doo-doo such as the XSLT-ish support in IE5; and let's not even talk about the XSD interop mess that is only slowly going away. But nobody (except the Web 2.0 hipsters maybe) is walking away from the mess, simply because the real world demand for true data interop is so great.
Likewise, by analogy, Microsoft implicitly (and perhaps unintentionally) did the world a favor by defining the core set of XML specs that really must interoperate -- XML 1.0, namespaces 1.0, XPath/XSLT 1.0, and XSD 1.0... while taking a tag soup approach to HTML but insisting on well formed RSS-ish stuff. Obviously lots of people would prefer a different base set, and I recall some Java people seeing this as an evil plot to subvert the ideal of code interoperability by hyping data interoperability. Still, this seems to have defined an achievable subset of the whole XML space that all have focused on, to the joint customers' benefit.
Maybe the same thing is happening in the WS world, with the WCF-mandated specs being the de facto interoperable core. Now it takes bilateral negotiation to make interop work, but do you really want to bet that the *engineering* talent focused on the interop problem at Sun, IBM, and MS can't succeed? I'd bet that *if* there is a strong unmet demand for service interop the way there was for data interop 10 years ago, the engineers will succeed, whatever us pundits and standards geeks might think today, and whatever mighta/coulda been If Only They Had Listened.
So what is the counter-hypothesis in more detail? Is there no real demand for service-level interop, and SOA of all flavors is just architecture astronautics? Is nobody in the real world getting enough benefit from SOAP, etc. and it's all a house of cards? Is the complexity of the *core* WCF-mandated WS stack really too great to be implemented? Are all those people using enterprisey ERPs, MOMs, etc. happy enough with their current world that they won't pay for something better? Or will they really find that refactoring their systems with URIs, POX, minimal operator sets, and "hypertext as the engine of application state" works better than all that enterprisey crapola?
[link]
From: Tim (Feb 05 2007, at 21:52)
Speaking as one who helps implement "interoperable" stuff in the field between .NET and IBM's mainframe world (though no actual WS-stuff yet), I can tell you that there is a cynic's view to why they push this so hard: it makes money for their services organizations, who are only too willing to come in (for money), analyze your issues (for a little more money), and set things up so they "work" (for of course, quite a bit more money).
The pieces for developers may be decent, but the documentation on configuration and implementation, especially given that the names for things are often different on each end and sometimes a parameter needed on one end is not anywhere intuitively obvious at the other, are not. For some reason (see above) the support organizations don't always want to hand you a simple step-by-step document written by someone who's _done_ it but rather want to follow a script starting from zero, and try to gather as much information as they can because they have little to give: _they_ don't know how to make it work either, they have to get to level 2 or level 3 support and get back to you.
[link]
From: Karl Waclawek (Feb 06 2007, at 07:22)
What bothers me about most of these Enterprise vs Web Architecture discussions is that no-one bothers to give good heuristics for what applications should be developed in a web style and what apps are better of with other types of architectural styles.
Karl
[link]
From: Eric Newcomer (Feb 07 2007, at 10:03)
Tim -
Good discussion, although somewhat one sided. I have been raising the basic issue at W3C meetings for more than a year now, so I am very pleased to see that the Workshop will finally be happening at the end of the month. I look forward to a lively and hopefully productive debate.
I suspect, as is often the case in long running disputes of this nature, that both sides are correct to some degree. In at least two of the discussions at W3C meetings we have debated the proposition that the requirements of enterprise IT systems can be sufficiently met by Web based technologies. The answer appears to be no. HTTP and URIs (plus content type) may be great for accessing information but not so good for updating it.
Web oriented folks should easily understand the main reason for this -- the constraints behind REST that allow it to scale worldwide omit things like persistent communication sessions (on purpose of course) that enterprise IT shops rely on for the QoS attributes of their mission critical systems. The systems on which they depend to run their businesses and process the world's transactions.
It does not appear that a single software architecture is capable of supporting both goals - worldwide scalability and mission critical transaction processing.
However there is a big BUT here, which is that the Web's "mega sites" have indeed managed to accomplish this. EBay, Amazon, Yahoo, Google, MSN, etc. They have done so basically by customizing Web technologies. So it can be done.
But what about companies whose IT infrastructures predate the Web? How do they manage to construct the bridge?
Your point about integration scenarios being sort of artificially created in order to sell services is a bit cynical. It's possible that some integration vendors have that strategy, but others of us are working hard to deliver product based solutions.
However I suspect the greater culprit is competition in general. Meaning vendors prefer to compete to become a "sole supplier" to customers and focus on that rather than developing compatibility among product offerings. I suspect it is this aspect of commerce rather than anything technical that really gets in the way of the interoperability solution everyone is looking for.
I've been trying to contribute in varying ways for more than 15 years to the solution to enterprise software standardization. I actually think this is the big question here, not whether REST or WS-* is better.
The cost of delivering new applications and products to market is much higher than it should be. The cost of not having such standards in place much greater than the cost of imposing them would be. But who really benefits from real standardization?
One thing I said when I first raised this issue is that solving the problem of enterprise software standardization - which is what I really think we're up to, or should be - is of much greater significance than the Web (at least economically, not socially tho).
Eric
[link]