From many talks, blogs, case studies and reviews, I have collected a list of conceptions of what people think SOA is. Here is a discussion about it.
Yes, Service Oriented Architecture may mean different things for different people. I’m not talking about definitions, since those are more academic-theoretical things. Conceptions are more like the practical being of the concept.
Most conceptions differences are subtle, but enough to be important.
Let’s start by saying I conceptualize a SOA (yes, an instance of a SOA) as an architecture whose elements, in majority, represent (or are) services. SOA is an architectural style.
That said, here is the list:
SOA as an Acronym. Yes, SOA is just a name created by composing the first letter from Service Oriented Architecture. Thus, SOA is taken as yet another acronym that may be compared to other named technologies. Just another one of the bunch.
Academic SOA. In trying to explain the concept, many academics find several similarities with other concepts they had known from long time ago. Are they simple exposed objects? Are services similar to Complex Systems? What is the difference between a Service and an Intelligent Agent? Of course, there are differences. Services were never meant to be exposed objects or components (although implementation made that happen). Complex systems have evolution, self organization, chaos is involved and emergence (clearly, services are far much simpler). And of course, an agent is something that is not only autonomous, social (talk to other agents) and react and pro-act, but also have intelligence. Services do not.
SOA as an Indirection Layer. Now this one is more on the land of implementations. SOA is seen just as a layer that receives commands or requests, and passes them down to the real working objects (that ones with the business rules). So, SOA is just a way to add indirection to the requests, encapsulating and hiding the actual how-to. Of course, this conception is wrong by a great deal. SOA is not a layer to begin with. Being an architecture, it should be an organization of elements, the majority of them representing services. As implementation, we may think of services as the layer before the actual implementation, but the service is really the complete thing: the service contract, interface and inner implementation.
SOA as a Wrap. This is very similar to the above. SOA is seen just as a decoration for already made business logic. Usually presented as a salvation for legacy code, SOA is depicted in the diagrams as a layer that wraps the old in-use code, and made it usable for the new generations. (Careful with that picture, it is not as easy to expose old functionality with new interfaces, old code may not be designed to handle new load or business flow). Of course, SOA cannot be a wrap. You can create a wrap that uses services, but then your architecture will have new elements on top, services in the middle and old code down below. That is a sandwich, not really an architecture oriented to services.
SOA as a Component. Now, this one is interesting. SOA is mentioned and placed as a little square in some place of the diagram, and is given responsibilities and interfaces. Of course, this view of SOA as a component that can be use to construct an architecture, also breaks the idea of the SOA as a whole. It may fit, if that component is a subsystem that was created using the SOA style. But then, that component should be a subsystem, and the way it was implemented should not be its name!
SOA as a Service Group. Well, here there is not component, but just a container of all services I have. Yes, a group of services. SOA is then the place where you can find the services your architecture is using. I hope I don’t have to explain why this is a very wrong view.
SOA as a BP container. BP stands for Business Process. (Yes, it is not a “BPM container”, since the M stands for management: you create BPs and you work with them in a BPM system). So, SOA is just a container of BPs, and it is needed to have BPs implemented. Right. Of course that is not true. BPs can be implemented without SOA in the first place, since they are business abstractions that may not use the service metaphor or use it for just two or three calls, which will not make the architecture a Service oriented one. Services and BPs work in the business abstraction layer, meaning they refer to business functionality and not about object and methods. That is, they are the working units of business analysts and integrators. Still, SOA is an architecture, a container for BPs is just a container, and the services will be just a bunch of services. An architecture takes more than that to be SOA:
SOA as a Modernization Agent. As mentioned above, SOA is meant to be used to reuse old code, and to allow new interfaces for new layers to interoperate with ancient programs. Services could be use for that, but that will not make your architecture a SOA complaint. SOA will require the complete architecture to be made using the services metaphor, not just for accessing the old code, but to rethink the business solution.
Do you know any other conception of SOA I’m missing?