Leverage the Service Refactoring Pattern
The Service Refactoring pattern facilitates changes in service logic and/or underlying service implementation while preserving existing consumer contracts.
The Service Refactoring pattern allows the service provider to change the service implementation while preserving existing service contracts. This allows the provider the flexibility to honor existing consumers while taking advantage of streamlined service logic and/or better technologies. If this idea sounds familiar, it is based on the refactoring principles and techniques advocated by Martin Fowler in the object oriented design paradigm and aims to achieve the same result for services in a SOA context. This pattern requires the development of an adapter – that will translate messages conforming to the existing contract into the refactored contract and vice versa.
- Allows for phased migration of consumers who use existing contract to a new one
- Allows the provider to upgrade/enhance service behavior in phases. The refactoring can be accomplished via multiple steps and don’t all have to be bundled in a single release
- Eliminates the need for consumers to change code to take advantage of refactored service
- Allows new consumers to bind to the enhanced service contract and allows for new and existing consumers to co-exist
- Potentially enhance performance, availability, and scalability as new consumers come on board
There is a need for strong and coordinated service governance to make sure that consumers are aware of the refactoring effort, retest to validate the behavior, and ultimately provide sign-off for the service capability to be turned on in a production environment. At a minimum, this pattern needs to make sure that existing consumers conduct regression testing to guarantee that the refactored service doesn’t necessitate code changes.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)