Service Oriented Thinking
David Ing posted a great set of questions I'll paraphrase as "what this heck is this Service Orientation thing anyway? A Pattern?"
This essentially raises the question - if SO is not an architecture, WHAT IS IT? A good way to think about this is:
Do you remember when you first TRULY understood what Object Orientation really meant? I do. I was at University. It was late at night after a night out at The Turf (a great, but hard to find pub). I had partaken of one or two too-many pints of scrumpy and had ambled back home (a 4 mile walk which only took 5 mins ... somehow!) When I got home, I pressed play on my tape deck (no CD's back then! ;)) and The Black Crowes started playing. I was working on my dissertation at the time - a photorealistic ray tracer and was considering writing it in Modula2. At the time (1990), C++ was only just emerging commercially but the university didn't teach C until my final year and C++ was still years away from the syllabus. However, I'd already started reading the articles and the books - I bought and read Bjarne Stroustrup's masterpiece cover-to-cover the previous weekend and subsequently pored over it for weeks. So I had an appreciation of the concepts and syntax of C++ but I didn't yet truly comprehend the story. However, that night, whilst pondering the best approach to the implementation of my RayTracer, something clicked in my head. Suddenly it all just made sense. Data and behaviour encapsulated together ... operator overloading ... inheritance ... polymorphism ... virtual methods ... dispatch-tables ... GOT IT! And that was it. My procedural programming days were over and the way I even thought about how to design and build software completely changed at that very instant.
A similar experience happened to me when I started working over here in Redmond. Through discussions with Steve Swartz, Don Box, Doug Purdy and many others in Indigo land, I began to appreciate the notions of Service Orientation and how distributed systems should be constructed. In short, I began to think Service Oriented. And again, it suddenly clicked. I guess I got to the point where I had applied enough thought and debated the subject enough to reach the point where I was sufficiently comfortable and willing to let go of previously held beliefs and concepts that had carried me so well thus far. Once I got to that point, once I was willing to let go of OO as a notion for distributing services, I was finally able to appreciate what SO meant.
And again, my world view changed and suddenly clarity pervaded. Rather than being limited by the inadequacies of exisitng distributed systems technologies at the time, I began to reassess how distributed systems COULD be built if interop was possible, if security and reliability were pervasive, if rich metadata and the notion of passing data by value was core, if we assume that the network is unrealible, insecure and constrained and if we design assuming things are far away ... and oh the upside when they come close. Blam. A whole new world opened up.
This is what I believe SO is ... it truly is a belief system and a way of thinking. It is not a prescriptive architectural process or methodology. It's not a template that you can apply that results in a service oriented system. It's where art meets science. It's where aesthetics meets engineering. It's the thing adds a human touch to the things we create. It's inside of me and it's inside of you.