Service refactoring: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 17:45, 28 August 2024

Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service^[1] so that either the service logic or its implementation can be changed without affecting the service consumers.

Rationale

It is natural for a service to undergo changes for various reasons. The change could be required because the underlying implementation e.g. databases, legacy systems, etc. needs 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 by the service consumers themselves. For example, with limited concurrent usage, the service performs as stated in its SLA, however, with an 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.^[2]

This situation needs to be addressed in a way that upgrades the service without disrupting consumers who have already become dependent on it. 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, we are concerned with both the outcome from the execution of service capabilities^[3] and also with the behavior and reliability of the service. The Service Refactoring design pattern provides a strategy aimed at ensuring that a service can evolve without negatively affecting its consumers.^[4]

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 minimal and can be easily reversed if it 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.^[5] This can be done by introducing a façade component^[6] 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^[7] design pattern. This could further be strengthened by the application of the Contract Centralization^[8] design pattern that advocates establishing the 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.^[9]

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 increase 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^[10] design pattern could be applied, allowing the service to continue supporting consumers dependent on the old contract while simultaneously offering an updated contract that aligns with the new service logic or implementation.

References

^ "service". Archived from the original on 2012-05-01. Retrieved 2010-03-14.
^ Jason Bloomberg.The Four Pillars of Service-Oriented Development Archived 2011-07-16 at the Wayback Machine[Online]. Date accessed: 27 April 2010.
^ "Service Capabilities". Archived from the original on 2010-01-17. Retrieved 2010-03-14.
^ Thomas Erl.Introducing SOA Design Patterns Archived 2010-09-13 at the Wayback Machine[Online]. Date accessed: 5 April 2010.
^ Wajid Khattak.Service Refactoring Archived 2012-01-13 at the Wayback Machine[Online]. Date accessed: 27 April 2010.
^ "Service Façade design pattern". Archived from the original on 2010-01-29. Retrieved 2010-02-15.
^ Decoupled Contract design pattern
^ "Contract Centralization design pattern". Archived from the original on 2010-01-28. Retrieved 2010-02-15.
^ Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense Archived 2010-09-20 at the Wayback Machine[Online]. Date accessed: 28 April 2010.
^ "Concurrent Contracts design pattern". Archived from the original on 2010-01-17. Retrieved 2010-02-15.

External links

[service-1] "service". Archived from the original on 2012-05-01. Retrieved 2010-03-14.

[JB-2] Jason Bloomberg.The Four Pillars of Service-Oriented Development Archived 2011-07-16 at the Wayback Machine[Online]. Date accessed: 27 April 2010.

[SvcCap-3] "Service Capabilities". Archived from the original on 2010-01-17. Retrieved 2010-03-14.

[SOAWorldMag-4] Thomas Erl.Introducing SOA Design Patterns Archived 2010-09-13 at the Wayback Machine[Online]. Date accessed: 5 April 2010.

[IIT-5] Wajid Khattak.Service Refactoring Archived 2012-01-13 at the Wayback Machine[Online]. Date accessed: 27 April 2010.

[SvcFacade-6] "Service Façade design pattern". Archived from the original on 2010-01-29. Retrieved 2010-02-15.

[DecCont-7] Decoupled Contract design pattern

[ConCen-8] "Contract Centralization design pattern". Archived from the original on 2010-01-28. Retrieved 2010-02-15.

[DW-9] Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense Archived 2010-09-20 at the Wayback Machine[Online]. Date accessed: 28 April 2010.

[ConCon-10] "Concurrent Contracts design pattern". Archived from the original on 2010-01-17. Retrieved 2010-02-15.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

@@ Line 1: / Line 1: @@
-{{orphan|date=March 2010}}
-{{Wikify|date=March 2010}}
 {{tone|date=March 2011}}
-Within the [[service-orientation]] [[design paradigm]], '''Service Refactoring''' is a [[Design pattern (computer science)|design pattern]], which is applied to an existing service<ref name="service">[http://www.whatissoa.com/p11.php service]</ref> so that either the service logic or its implementation can be changed without affecting the service consumers.
+Within the [[service-orientation]] [[design paradigm]], '''Service Refactoring''' is a [[design pattern]], which is applied to an existing service<ref name="service">{{Cite web |url=http://www.whatissoa.com/p11.php |title=service |access-date=2010-03-14 |archive-date=2012-05-01 |archive-url=https://web.archive.org/web/20120501123049/http://www.whatissoa.com/p11.php |url-status=live }}</ref> 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]]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 [[Service level agreement|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.<ref name="JB">Jason Bloomberg.[http://www.zapthink.com/2005/04/18/the-four-pillars-of-service-oriented-development The Four Pillars of Service-Oriented Development][Online]. Date accessed: 27 April 2010.</ref>
+It is natural for a service to undergo changes for various reasons. The change could be required because the underlying implementation e.g. databases, [[legacy system]]s, etc. needs 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 by the service consumers themselves. For example, with limited concurrent usage, the service performs as stated in its [[Service level agreement|SLA]], however, with an 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.<ref name="JB">Jason Bloomberg.[http://www.zapthink.com/2005/04/18/the-four-pillars-of-service-oriented-development The Four Pillars of Service-Oriented Development] {{Webarchive|url=https://web.archive.org/web/20110716060328/http://www.zapthink.com/2005/04/18/the-four-pillars-of-service-oriented-development/ |date=2011-07-16 }}[Online]. Date accessed: 27 April 2010.</ref>
-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<ref name="SvcCap">[http://www.soaprinciples.com/p2.php Service Capabilities]</ref> 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.<ref name="SOAWorldMag">[[Thomas Erl]].[http://soa.sys-con.com/node/645271?page=0,2 Introducing SOA Design Patterns][Online]. Date accessed: 5 April 2010.</ref>
+This situation needs to be addressed in a way that upgrades the service without disrupting consumers who have already become dependent on it. 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, we are concerned with both the outcome from the execution of service capabilities<ref name="SvcCap">{{Cite web |title=Service Capabilities |url=http://www.soaprinciples.com/p2.php |url-status=live |archive-url=https://web.archive.org/web/20100117144209/http://www.soaprinciples.com/p2.php |archive-date=2010-01-17 |access-date=2010-03-14}}</ref> and also with the behavior and reliability of the service. The Service Refactoring design pattern provides a strategy aimed at ensuring that a service can evolve without negatively affecting its consumers.<ref name="SOAWorldMag">[[Thomas Erl]].[http://soa.sys-con.com/node/645271?page=0,2 Introducing SOA Design Patterns] {{Webarchive|url=https://web.archive.org/web/20100913104647/http://soa.sys-con.com/node/645271?page=0,2 |date=2010-09-13 }}[Online]. Date accessed: 5 April 2010.</ref>
 ==Usage==
-The application of this design pattern advocates the use of traditional [[Code refactoring|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.<ref name="IIT">Wajid Khattak.[http://www.informit.com/articles/article.aspx?p=1571354 Service Refactoring][Online]. Date accessed: 27 April 2010.</ref> This can be done by introduction of a façade component<ref name="SvcFacade">[http://soapatterns.org/service_facade.php Service Façade design pattern]</ref> 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<ref name="DecCont">[http://soapatterns.org/decoupled_contract.php Decoupled Contract design pattern]</ref> design pattern. This could further be strengthened by the application of the Contract Centralization<ref name="ConCen">[http://soapatterns.org/contract_centralization.php Contract Centralization design pattern]</ref> design pattern that advocates establishing service’s contract as the only official entry point into the service.
+The application of this design pattern advocates the use of traditional [[Code refactoring|software refactoring techniques]]. The focus is on refactoring the service in smaller steps so that the impact of each step is minimal and can be easily reversed if it 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.<ref name="IIT">Wajid Khattak.[http://www.informit.com/articles/article.aspx?p=1571354 Service Refactoring] {{Webarchive|url=https://web.archive.org/web/20120113080552/http://www.informit.com/articles/article.aspx?p=1571354 |date=2012-01-13 }}[Online]. Date accessed: 27 April 2010.</ref> This can be done by introducing a façade component<ref name="SvcFacade">{{Cite web |url=http://soapatterns.org/service_facade.php |title=Service Façade design pattern |access-date=2010-02-15 |archive-date=2010-01-29 |archive-url=https://web.archive.org/web/20100129054815/http://www.soapatterns.org/service_facade.php |url-status=live }}</ref> 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<ref name="DecCont">[http://soapatterns.org/decoupled_contract.php Decoupled Contract design pattern]</ref> design pattern. This could further be strengthened by the application of the Contract Centralization<ref name="ConCen">{{Cite web |url=http://soapatterns.org/contract_centralization.php |title=Contract Centralization design pattern |access-date=2010-02-15 |archive-date=2010-01-28 |archive-url=https://web.archive.org/web/20100128223050/http://www.soapatterns.org/contract_centralization.php |url-status=live }}</ref> design pattern that advocates establishing the 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.<ref name="DW">Dennis Wisnosky.[http://www.soamag.com/I25/0109-2.pdf Principles and Patterns at the U.S. Department of Defense][Online]. Date accessed: 28 April 2010.</ref>
+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.<ref name="DW">Dennis Wisnosky.[http://www.soamag.com/I25/0109-2.pdf Principles and Patterns at the U.S. Department of Defense] {{Webarchive|url=https://web.archive.org/web/20100920163201/http://www.soamag.com/I25/0109-2.pdf |date=2010-09-20 }}[Online]. Date accessed: 28 April 2010.</ref>
 ==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.
+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 increase 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<ref name="ConCon">[http://www.soapatterns.org/concurrent_contracts.php Concurrent Contracts design pattern]</ref> 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.
+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<ref name="ConCon">{{Cite web |url=http://www.soapatterns.org/concurrent_contracts.php |title=Concurrent Contracts design pattern |access-date=2010-02-15 |archive-date=2010-01-17 |archive-url=https://web.archive.org/web/20100117183602/http://www.soapatterns.org/concurrent_contracts.php |url-status=live }}</ref> design pattern could be applied, allowing the service to continue supporting consumers dependent on the old contract while simultaneously offering an updated contract that aligns with the new service logic or implementation.
 == References ==
 {{Reflist}}
-* [[Thomas Erl|Erl]] et al.,(2009).[http://www.amazon.com/dp/0136135161 SOA Design Patterns]. Prentice Hall. ISBN 0-13-613516-1.
+==Further reading==
+* [[Thomas Erl|Erl]] et al.,(2009).[https://www.amazon.com/dp/0136135161 SOA Design Patterns]. Prentice Hall. {{ISBN|0-13-613516-1}}.
 * Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp.&nbsp;1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 5 April 2010.
-== External links ==
+==External links==
 * [http://www.whatissoa.com/ SOA Concepts]
 * [http://www.soaglossary.com/ SOA Terms Glossary]