Service Refactoring
Encyclopedia
Within the service-orientation
design paradigm
, Service Refactoring is a design pattern
, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.
It is quite natural for a service to undergo changes because of various reasons. The change could be required because the underlying implementation e.g. databases, legacy system
s, etc. need to be upgraded or simply because the original service logic was not making efficient use of memory. In other cases, the change could be initiated from the service consumers themselves e.g. with a limited concurrent usage, the service performs as stated in its SLA
, however, with increase in its concurrent usage, the service is unable to fulfill its SLA, consequently the service needs to respond to the increasing performance demands from its service consumers.
This situation needs to be dealt with in a manner so that the service is upgraded without affecting its consumers that have already formed dependencies on the service. Although one could argue that responding to any of the aforementioned requirements should not be problematic as long as the service honors its contract, however, over here we are not just concerned with the correctness of the outcome linked with the execution of service capabilities but also with the behavior and the reliability of the service. To address these issues, the Service Refactoring design pattern provides a strategy that strives to ensure a service can evolve without negatively affecting its consumers.
The application of this design pattern advocates the use of traditional software refactoring techniques. The focus is on refactoring the service in smaller steps so that the impact of each step is small enough to the reversed in case such a change negatively affects the service consumers. Secondly, to ensure the service contract remains unaffected by changes in logic or implementation, the service contract must be decoupled as much as possible. This can be done by introduction of a façade component in between the service contract and the service logic. However, this is only possible if the service contract is physically decoupled from its implementation in the first place, which could be accomplished by the application of the Decoupled Contract design pattern. This could further be strengthened by the application of the Contract Centralization design pattern that advocates establishing service’s contract as the only official entry point into the service.
On the other hand, to insulate service logic from negative effects from changes in the service implementation, the Service Façade design pattern could be reapplied to introduce another façade component between the service implementation and the service logic. The application of the Service Abstraction
principle can further help to reduce the possibilities of any detrimental effects caused by the application of this design pattern.
The application of the Service Refactoring design pattern requires extensive testing to ensure a reliable and proven service, although inefficient, carries on the same level of behavioral stability and reliability. This might spike up the project costs and would require additional quality assurance procedures and strict governance.
On the other hand, with its application, there might be a change to the current abstraction levels of the service, which would in turn require reapplication of the Service Abstraction design principle to ensure the service maintains the right level of abstraction. In some situations it might be impossible to constrain the effect of changes in the service logic or its implementation, and inadvertently the service contract must be updated. In this case, the Concurrent Contracts design pattern could be applied so that the service continues to entertain its consumers that have formed dependencies on its old contract while at the same time providing the updated contract that is in line with the updated service logic or service implementation.
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:...
, Service Refactoring is a design pattern
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...
, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.
Rationale
It is quite natural for a service to undergo changes because of various reasons. The change could be required because the underlying implementation e.g. databases, legacy system
Legacy system
A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available...
s, etc. need to be upgraded or simply because the original service logic was not making efficient use of memory. In other cases, the change could be initiated from the service consumers themselves e.g. with a limited concurrent usage, the service performs as stated in its SLA
Service Level Agreement
A service-level agreement is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time or performance...
, however, with increase in its concurrent usage, the service is unable to fulfill its SLA, consequently the service needs to respond to the increasing performance demands from its service consumers.
This situation needs to be dealt with in a manner so that the service is upgraded without affecting its consumers that have already formed dependencies on the service. Although one could argue that responding to any of the aforementioned requirements should not be problematic as long as the service honors its contract, however, over here we are not just concerned with the correctness of the outcome linked with the execution of service capabilities but also with the behavior and the reliability of the service. To address these issues, the Service Refactoring design pattern provides a strategy that strives to ensure a service can evolve without negatively affecting its consumers.
Usage
The application of this design pattern advocates the use of traditional software refactoring techniques. The focus is on refactoring the service in smaller steps so that the impact of each step is small enough to the reversed in case such a change negatively affects the service consumers. Secondly, to ensure the service contract remains unaffected by changes in logic or implementation, the service contract must be decoupled as much as possible. This can be done by introduction of a façade component in between the service contract and the service logic. However, this is only possible if the service contract is physically decoupled from its implementation in the first place, which could be accomplished by the application of the Decoupled Contract design pattern. This could further be strengthened by the application of the Contract Centralization design pattern that advocates establishing service’s contract as the only official entry point into the service.
On the other hand, to insulate service logic from negative effects from changes in the service implementation, the Service Façade design pattern could be reapplied to introduce another façade component between the service implementation and the service logic. The application of the Service Abstraction
Service Abstraction
Service Abstraction is a design principle that is applied within the service-orientation design paradigm so that the information published in a service contract is limited to what is required to effectively utilize the service i.e. the service contract should not contain any superfluous information...
principle can further help to reduce the possibilities of any detrimental effects caused by the application of this design pattern.
Considerations
The application of the Service Refactoring design pattern requires extensive testing to ensure a reliable and proven service, although inefficient, carries on the same level of behavioral stability and reliability. This might spike up the project costs and would require additional quality assurance procedures and strict governance.
On the other hand, with its application, there might be a change to the current abstraction levels of the service, which would in turn require reapplication of the Service Abstraction design principle to ensure the service maintains the right level of abstraction. In some situations it might be impossible to constrain the effect of changes in the service logic or its implementation, and inadvertently the service contract must be updated. In this case, the Concurrent Contracts design pattern could be applied so that the service continues to entertain its consumers that have formed dependencies on its old contract while at the same time providing the updated contract that is in line with the updated service logic or service implementation.