Death isn't on the line, so I feel safe going against Sam Marcuccio in this
discussion. I'll start at the bottom of Sam's post and work my way up. The last line says "The really funny part of all this is, based on the argument, you'd never guess which on of these guys works for Microsoft". I know there was a smiley face after that, but I'm totally confused. To the extent there is an official Microsoft position on service orientation, Rich's
position is it. Sam thinks we're arguing over semantics. He's right, but not in the sense he means. The argument isn't over semantics in the common, rather narrow, sense of the meaning of particular words as much as it is over the use of language to communicate ideas. Rich and I have very different ideas about how to use language to construct useful models for describing software design. Sam also thinks that my position is technology centric and nothing could be further from the truth. Using WS* technologies doesn't make you SO.
Sam says he agrees with just about everything Rich Turner had to say about SOA, but I wonder if Sam ever read Rich's comments
here. Rich says that the four tenets are mandatory. This is the crux of my disagreement with Rich and his co-workers at Microsoft. It's also where I think Sam misunderstands Rich's position. If you believe that the four tenets are mandatory, you believe that they define service orientation rather than describe it. If the four tenets
define service orientation, then it's obvious that there is no such thing as SOA. No real software architecture can be defined by those four tenets. If, on the other hand, you believe that the four tenets represent a description of service orientation, the situation is completely different. Architectures can be described as more or less service-oriented and evaluated on how well they meet the needs of their users. As David Ing has
described so well, the four tenets can't be taken as revealed truth by those of us who actually build enterprise systems.
If Rich's position is correct, then every single application built with Indigo will be service oriented. I can guarantee that not every Indigo application will have the wonderful qualities from Code Complete that Sam describes. Indeed, given the heavy promotion of [DataContract] and its related attributes, I can guarantee that most Indigo apps will be more tightly coupled than the typical ASMX application is today (and that's really disappointing). Not because [DataContract] will inherently create tightly coupled systems, but because it will enable tightly coupled distributed object designs to claim service orientation while still suffering from all the failings of distributed objects. The Indigo team's "we learned SO so you don't have to" attitude will inevitably result in applications that won't get the full advantage of the Indigo platform.
Posted
May 28 2005, 04:51 PM
by
john-cavnar-johnson