Redundant code and functions in services: Normalization

Redundant code and functions in services: Normalization

If your SOA landscape exists for a while, there could be a problem, which you could also know from system, that do not use service-oriented archtecture: Redundant code or functions!

Redundant code or functions means programming logic, which exists more than once in your system or programming logic, which creates exactly the same result. Redundant code is dispensable. That means, if you do it right, you can delete the redundant code or function and the results will be the same. Also the logic of your services can overlap, which means, that only parts of it are redundant.

When will it happen?

If the number of services in your system grows or already has increased over the years, redundant code and functions can happen very easily, if your analysis of logic and content is not what it should be.

Problem

If the logic of an existing function changes, you have to adjust every part of your system, where this redundant logic was implemented. Often it is very hard to identify all those places in your system. Also, this has negative impact on the re-usability of your services.

Solutions

A possible solution would be a normalization of (the logic of) your services, which prevents redundance and overlapping in the service-logic of your SOA.

Your efforts to avoid redundant code and functions in your services should start very early in your development process. Right from the start of the analysis phase should be assured, that conjoint logic is identified and marked as such. At design time each of those functions should be united and exposed in one service. It does not matter if you deal with business or technical logic. Business logic is packed into a business service, which can be consumed by other business services, whereas technical logic is implemented in a technical service, which can be consumed by business services or technical services.
The boundaries of the services(-logic) have to be defined and must strongly be observed, to avoid overlaps.

If you observed already redundant logic in your services, the only solution is a review and consequent refactoring. The redundant implementation of logic for related or identic problems by different developers at different places occurs oftenimes, especially on the technical level.

SOA

The SOA paradigm makes the refactoring easier in this case. If a identic function or logic was identified in different places of your code, those can be cut out and be implemented as an own service. At the cut-out areas the new service must be consumed. At this, you have to keep some important patterns in mind, to meet the SOA paradigm: Are the services still lousely coupled afterwards? Which message pattern must be used? Do you need a proxy- or a wrapper-service? And so on...

Normalized services and a normalized service repository will help you with re-usablitiy, simplifies your maintenance and makes thinks clearer, regarding your logic and services.

More information about service normalization:
http://en.wikipedia.org/wiki/Service_Normalization_Pattern
http://www.soapatterns.org/service_normalization.php