SOA Defined

Martin Fowler once referred to SOA as an acronym for Service Oriented Ambiguity - not surprising given the amount of ambiguity in the term's constituent words. I have previously commented on the ambiguity inherent in the term service. Architecture contains just as much ambiguity.

Architecture may refer to the process of designing something (in the sense that someone can be skilled in architecture), the style in which something is designed (for example Victorian architecture) and a specific design (such as the architecture of a building). In the context of SOA, all three definitions apply.

As an architectural style, SOA refers to the style of designing systems that are comprised of interacting coarse grained units of logic called services. Services interact by way of exchanging explicitly defined messages via their endpoints. The messages and endpoints are described by service contracts. Policies determine the requirements incumbent upon a service consumer in order to be capable of interacting with a service.

Any architecture meeting the above description is considered service oriented. This then leads us to our second definition. An SOA may refer to any architecture conforming to the SOA architectural style.

And finally, SOA may refer to the process of producing an architecture consistent with the service oriented style of architecture.

It is important to note that there are good architectures and bad architectures that constitute SOA from the standpoint of architectural style. Just because you have a bunch of services, does not mean you have a good architecture. The design patterns and best practices discussed in this blog thus far provide guidance for delivering a high quality SOA (that is, a high quality architecture in the SOA style). However, they are not prerequisites for an architecture to be service oriented.

Due to the ambiguity inherent in the term SOA, we must take care such that when using the term the context in which its usage is intended is clear.