John Wood

I'm always struggling to find good definitions of SOA, and I think this is part of the problem. People say it's all marketing fluff, and yet actually the marketing for SOA has failed because it's not conveying the message of SOA effectively at all. If it was, then there wouldn't be so many confused individuals out there.

Some people have taken the initiative to find punchy acronyms to help define what SOA really is. PEACE is one of them. The problem is it's not really all that punchy when each word of the acronym averages like 10 syllables. We really do need something like ACID (the transaction acronym that is, not the hallucinogen). At least I can remember what ACID stands for.

As much as I love MSDN's (originally Don Box's) four tenets of service orientation, I think it requires too much study time to be effective as a marketing tool. I really think it's time to get back to basics.

So lets look at what the basic qualities of a service should be:

"Self Describing". Services must expose their interface, including all information relating to the structure of the messages it will accept and messages it will produce. (eg. WSDL)

"Open" . Services must be open and therefore accessible to a broad range of components, applications, and platforms. (eg. SOAP)

"Black-Boxed". This is really the "I don't need to see your underwear to talk to you" rule. You should be able to use a service without having to know about its inner-workings. Also referred to as "explicit boundaries", this has many implications. It often means that the service calls will be coarse-grained (ie. will require a lot of data in one call) because no assumptions can be made as to the state of the service or where the service ultimately lives. Black-boxing also covers statelessness, because you should be able to ask a service to do something without having to know its state.

"Autonomous". Although not always practical, services should strive to be autonomous. That is, they should not depend upon other facilities in the application in order to function, and if they are then these dependencies should be well documented and configurable. This is really to help meet the independence and loose-coupling goals of service orientation.

"Re-usable". Services should be developed with re-use in mind, they shouldn't be developed to serve just one application.

So that makes SOBAR. Not a particularly fun acronym but perhaps easier to remember at least.

Any other suggestions?