Difference between revisions 427089083 and 465784505 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]</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 requiremen(contracted; show full) 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]</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.

<br/>
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.] [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==
[[Image:SOA DP Utility Abstraction.JPG|thumb|alt=Utility Abstraction|Abstracting Utility Functions<br/>Processes A, B and C all contain utility functions which can be of interest to other services. As a result, five different utility functional contexts are created and the related functionality from each process is added to the most relevant functional context. Doing so also eliminates any redundant functionality.]]
<br/>⏎
This design pattern provides practical guidelines for designing the utility service layer as advocated by the [[Service Layers Pattern|Service Layers]] design pattern. These utility services are designed by analyzing the common processing requirements of business services (services that contain business process-specific logic) and then developing the required functionality represented by a meaningful functional context<ref name="FunctionalContext">The kind of the functionality provided. The service boundary of a service is represented by a particular functional context.</ref>. The functional contexts of utility services would tend to be more technology oriented as compared to entity services<ref name="SvcLayerTypes" /> as utility services mostly provide technology interfacing functionality<ref name='SearchSOA'>Bernhard Borges, Kerrie Holley and Ali Arsanjani.[http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1006206,00.html Service-oriented architecture][Online].Date accessed: 17 April 2010.</ref> e.g. a wrapper service that talks to a legacy database or a service that provides data conversion functionality between different formats<ref name='DOD'>Dennis Wisnosky.[http://www.soamag.com/I25/0109-2.php Principles and Patterns at the U.S. Department of Defense][Online].Date accessed: 18 April 2010.</ref>.
<br/>
It is important to understand that the functional contexts identified for the utility services need to correctly represent the functionality contained within utility services. This places an increased burden on correctly identifying such functional contexts which may prove difficult as the contained functionality is not directly linked to a particular business context and hence cannot be easily categorized into meaningful functional contexts. Some of the suggestions include:
⏎
⏎
* Setting the functional boundary according to the specific technology to which the utility service provides an interface e.g. a utility service for talking to an [[ERP software|ERP]] system.
* Identifying the functional boundary according to the category of utility functions e.g. a utility service that performs [[encryption]] and decryption of messages.

<br/>⏎
The utility services are mostly used as helper services from multiple business process-specific logic, each having specific requirements, consequently it is better to design utility services that are based on targeted and specific functional contexts rather than vague functional contexts that pack a range of functions. This is important as it not only helps to keep the maintenance overhead of such services to a minimum but also increases the reuse potential of utility functionality because the service consu(contracted; show full)
* 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)]]