After an enjoyable and extremely educational 2 1/2 years on the core XML team in SQL Data Programmability at Microsoft, I've moved to a position in the Connected Systems Division's Interoperability unit.  Responsibilities include representing Microsoft on the W3C, helping with web services standards partnerships, and generally helping the world understand the method behind the apparent WS-Madness, or at least the subset of it that Microsoft endorses.

"Huh?" you might ask.  Why voluntarily join the doomed crew of WS-Deathstar?  Or maybe the WS-* crowd are not evil, they're  weenies who get sand kicked in their faces? As with XML itself, the point isn't whether "any damn fool could produce a better data format" it's whether the web services specs provide a pragmatic foundation for actual interoperabiliy. Just as XML quietly became pervasive while its numerous limitations were being flamed by the cognoscenti, the WS technologies are quietly taking root in all sorts of places where interoperable identity, security, reliability, management, etc. concerns trump geek aesthetics.  There's no disputing that skillful people can implement systems with all these properties without WS-*, but there is much to be said for building these capabilities into the infrastructure of Windows, .NET, Websphere, Java, Apache, etc., in a standardized and interoperable way. I don't pretend that goal has been achieved, but I'm convinced its achieveable.

 Another part of my reason for moving is that LINQ to XML is close enough to being done that I can declare victory and move on, hoping that its success will rebalance my karma after the beating it suffered from my role in DOM :-).  I'm still involved in the project to some extent, backing up Ralf as he assumes the role of LINQ to XML PM and doing my bit to evangelize the LINQ XML story in Orcas and Silverlight.

But there are some more substantive attractions to WS-Darkness.  First, the overall WS-* framework doesn't deserve its bad reputation among XML and Web geeks. It's hard to call anything designed by that many committees elegant, but there is an underlying conceptual integrity in it that I've come to appreciate over the years. That's not exhibited by all the specs, to be sure ...don't ask me to defend XSD or WSDL!  There's no disputing that current interoperability above the SOAP level can be problematic, but much of this can be traced to incorrect implementations and problems mapping XSD to underlying object systems. It will take longer to get full interoperability at the higher levels of the WS stack, but I'm convinced that it will be much more practical to complete the work that is underway than to start over with some new paradigm, or to return to the bad old days of one-off data contracts and armies of consultants needed for everything.

 The stock phrase in the WS-* specs is that they are "designed to be composed with each other to provide a rich messaging environment".  I think the term "Aspect-oriented messaging" better captures the underlying architectural principle that the WS specs can work separately or be composed together to provide a variety of message services: 

[SOAP 1.2] provides a much simpler and more powerful aspect-oriented mechanism for extending the SOAP processing model. New aspect-oriented features can be added to SOAP by defining additional SOAP headers and how to process them. Such features can range from transport-level features such as security and reliable messaging to business-level features such as spending-policy enforcement to personalization and differentiated service. Bottom Line: Users who consider SOAP to be just a low-level RPC mechanism should review SOAP v1.2 to understand its potentially profound architectural implications for distributed computing.

"Ironick" indeed, that's by the same Nick Gall whose Web of Services for Enterprise Computing whitepaper got so much link love from the WS-skeptics. Gall may or may not have come to regret his previous enthusiasm for SOAP's architectural principles, but in any event the main point of his position paper isn't  isn't so much about WS architecture as it is about W3C's philosophy: "While there is nothing wrong with [the various WS-* specs]  --in fact there is great value in having the major middleware vendors finally agree on middleware standards after so many years of proprietary middleware protocols--the problem is that such work has nothing to do with web architecture or the W3C."  That may be a defensible position, but the fact remains that the W3C management and staff have worked hard to give at least some of the more fundamental and web-related WS specs a home at that organization.  

Which leads to my second point:  "It's a tool, not a religion".

I have spent time around job sites. I can promise you that you'll find circular saws, chop saws, and table saws. Is there overlap in functionality and potential application of these saws? Absolutely. Why have all three then? Well, because each is particularly good for certain types of cutting chores and less optimal for others. Contractors, like mechanics, want a broad set of tools available so they can have the optimal tool for each task.

Why then do we, as software engineers, have to work so hard to reduce our toolbox to the ultimate tool? There is this tendency to look for the Swiss Army language with supporting framework that will be the optimal solution for every problem in the world. The simple reality is that such a language and framework can never be created.

I've always been annoyed by the zealotry manifested in the "SOAP vs REST" debate.  The overhyped WS marketing and the RESTifarian pushback in 2001-2002 or so had the effect of people "flipping the bozo bit" on each other wholesale.  We're just now seeing some exploration of the sensible middle position -- the native Web technologies are powerful and deserve first class support in the services-oriented tools and specs, and at least some of the WS technologies are useful on the Web as well as the enterprise, especially in the realm of identity and security.  People on the WS side are finally understanding the the potential of the SOAP GET binding, and maybe the REST folks are starting to understand the oft-maligned WS-Transfer  ("HTTP over SOAP over HTTP") is not quite so pointless in a multi-hop, multi-protocol world.

Finally, the supposed coup de grâce in most skewerings of WS-* is to point out the complexity of the web of specs and frameworks.  The best response I've seen is by Charles Zedlewski:

But I think the kvetching over the WS-* complexity is pretty overblown. What struck me looking at Innoq’s diagram is how similar it is to the Java class library (or any other major language’s class library for that matter).

...  you don’t have to learn all the inner workings of either standard to make good use of it. You either:
1) Learn and choose to leverage only the most useful bits of the standard that are relevant for your project. ... Or you:
2) Utilize some combination of tools and platforms that hide the complexity of the underlying standards.

Anyway, I'm having fun getting back up to speed on all this and getting back in the blog debates I swore off awhile ago.