Time for one of SOA’s best-known principles: reusability. It is certainly one of the most obvious benefits of service orientation. It is surely the easiest to explain and understand. It is often the easiest to take on by those approaching SOA. In fact, reusability is part of the history of software development since its inception, although at different scales, so more or less, sounds to us all enough.
A few months ago we dedicated an entry to talk about reusability in SOA. You can review now that post related to this fourth SOA principle, but here we will try not to repeat ourselves.
Let us focus on the statement of this principle.
This SOA principle indicates three important nuances that I would like to comment:
What does this mean?. For me the concept of abstraction is more familiar than agnosticism in ICT. Here, when speaking of agnostic logic, it means that the service logic focuses on the entity in the service scope, completely forgetting the uses that will arise in any information system.
The logic to include must be the inherent to that entity, stripped of any logic inherited from any information system; if not, we would be polluting the service, and introducing some degree of coupling.
As you can see, it is a very close idea, if not identical, to abstraction and encapsulation.
Related to the previous point, it is important that the logic is explicitly inherent to the entity’s protagonist of the service, without ambiguities.
If the service is about “patient exitus notification”, all the logic and information contained in the service contract must refer only, expressly and autonomously, to the patient’s data, and to his death.
Information about the destinations of such notification should not be included, neither information regarding the systems that may send it. Nor any other circumstances that may accompany the patient in certain use cases.
Reusable business resources.
Let us focus here on “business resources”.
This approach from the point of view of ICT is very interesting. It points directly to the industrialization of software development. It is a matter of incorporating the same principles that govern the designing, manufacturing and testing process of parts of any industrial sector into the designing, developing and testing process of software parts.
Looking at the three aspects as a whole, we see how the reuse of SOA services is maximized.
Just as a nut is conceived, designed, manufactured and tested in a way totally independent of the thousands of uses it may have, an SOA service must be conceived, designed, constructed and tested with the clear idea that it solves a general need for an entity, with a solution specifically designed for that entity, and with the idea of being reused in any situation where that entity may appear.
We do not care what, when, where or how. We only care to ensure that, just like that nut will always give the expected result in any of its many possible uses, our service will always have the expected behavior in any context where it is used.
This industrial and commercial vision of service manufacturing is a very important step for the evolution of our traditional paradigms of software development, and is the one that will maximize the service reusability in a SOA strategy at the enterprise level.