I'd like to start a separate thread on what the real problems of WS-* are from a developers perspective that continue to fuel the fire on these debates. That is, rather than continue to say whether REST is better than WS-* or not, lets talk about why there is a level of frustration with WS-*. I think Ashraf Galal's comments on the goals of WS-* with respect to A2A versus the goals of WOA captured things quite well.
From what I've seen in working with a variety of developers, it seems that things fall apart because of the strong movement toward a WSDL-first, or even XSD-first approach. Erik Johnson made a similar comment on Stefan's blog. Building WSDL and XSD by hand is something that developers loathe. It's not easy to do, and many of them question the ultimate value in it. Odds are that they will still need to create a human-readable user's guide anyway, and many wonder whether that is sufficient. Add to this the fact that there is a distinct level of distrust (which is unfounded in my opinion) on anything that is generated. Some will argue that generated code increases coupling, which I don't agree with. Generated code may increase your dependency on the tools, but it doesn't necessarily increase your coupling in your solutions. Compilers generate code. Nobody complains about them anymore, so why are we so averse to using generators in other areas? There's a natural maturity cycle with these things, and always a potential to use them wrong, but tooling is what makes things more efficient. I've yet to run into an enterprise that wants to spend more time writing custom code. Coming back to the original premise, the theory goes that when you simply add an annotation to your code that says "give me a WSDL representation of this service" that you're now going to get something where the interface is tightly coupled to the your implementation. If the thing you annotated was already an interface, rather than a concrete class, is this really the case? Yes, there is greater risk that you may be exposing platform specific structures, but it seems that a little education or even some automated testing tools could easily capture this. As for the complexity of the WS-* stack, this is another argument that doesn't hold a lot of water for me, mainly because I don't see very many developers that have to deal with it. If the people working in the standards bodies want to continue to come up with standards for more fringe items that are of importance to smaller communities, that's fine with me. If I don't need them, I can simply ignore it. Someone else may need it, and they should pay attention. It only becomes problematic if I have to worry about them when I have no need for the capability. For example, if I don't need reliable messaging, I don't have any extra work to explicitly state that I don't need it. So, is the problem really just the complexity of using XSD and WSDL? If it was far easier to do work with this, would life be easier? Again, this is not directed at the REST crowd. This is directed toward the people who are simply doing XML (maybe only on the response side) + HTTP instead of WS-*. As previously stated by many people, these developers aren't writing REST, although I'd bet a majority of them think they are. -tb
