Logic Centralization Pattern
Encyclopedia
Logic Centralization is a design pattern
, applied within the service-orientation
design paradigm
, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented by a service that has the most suitable functional context.
As more and more services are developed, there is a constant risk that services with redundant functionality may be created. Although the application of the Service Normalization
design pattern does help to eliminate this redundancy, however, just by having a set of normalized services on its own, does not guarantee that they would be reused as originally envisaged. In case of agnostic services, this issue can severely restrict the actual reuse of such services because a project team (Team A) may decide no to reuse an existing service, e.g. it requires data that corresponds to a complex schema, and instead develop a lightweight service that just does the job. As a result, the same reusable logic now exists with two different services, whereas the existing service should have been evolved even if it did not contain the most suitable flavor of the functionality. This effect gets multiplied when another team (Team B) hoping to find the functionality within the existing service, as the boundary of the service does cover the required functionality, fails to find it and instead start using the newly created service by Team A. Consequently, the actual reusability of the original agnostic service drops and at the same time creates governance
problem as far as the maintenance of the original and new services is concerned because now reusable logic exists in a decentralized manner.
In order to ensure that a particular type of reusable solution logic is only enclosed by one specific agnostic service, the Logic Centralization design pattern dictates that design standards need to be established that force the proper use of agnostic services. This gives the service consumers the confidence that they are accessing the functionality through the correct service.
The application of this design pattern requires setting up 'official endpoints' (services) that represent a particular type of functionality i.e. the functionality that falls under a particular type of functional domain. Access to any other services, which may offer the same functionality, is prohibited and only one service is made accessible for a particular type of functionality. By restricting access to other services, the governance burden is reduced as now the logic is confined within a single service. Whenever a new functionality is required, which is not currently offered by any of the existing services, then first the functional contexts of the existing services need to be checked and if the new functionality falls under the boundary of an already existing service, then it should be added to that service. This requires an enterprise wide standard that enforces the centralization of logic. In order to make sure that service developers are aware of the service boundaries, Metadata Centralization design pattern could be applied. This helps in creating a centralized repository of information about the functional contexts and the functionality provided by the services. The Logic Centralization design pattern when applied together with the Contract Centralization design pattern, constitute the Official Endpoint design pattern. The application of the Logic Centralization design pattern further helps in the application of the Service Reusability
and the Service Composability
design principles by ensuring that each service contains the right type of reusable functionality so that it can be composed repeatedly.
In order to apply this design pattern, it needs to be ensured that all the project teams across the enterprise understand and agree to the proper use of agnostic services and do not create any new services that only serve the short-term requirements of a project. This can also impact the project delivery times as the use of existing agnostic services (and to evolve them as per the guidelines of this pattern) would require increased time and efforts. This is because the services in the current project may not be able to make use of the agnostic services until their own design is changed.
Design pattern (computer science)
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that...
, applied within the service-orientation
Service-orientation
Service-orientation is a design paradigm to build computer software in the form of services. Like other design paradigms , service-orientation provides a governing approach to automate business logic as distributed systems...
design paradigm
Design paradigm
The term Design paradigm derives from the rather ambiguous idea of paradigm originating in Sociology of Science, which carries at least two main meanings:...
, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented by a service that has the most suitable functional context.
Rationale
As more and more services are developed, there is a constant risk that services with redundant functionality may be created. Although the application of the Service Normalization
Service Normalization Pattern
Service Normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality...
design pattern does help to eliminate this redundancy, however, just by having a set of normalized services on its own, does not guarantee that they would be reused as originally envisaged. In case of agnostic services, this issue can severely restrict the actual reuse of such services because a project team (Team A) may decide no to reuse an existing service, e.g. it requires data that corresponds to a complex schema, and instead develop a lightweight service that just does the job. As a result, the same reusable logic now exists with two different services, whereas the existing service should have been evolved even if it did not contain the most suitable flavor of the functionality. This effect gets multiplied when another team (Team B) hoping to find the functionality within the existing service, as the boundary of the service does cover the required functionality, fails to find it and instead start using the newly created service by Team A. Consequently, the actual reusability of the original agnostic service drops and at the same time creates governance
SOA Governance
SOA governance is a concept used for activities related to exercising control over services in a service-oriented architecture . SOA governance can be seen as a subset of IT governance which itself is a subset of corporate governance. The focus is on those resources to be leveraged for SOA to...
problem as far as the maintenance of the original and new services is concerned because now reusable logic exists in a decentralized manner.
In order to ensure that a particular type of reusable solution logic is only enclosed by one specific agnostic service, the Logic Centralization design pattern dictates that design standards need to be established that force the proper use of agnostic services. This gives the service consumers the confidence that they are accessing the functionality through the correct service.
Usage
The application of this design pattern requires setting up 'official endpoints' (services) that represent a particular type of functionality i.e. the functionality that falls under a particular type of functional domain. Access to any other services, which may offer the same functionality, is prohibited and only one service is made accessible for a particular type of functionality. By restricting access to other services, the governance burden is reduced as now the logic is confined within a single service. Whenever a new functionality is required, which is not currently offered by any of the existing services, then first the functional contexts of the existing services need to be checked and if the new functionality falls under the boundary of an already existing service, then it should be added to that service. This requires an enterprise wide standard that enforces the centralization of logic. In order to make sure that service developers are aware of the service boundaries, Metadata Centralization design pattern could be applied. This helps in creating a centralized repository of information about the functional contexts and the functionality provided by the services. The Logic Centralization design pattern when applied together with the Contract Centralization design pattern, constitute the Official Endpoint design pattern. The application of the Logic Centralization design pattern further helps in the application of the Service Reusability
Service Reusability Principle
Service Reusability Principle is a design principle that is applied within the service-orientation design paradigm, in order to create services that have the potential to be reused across the enterprise...
and the Service Composability
Service Composability Principle
Service Composability is a design principle, applied within the service-orientation design paradigm, which encourages the design of services in a manner so that they can be reused in multiple solutions that are themselves made up of composed services...
design principles by ensuring that each service contains the right type of reusable functionality so that it can be composed repeatedly.
Considerations
In order to apply this design pattern, it needs to be ensured that all the project teams across the enterprise understand and agree to the proper use of agnostic services and do not create any new services that only serve the short-term requirements of a project. This can also impact the project delivery times as the use of existing agnostic services (and to evolve them as per the guidelines of this pattern) would require increased time and efforts. This is because the services in the current project may not be able to make use of the agnostic services until their own design is changed.