Indigo: WS-TheEmperorHasNoClothes

From MSDN Indigo FAQ (emphasis mine):

J2EE is deeply rooted in a classic distributed object architecture (based on EJBs)—an architecture that has proven to be complex and brittle for Internet and enterprise-scale business integration scenarios. Service-oriented development is a fundamentally better way for building connected systems. But with its distributed object architecture, J2EE is not designed for service-oriented development. Indigo builds on .NET's leading-edge support for Web services, and provides a complete service-oriented programming model and integrated communications infrastructure for building and running connected systems in a productive and reliable way.

From MSDN article on developing with Indigo:

With this [stateful web service] model, private variables can be persisted and properties can be employed. Essentially, true object oriented programming is brought to Web services. Those who have used client-activated objects in .NET Remoting will find this familiar; however, this is completely novel for those used to ASP.NET Web services.

Que? On the one hand OO systems like J2EE Enterprise Java are "brittle", and on the other "true" OO programming is a good thing for developers of web services. They seem to be implying developers can have their OO cake and still adhere to Indigo's avowed goals to separate service contracts and semantics from the underlying object model. I can't see how this can happen if they're encouraging the OO mentality to persist. I also find it a little bemusing that they're actively promoting one of the key things that WS advocates abhor: stateful services.

This sort of crap is liberally sprinkled throughout MS's descriptions of why Indigo and web services are so superior to the previous One True Way of building services. They also only use J2EE as a punching bag, neglecting to note that apparently they've realised DCOM now also sucks.

While I'm certainly not the only one wondering whether the emperor has no clothes, I have to wonder whether even some of the senior, non PHB people at MS are having trouble working out why exactly they're shifting from RPC via DCOM to RPC over XML.