Service Oriented Architecture and Object Oriented Programming have a lot in common. Among other things, both terms contain too many words. Are there more similarities?
Service Oriented Architecture should just be called Architecture and SOA should be called A. The same goes for OOP. Just P or Programming is sufficient because you won’t find many developers anymore who don’t write object oriented code.
Just like with Architecture the “contract first” principle is very important for Programming; the contract is created first before the component or service is implemented. This will increase the interoperability because the intent of the component or service will always be clear. It also makes it easier to implement it to perfectly match the contract which will increase the quality.
Apart from “contract first” there are two more principles that I want to highlight here: Abstraction and Reusability (for the other 6 principles – read Principles of Service Design by Thomas Erl).
Abstraction is important because the implementation of the component or service can be masked for who or what invokes the service or component.
Reusability is of course important because it lowers implementation costs of new business processes. It can be implemented by making sure that the component or service does not know anything about its context.
You’ll also see that the other 6 principles also apply to both services and components.
The only difference is that components are “welded together” by the programmer who creates code using a text editor and services are invoked by business processes that can be visually designed using a Business Process Management environment (using Orchestration, Business Rules, etc.). With the former, the programmer creates procedural code, with the later the business analyst creates solutions by “clicking together” services.
But, if this is the only difference… isn’t it about time to combine these two paradigms into a new solution? The best of both worlds? P will deliver reusable, abstract components and A will deliver orchestration of the components. An we’ll call it: Software Architecture 2.0 or SA 2.0?
indaField 