Abstraction had to be in SOA principles. If you have read my previous entries in this blog, you will have seen how this concept often appears when we are dealing with service orientation. In fact we expressly dedicated this entry to this concept.
Indeed, this third SOA principle focuses on abstraction. As indicated in the text accompanying this principle, abstraction is closely related to the level of coupling and to the granularity of services. And therefore also affects the rate of reuse (of which we will speak in another SOA principle very soon).
You can see that these first SOA principles are closely related. The use of standards (first SOA principle) allows to define uniform interfaces that hide the logic of the service, with respect to the surrounding environment (supplier and consumer systems). This allows to encapsulate the service and reduce the coupling (second principle SOA). And with an encapsulated, standard and decoupled service, the abstraction level defines the scope of the service in its business scope, and its rate of reuse.
Abstraction is a feature deeply present in the history of software. Information technologies, programming languages, APIs, design techniques, different UML diagrams, etc, etc, etc., continually apply successive layers of abstraction, on the one hand, away from technology, and on the other hand, to get closer to the real world that we intend to capture and model. The OSI model itself, which was so important at the time, was an exercise in abstraction.
The different paradigms of software development have meant significant steps in the levels of abstraction that we apply when designing information systems.
The structured programming promoted not only the order in the source code, but also the internal re-use of specialized pieces of code (procedures, functions), for which it was necessary to abstract its logic to make it useful in different moments of the execution of the program.
Object Orientation was an enormous qualitative leap in consecrating abstraction as an essential feature for the design of class diagrams, and for the design of the classes themselves. It left behind the local scope of a program and placed us on a higher plane, common to different applications, that could use the same classes to solve similar requirements.
Now the Service Orientation goes a step further and leaves behind the scope of information systems, to place us at the level of the implementation of the standards at the business level. At this level of abstraction is where we move to identifying, defining and designing business services. The technology and the information systems that will use these services are further down, and are no longer important in designing business services.
This level of abstraction allows us to focus exclusively on the specification of the service, not including technological information or any other nature, beyond the standard specification of the service from the point of view of the business it serves, which is reflected in its contract.
And this is precisely what the statement of this principle indicates.