The Definitive SOA

The definition of Service Oriented Architecture (SOA) seems to cause some anguish and confusion. This is because

• There is no good definition,
• Every one is thinking a bit differently about what SOA is,
• There is no acknowledged ultimate source on SOA, and
• It is hard to be brief enough to fit any SOA definition on a bumper sticker.

I thought I would set myself the challenge of coming up with a definition of SOA that I liked. My favorite for the last 12 months has been from Chris Brown of Wachovia Bank. I like it because it has two perspectives:

• From a business perspective, SOA is a construct and discipline whereby new business requirements are evaluated holistically against a backdrop of processes and functions that are currently in use by other business solutions. A common process or service that has been previously created, and paid for, is then augmented or reused, in whole or in part to create a new and/or improved process.
• From a technical perspective, SOA is a software architecture model where loosely coupled software components, representing granular but complete technical or business functionality, are accessible through known platform independent interfaces and transports over a network.

This is good for me because it speaks to the business in language they can understand. For the purposes of talking to the business I am happy to abandon technical precision. As for the second part of the definition I have recently had cause to question its precision. Terms like 'loosely coupled', 'granular functionality' and 'complete business functionality' are too ambiguous for a good technical definition.

It should be clear from a good definition that some applications do not apply to SOA. Some definitions I have seen would have to admit well structured COBOL applications as complying with SOA.

The reason it is important to have a definition is that now there seem to be a number of different interpretations to SOA. SOA to some people is Web Services, SOAP and WSDL. SOA to some is having a discipline around component reuse and not much more. SOA to some can also be as vague as basing software on business services. These interpretations of SOA can be useful in certain circumstances. This just means that when I talk about SOA it is necessary to declare what I mean.

I have looked through a number of definitions referenced below. Of special note is the research done by SearchWebServices.com that documented 12 different definitions supplied to it by technical celebrities who were asked to keep there definition to 50 words.

The things I want to include in my definition are:

• Distributed Computing
• Message Coupling
• Platform Independence
• Implementation Hiding or Abstraction

I should mention that I interpret "Loose Coupling" to be relative term. What is loose coupling in one context could the tight in another context. I have an earlier posting on the subject of coupling which emphasis the wide range of coupling types. I think we need to be precise about exactly what coupling we are talking about so I will use the term 'message coupling' in my definition.

The things that appear in some definitions that I want to leave out of my definition are:

• Web Services, SOAP, WSDL (too specific)
• Reference to Clients and Servers (It does not matter in SOA)
• Benefits of SOA (Reuse, agility etc.)
• Higher order concepts (Quality of Service, Security, Orchestration, Repositories)

So here it is. I resort to defining SOA and then a service.

SOA is a software architecture where the business logic is encapsulated in services and a single application may be distributed over many processors.

A service in this context is a software component which
· Hides its implementation,
· Is based on standards,
· Is location transparent,
· Is message coupled, and
· Is accessible through defined platform independent interfaces.

It would have been no good for SearchWebServices.Com because it is 59 words and it certainly will not make a good bumper sticker. However, it works for me now and like the rest of my thoughts on SOA, it is sure to evolve.

References:
My previous Postings on coupling: Bragging Rights on Coupling, Cohesion, Coupling and SOA

Brown, Chris, Transforming Business Process through Effective SOA Implementation, Conference Paper for Service Oriented Architecture 2007: Synchronising Business and IT to Drive Performance, February 26 - March 1, 2007, IQPC Conferences

Mimoso, Michael, A defining moment in SOA, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1017004,00.html, SearchWebServices.Com, 20 Oct 2004

Some More Definitions of SOA:
OASIS: http://en.wikipedia.org/wiki/Service-oriented_architecture
XML.COM: http://www.xml.com/pub/a/ws/2003/09/30/soa.html
Webopedia: http://isp.webopedia.com/TERM/S/Service_Oriented_Architecture.html
TechEncyclopedia: http://www.techweb.com/encyclopedia/defineterm.jhtml?term=soa
OMG: http://colab.cim3.net/cgi-bin/wiki.pl?OMGSoaGlossary%23nid34QI
OASIS: http://colab.cim3.net/cgi-bin/wiki.pl?OasisSoaGlossary%23nid34QP
OpenGroup: http://colab.cim3.net/cgi-bin/wiki.pl?OpenGroupGlossary%23nid34QT
W3C: http://colab.cim3.net/cgi-bin/wiki.pl?WwwCSoaGlossary#nid34R0
WhatIS: http://searchwebservices.techtarget.com/gDefinition/0,294236,sid26_gci929153,00.html
Gartner: http://www.ipt-group.com/download/SOA_IG/SOA_IG_CS_2007_08_28.pdf