Sam Gentile says:
[W]hen people bitch about WS-*, I don't get how its not obvious that "the main characteristics of Web services is communication over unreliable communication channels such as the Internet employing unreliable data transfer protocols such as HTTP, SMTP and FTP" and many of us need things like WS-RM and other standards to build real service-oriented systems that actually do something.
Since I've stopped being polite about WS-*, I'll bite:
It's just not the case that "real service-oriented systems that actually do something" require the WS-* stack. Very reliable, very scalable, very large systems accomplish transactions over Internet protocols without using WS-RM. iTunes has now executed over a billion transactions without using WS-RM. And, subjectively, while Internet protocols are technically unreliable, they are reliable enough for me to order books from Amazon, track packages via FedEx, send my articles and invoices via email, etc. Professionally, they're reliable enough for a POX system I architected to transact \~\$100M a year in airline tickets.
WS-* advocates will probably say that the transactions involved in the examples cited above are relatively simple -- high volume, perhaps, but simple. "Financial services! Trading partners! Supply chains!" they will say. It is to these which, for years, I gave a "To be sure..." exemption. "REST works in most situations," I would say, "Although, to be sure..." and then I would capitulate. Perhaps with a high-enough volume, or a large-enough amount of money, or a time-sensitive enough clock, or a complex-enough transaction, one needed WS-*.
I no longer concede that. I say that, six or seven years into the Web Services era, the onus is on the WS-* advocates to prove the need, because the advocates of KISS approaches have, I think, amply demonstrated the viability of their approaches.
Further, let's posit for the sake of argument that reliability and re-ordering may be problems. I say that, in both those cases, the solution lies in higher, not lower, abstraction levels. If reliability is a problem, implement some form of visible ACK/NACK functionality (if you think about it, the idiom of "shopping cart checkout" that has evolved involves just such a higher-level ACK/NACK: "Press submit to finalize," "Here is the page acknowledging your order; an email has been sent to you acknowledging the order as well."). If reordering is a problem, first check for excessive conversational state, and second, put a frackin' messageOrder element in your XML. Visible, visible, visible.
Would it be better to have such functionality "for free" in a library or tool? Would such functionality be burdensome and error-prone? Sure, why not? All programming is burdensome and error-prone. But I assert that the odds of being stumped by a problem are lower in a Keep It Simple Stupid, highly-visible, higher-abstraction-level solution than they are in a WS-* architecture involving more than one vendors' service stack.
Further, I would argue that WS-* is unlikely to ultimately triumph for the very reason that it's attempting to inject a low-abstraction-level layer between a (posited-for-the-sake-of-argument) insufficient infrastructure and the business-programming domain. That may work for a single vendor, with a unified analysis of the supposed shortcomings of the infrastructure and the business-programming domain. But with multiple vendors, who not only don't share a single view, but whose view of the business-programming domain is inherently biased by their commercial interests, the confusion and slow progress that has characterized WS-* is more likely than not to continue.