Logic centralization pattern
Logic Centralization is a design pattern, applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic [1] by ensuring that services[2] 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.[3][4]
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 design pattern does help to eliminate this redundancy, however, just having a set of normalized services on its own, does not guarantee that they would be reused as originally envisaged. In the case of agnostic services,[5] this issue can severely restrict the actual reuse of such services because a project team (Team A) may decide not to reuse an existing service, e.g. it requires data that corresponds to a complex scheme, and instead develop a lightweight service that 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 is exacerbated 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 starts 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.[6]
Usage
In the presence of an enterprise-wide design standard, service consumers' access to the redundant red service created by Project Team 2 is prohibited, and instead they are forced to use the existing red service created by Project Team 1. Similarly, Project Team 3 is prohibited to create any new service whose functionality falls within the existing red service, as a result, Project Team 3 uses/evolves the existing red service created by Project Team 1.
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.[7] By restricting access to other services, the governance burden is reduced as now the logic is confined within a single service. Whenever 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[8] 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[9] design pattern, constitute the Official Endpoint[10] 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.
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 effort. 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.
References
- ↑ Logic that does not belong to a specific business process and hence can be reused to automate multiple business processes
- ↑ "Services". http://www.whatissoa.com/p11.php.
- ↑ The type of the functionality provided by the service.
- ↑ Kanu Tripathi.Service Transaction Handling Without WS-AtomicTransaction[Online].Date accessed: 25 April 2010.
- ↑ Services that contain agnostic logic
- ↑ Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense [Online].Date accessed: 25 April 2010.
- ↑ Matthew Dailey.Software Architecture Design Service-Oriented Architectures (Part II) [Online]. Date accessed: 25 April 2010.
- ↑ Metadata Centralization pattern
- ↑ Contract Centralization pattern
- ↑ Official Endpoint pattern
- Erl et al., (2009).SOA Design Patterns. Prentice Hall. ISBN:0-13-613516-1.
External links
 |  |
