More on the state of Web services...

Don posted to add his two cents to the conversation with Michi. He points out that not dictating a programming language binding is an advantage, and I completely agree. He also mentions that he finds WS-ReliableMessaging increasingly interesting. I should have included that spec on my list of the things I think are most important in the new stack (although I'm not sure it would have changed the model we used in my last project, as Don suggests, since RM doesn't necessarily imply durability). Finally, he points out that Indigo (a) won't hide XML message bodies if you want to see them and will hide the details of the protocols if you don't want to see them. Both are very good things.

Michi also posted a lengthy comment laying out his perspective on why past middleware solutions have failed, and I think it's a pretty reasonable assessment. He also predicts a similar failure for Web services, which I think is less reasonable. There are a lot of smart people with a lot of distributed systems experience working on this technology and I have faith that it will be successful. It may sound like I doubt that sometimes when I speak out about on the overall direction, whether developers should see XML, the complexity of the interactions between protocols, etc., but in general that's just a way for me to help make sure the issues I think are important are on the table, helping to shape the conversation and, hopefully, the technology.

Finally, Mike commented, asking whether things really were that complicated. Frankly, I go back and forth on this question. Sometimes I think the answer is no, they aren't. The fact is, if you use WSE today, you have APIs that will let you deal with messages as XML or objects, build bindings for additional transport protocols - exposing as much or as little of the details as desired, use the core WS-Sec* functionality, build intermediaries, and use policy to control  your app. With WSE in hand, you can go out and build some very cool things. If they add reliable messaging, an interoperable TCP binding, and a more efficient way to handle large messages, then WSE is everything that I want today. Then I talk to a developer who doesn't know a lot about how SOAP works, what intermediaries do, what the options with WS-Sec* are, etc. and I think the answer is yes, because their eyes glaze over and start to roll back into their head.

I think there's a good analogy here to (D)COM. If you knew how it worked, you could start with a blank file, write the necessary C++ code, configure your machines to allow access and you were off to the races. But if you didn't know all that stuff, you were stuck. VB's COM support changed that. If you worked in VB, you couldn't do everything, but you could do a lot and, more importantly, you didn't have to know all the details (though if you kept someone around who knew all the details, you found it very useful). I think the same thing will happen with WS. Some of the people looking at WS-* today are ready to dive in, learn a ton of detail, deal with changes as they come. Those people can take WSE and run with it. Some of the people looking at WS-* are not ready to dive in, either because they don't have the time to invest or they don't have the interest. For them, a tool that does more of this stuff transparently (like VB did for COM) is the answer. Hopefully that will be Indigo, that's certainly one of their goals.