SOA Pattern (#14): Logic Centralization
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Logic Centralization design pattern is closely related to the Service Normalization design pattern and may even seem similar to what the Service Normalization design pattern advocates: keeping the service inventory free of any redundant solution logic. However, there is a major difference between these two design patterns. The application of the Service Normalization design pattern results in services with non-overlapping service boundaries, but this does not guarantee that these normalized services would actually be used and evolved as indicated by their functional contexts. For example, a project team may decide to develop a new Invoice service, which is more streamlined with their tactical requirements, instead of making use of an existing normalized Invoice service. Therefore, despite the fact that the service inventory was fully normalized to start with, as time passes and more services are delivered by different project teams, a strong chance of the service inventory becoming denormalized exists. This denormalization further reduces the reuse potential of agnostic services, because when agnostic logic that belongs to the same functional context exists under multiple functional contexts, the service consumers are unable to find the required functionality within the originally advertised agnostic service. Consequently, this lack of reuse negatively impacts the intended increased ROI goal of SOA and increases the governance burden related to the evolution of the affected services.
This is where the Logic Centralization design pattern comes into play by advocating that each service be used as it was originally envisaged at the time of its inception. This design pattern is enforced via design standards that demand the correct use of services as indicated by their functional contexts. The application of this design pattern can be viewed from two different aspects: one from the consumption of services and the other from the service’s evolution. Both of these are interrelated as the application of one makes the realization of other possible. On the service consumption side, this design pattern dictates that only one service can act as the official endpoint for a particular functional context, as a result of which the service consumers are forced to only use a particular service that officially represents its corresponding functional context, and access to any other service or component that provides the same functionality is not permitted. As a result, service consumers become dependent upon a particular service and expect that the service provides the complete set of functionality as indicated by its functional context. This dependency can rise considerably if the service under question happens to be an agnostic service. So now although the use of the service has been standardized, the benefits linked with this standardization will only be realized if the official endpoint provides all the expected functionality. This is where the evolution of service comes in. The application of the Logic Centralization design pattern, while designing new services, requires that any solution logic that falls under the functional context of an existing service should be added to that particular service instead of creating a new service. This centralizes the same type of logic within a single service and now the service consumers can expect to find the relevant functionality within the expected service.
The application of the Logic Centralization design pattern is of special interest to the agnostic services as by restricting the same type of agnostic logic in one service, the chances of agnostic services being reused more are increased automatically. This centralization of logic further helps to reduce the level of redundant logic within the service inventory.
The Logic Centralization pattern directly supports the increased ROI goal of SOA. However, the degree of its success is dependent upon the true adoption of the design standards as set by this design pattern. Apart from the cultural issues, which may stand in the way of embracing the design standards, the application of this design pattern usually results in an increase in the project development time, as the solution design may need to be adjusted in order to make use of the official endpoints, and would also increase the governance burden of such official endpoints, as the service architecture may need to be evolved due to the new service capabilities being added to the service.
The SOA Pattern series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).