Brian Noyes' Blog

SOA != Death of components and OOP

Sam is trying to get his head around SOA, along with many of us. He states:

“I must confess SOA to be one of those* paradigm shifts* – it really does mean the death of objects at least as we know them.”

I don’t see it that way at all, any more than the development of component-oriented development meant the death of OOP. I see SOA as a semi-formalization of a higher level of abstraction that is needed in large scale applications. OOP developed as a good abstraction and way ofencapsulting state and behavior in small-grained pieces of code for maintainability and (potential) reuse. Components evolved to encapsulate meduim grained chunks of functionality at a level where you could start to compose systems from pieces that could be more easily understood, managed, maintained, and yes, sometimes reused. I see SOA as a further evolution down that path – encapsulating functionality and processes at a course grained level – making it easier to describe and compose larger systems out of collaborating, interrelated parts.

I don’t think SOA means the death of OOP or Components at all. Just like most people build components using OOP, I think most people will built SOAs using OOP and Components. They are not competing concepts but complementary.

Indigo gets into the game by not forcing you to choose up front in and all or nothing fashion about which particular communication technology is going to be used to let services collaborate by using the abstraction of SOA. If you have two pieces of a system, or two systems that need to communicate and share information, focus on the communication contract, not the implementation mechanism. Maybe for now they are both going to be sitting on the same machine, but you want strong security and have more than one resource manager – a good fit for Enterprise Services. Next year you find you need to scale out or relocate those services and now there is a firewall in between. Now Web Services start to make more sense. Today you would need a significant rewrite of the application. With Indigo it would mostly be tweaking configuration.

I spent a lot of time looking at, writing on, and speaking about the Microsoft Application Blocksbefore attending a workshop on Indigo in Redmond back in September, and it helped me understand Indigo in a big way. Many of the application blocks use abstractions of Providers and Publishers that can be configured and plugged in to change the behavior of the block without needing to change any of the application code. This is done by adding classes (components really) that implement the interfaces that constitute the contract of the block, and using config files to get them loaded dynamically at runtime. The application just programs against the interface, so it doesn’t care which provider or publisher is servicing the functionality. They are very slick.

With SOA, the contract just migrates from being a binary interface specification to being a more abstract and platform neutral WSDL specification. How you satisfy that contract depends on the requirements of your application.

Bottom line, I see SOA building on OOP and Components conceptually, and see SOA applications beingbuiltwith OOP and components. I hope people don’t decide that this means they shouldgo back to procedural programming.