Monday, April 14, 2008

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.


flgb said...

Do you want to define "interacting coarse grained units of logic". Ta.

Bill said...

Yes I agree that the definition is somewhat intangible, but then services really are relatively intangible in that they include systems, people and process.

"Unit of logic" was about the best description I could arrive at; although I am open to suggestions. I didn't want to use "component" because that implies a service comprises only software.

In essence, a service is defined by its boundary. You can find a discussion on service boundaries here.

In terms of "coarse grained", I have a post coming up soon on service granularity that should hopefully make things clear.