MS Patterns & Practices are Shallow

The Microsoft Patterns & Practices group released a set of SOA principles. I was eager to see what the brains came up with but found myself beyond disappointed; I found myself actually in awe of their incompetence. Perhaps these are tough words but I'm so extremely disappointed in the group-think that is currently going on in the SOA world that I feel compelled to point it out.

First, the show can be found here:
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032262538&CountryCode=US

MS stated four primary tenets to SOA. My first thought was "holy smokes, they got it down to four?!!!" Well, here they are:
1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not class
4. Service compatibility is based on policy

Boundaries are explicit - yep, hard to argue. But what does this actually say? How about this instead: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."

Services are autonomous - Most people know that I firmly believe that "services are not autonomous", they are synergistic. Services work together in a 'service ecosystem'. Services will influence each others metadata. In no way are services autonomous.

Services share schema and contract, not class - I believe the point is that you want to share data using self describing, self validating, extensible schema systems that are ubiquitously deployed. That's cool - use an abstract typing system.

Service compatibility is based on policy - Yes. Agreed.

The patterns group then identified some "anti-patterns" or things not to do:
1. Avoid CRUDy interfaces. Don't use the CRUD pattern.
Guys - this is so wrong I felt sorry for them. After listening to them babble on this for a while all credibility was lost. I think what they meant to say is "Use CRUD, but don't violate the age-old wisdom around fully encapsulating and abstracting the persistence mechanisms. "

The second anti-pattern was avoid "loosely goosey" interfaces. The example they used was something like "runQuery(qry)". This one is tougher. If you really don't know what query combination needs to be run at design time then... you pretty much need something like "runQuery(qry)". This gets into a real interesting space that I wish MS would have talked about. Is it ok to pass XPath statement? Is it ok to pass an XQuery command? What is the right way to solve the runtime predicate problem? Surely the answer isn't "don't solve it". What about the surrogate key problem - where the only primary key is vendor specific key?

The list goes on and on... MS has the brains to do this stuff right. I wish they would ask some of their smart people to help the patterns & practice group get this stuff right.