Somewhere back in the mists of time the term SOA (standing for Service Oriented Architecture) was hijacked by the likes of IBM, Sun Microsystems, Oracle, BEA and others to mean a Java Web services implementation of a SOA solution and now you can't mention the term SOA without everyone assuming that is what you mean. While these implementations of SOA are a perfectly valid implementation are they the only possible implementation? Well NO! Can the approach be applied elsewhere to other implementations? Well YES but only if you get yourself out of the rut of thinking that SOA mandates a Java Web Services implementation. So just for a few moments suspend your preconceptions of what you think SOA is and approach what follows with an open mind.
In the rapidly emerging world of cloud computing everything is viewed as a service. The clue is in the naming - Software as a Service, Platform as a Service, IT as a Service, Infrastructure as a Service, Database as a Service, Storage as a Service, etc, etc, etc, in fact everyone seems to be rushing around trying to define their own as a service acronym. So what do these services look like. Well if done properly as well as the service itself there should be a clearly defined interface specification on how to access and consume the service. There will be one or more service level agreements defining the level of service that you can expect including such things as response times, permitted consumption levels, costs, up-times, recovery times, etc. Finally you will need a mechanism whereby each service can publish it's self and it capabilities for consumers to discover the service and attach to it. Typically this is via a service repository. New services can then be defined as unique entities or by building on or adding to an existing service or services - a composite service. These composite services will have their own unique service definition and SLA(s).
Now these services can be grouped into layers of abstraction as we build from base IT or infrastructure services through data and knowledge services to business services with each layer building on the layers below and adding functionality.
Hang on a minute this sounds exactly like a Services Oriented Architecture but as yet no use of the works Java or Web Services. So can Java Web Services exist in the new Cloud SOA world? Of Course they can but this Cloud SOA world is not dependant on Java Web Services for it's existence.
Time I think for the enterprise or cloud architects to go and dust off this SOA reference architectures and governance from the past from the likes of BEA and IBM and give them a refresh for the new world of clouds. The only question that remains is do we need to come up with a new acronym for it or do we reclaim the SOA acronym for what it originally meant before it was hijacked.