Keith Pijanowski has an excellent on-going series of posts on the topic of Enterprise Service Oriented Architecture. He’s got 2 articles on the topic posted so far:
The term Service Oriented Architecture (SOA) is used to describe a variety of very different architectural patterns for using services. This is unfortunate because a term with more than one meaning is a term which causes confusion. Let’s look at a couple of definitions of SOA and make some observations about each.
In my previous post I asserted that today the best way to think about SOA is to think of it as an Enterprise Architecture. Specifically, if an organization wishes to maximize reuse and make sure that all their services are well behaved and operational, then information will need to be stored and maintained such that all services are well known and capable of being managed. Since we want to manage the entire lifecycle of services in a SOA this information must be captured and maintained for services under development as well as services that are deployed. For a collection of services to be well known and manageable, information must be maintained which describes in a consistent way the functionality of each service, the service owner, interested parties, dependencies, configuration, the services categorization according to a business taxonomy and finally a description of proper behavior.