Difference between revisions 354354792 and 356819558 on enwiki

{{notability|date=March 2010}}
'''Utility Abstraction''' is a [[Design_pattern_(computer_science)|design pattern]], applied within the [[service-orientation]] [[Design_paradigm|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(contracted; show full)gt;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 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:

(contracted; show full)
* [http://www.soapatterns.org/ SOA Patterns]

== 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)]]