I’ve been involved in multiple projects sporting some form of Service Oriented Architecture using Microsoft .NET technologies. Some were SOA in name only (Remote Procedure Calls were involved) while others were closer in spirit to the tenets of SOA.
The term SOA tends to be abused in the community. When I do interviews with candidates, I often see SOA on resumes simply because the person has seen a web service through a car window. On the other hand, when I read SOA books & articles I sometimes find they are disconnected from the reality I’ve experienced and their field of application is too narrow.
I thought I would share my experience in applying SOA in the field. I will take the angle of bringing the concepts of SOA, discussing what they mean and then seeing how they can be applied. I’ll also discuss how principles can be bended or broken and how this can lead to situations we can see in the field.
SOA is an architecture style. It doesn’t fit in all situations but has been sufficiently studied to have a good body of knowledge (e.g. SOA patterns) attached to it, which makes it a good starting point to attack many software problems (but, by far, not all).
In this blog series, I will try to cover the following aspects:
- SOA Basics
- SOA Patterns
- Evolution (e.g. Versioning)
- Service Design (Discovery Process, Taxonomy)
- Reuse (e.g. Composition)
As always, your comments are most welcome as this is just my viewpoint, coloured by the experienced I had.