Difference between revisions 730079519 and 750186987 on enwiki

{{notability|date=March 2010}}
'''Utility Abstraction''' is a [[Design pattern (computer science)|design pattern]], applied within the [[service-orientation]] [[design paradigm]], which advocates designing services<ref name='svc'>[http://www.whatissoa.com/p11.php Services] {{wayback|url=ebarchive |url=https://web.archive.org/web/20120501123049/http://www.whatissoa.com/p11.php |date=20120501123049May 1, 2012 }}</ref> that provide cross-cutting<ref name="cross-cutting">Functionality that is based on logic which is not related to any particular business process e.g. the requirement to log incoming messages may be required by multiple business processes.</ref> non-business <ref name="non-business">Functionality that is based on logic which is not directly related to the automation of a business process e.g. the invoice processing business process may indirectly require (contracted; show full)d works fine for fulfilling the short-term  project requirements, it gets difficult to keep different services, each containing some level of utility logic, in-sync in the long run when it comes to making a change to the contained utility functionality e.g. due to an upgrade of the underlying technology resources ([[database]]s, [[legacy system]]s). On the other hand, it not only denormalizes the service inventory,<ref name='SvcInv'>[http://www.whatissoa.com/p13.php Service Inventory] {{web
citearchive |url=http://www.webcitation.org/5wB481EYJ?url=http://www.whatissoa.com/p13.php |date=2011-02-01000000 |dateformat=iso }}</ref> due to the redundancy of the utility logic, but also loses the opportunity of making such general purpose logic available for reuse to automate multiple business processes.

In order to address the above issues,<ref name='Mauro'>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.] {{webcitearchive |url=http://www.webcitation.org/5wB4T8QrA |date=20110201175755 |dateformat=iso?url=http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=2011-02-01 }} [online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 6 April 2010.</ref> the Utility Abstraction design pattern dictates the separation of generic processing logic from the business process-specific logic into a separate group of services known as the utility services.<ref name="SvcLayerTypes">[http://www.soamethodology.com/p5.php Service Layer Types]</ref>

==Usage==
(contracted; show full)

==Considerations==
By moving the utility logic into separate services, inter-service communication is increased that can introduce latency as well as increased processing overhead. Similarly, due to the distribution of generic logic, the overall design of the service composition<ref name='ServiceComposition'>[http://www.whatissoa.com/p12.php Service Composition] {{web
citearchive |url=http://www.webcitation.org/5wB4SzA1B?url=http://www.whatissoa.com/p12.php |date=2011-02-01000000 |dateformat=iso }}</ref> will become complex and difficult to maintain.

== References ==
{{Reflist}}
* [[Thomas Erl|Erl]] ''et al.'', (2009).[http://www.amazon.com/dp/0136135161 SOA Design Patterns]. Prentice Hall. ISBN 0-13-613516-1.
* Jason Hogg.[http://webcache.googleusercontent.com/search?q=cache:EvGPjZorQQoJ:blogs.msdn.com/thehoggblog/attachment/9911966.ashx+utility+abstraction+pattern&cd=11&hl=en&ct=clnk&gl=uk SOA, Software + Services and Cloud Computing][Online].Date accessed: 17 April 2010.
* Susanne Patig.[http://drops.dagstuhl.de/opus/volltexte/2009/2047/pdf/09021.PatigSusanne.Paper.2047.pdf Cases of Software Services Design in Practice][Online].Date accessed: 18 April 2010.

== External links ==
* [http://www.whatissoa.com/ SOA Concepts]
* [http://www.soaglossary.com/ SOA Terms Glossary]
* [http://www.soapatterns.org SOA Design Patterns]

[[Category:Service-oriented (business computing)]]