Recently, I got an opportunity to meet and chat with some very able and talented developers and architects here at our .Net user group – KolkataNet. As usual, we got into discussing technology. This time around the buzzword was SOA (Service Oriented Architecture). To my utter surprise, none of them (including me) were not able to come up with a decently ‘complete’ definition for SOA. I must confess here that deep down inside I was not very unhappy about it. I was glad to find that when it comes to SOA, I am not the only confused bloke (lol).
This set me out to dig deeper into this highly hyped term. And really, the crux of finding was that the so highly hyped SOA is nothing but just a natural growth of the craft of developing software. The craft has come up a long way from procedural to object-orientation to component-based and now to service-orientation. Of course, every stage has had its own compelling drivers to take it to the next one. Hence, SOA is no revolution, it is just an evolution. There are business (rather marketing, lol) aspects to SOA too. But let us limit our focus to SOA as software development approach.
So what is SOA? In order to qualify itself as an SOA, an architecture must adhere to the infamous Four Tenants of SOA. Which are:
Boundaries are explicit. Developers should define explicitly what methods/properties are going to expose to the client.
Services are autonomous. Services and the consumer application are independent. So in future if we need to modify or enhance the services feature then we can take the services offline and work with that. So this won’t affect the consumer application.
Share Schema/Contract not class implementation. We need to share only the schema to our clients. If should not share any implementation information in to our clients. For example, we should not ask them to give any connection string info in the attribute level, which will expose what database we are using for our service.
Compatibility based on policy. The services should define all the requirements in order to use the services. We should not have person – to – person communication about the services.
So next time when you profess to have implemented SOA, check against these tenants to make sure that you are not exaggerating.