What Service Orientation is NOT!
In his wonderful reply to my pre-Xmas post on different perspective of Service Orientation where I tried to convey an alternative way of thinking about the subject, David Ing takes a stab at stating how he would define Service Orientation to his grandmother:
"I think it is ok to say 'SO is an integration patterns approach based on interop'"
Now, this raises a number of questions: Why, David, are you trying to have this debate with your Grandmother? Don't you think that your Grandmother will simply agree with almost anything you say anyway ... if yours is anything like mine, I'm sure she would! :)
While your grandmother may agree with you, I'm sorry, but I don't buy it.
Just as I don't believe that SO is an architectural paradigm (what new architectural concepts does it provide), I don't believe SO is one or more "integration patterns". What patterns does SO introduce that aren't already in wide use elsewhere?
The problem I see all too often is that everyone assumes that SO == interoperability.
Interoperability == the ability of two systems to interoperate ... to exchange data and communicate.
Alas, they are two orthogonal concepts. I can, for example, build an entirely Service Oriented system using COM+, Remoting or TCP if I was willing to build a lot of code and forego most forms of interop.
I have seen many state that you can't build a performant service oriented system and yet I see customers and other teams here at Microsoft do it all the time. Often, the perceptions people have about the performance of Service Oriented systems are based on their beliefs of the performance of Web Services. Again, another orthogonal issue.
When I first moved over here to Redmond, I used to enjoy explaining what things were and how things worked by discussing what they weren't and didn't. Alas, this approach rarely found favour in Redmond and so I stopped doing it (eventually!). As I posted recently though, Steve Swartz' was recently Scobilized and discussed SO by explaining what it wasn't. Eagerly taking his lead, I'd like to propose my $0.02 to list things that I don't believe SO to be (incomplete and in no particular order):
SO <> a technology
SO <> Web Services
SO <> SCA
SO <> WCF/WWF/WIF/WTF
SO <> an architecture
SO <> SOA
SO <> EDI/EAI/ESB
SO <> a sysytems design methodology
SO <> world peace
SO <> the end of the story ... it's just the next evolutionary step
And for those that have never tried scrumpy before, I can (some would say plainly) support David's warning: "Remember kids - that stuff floating in the scrumpy will catch up with you in the end". Maybe I am living proof. But sometimes I wonder whether others were more regular consumers than I :)
