Difference between revisions 351031584 and 354352741 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 sServices]</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 a helper funct(contracted; show full)e main business processing solution logic (within the same service). Although this method 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|databases]], [[Legacy_system|legacy systems]]). On the other hand, it not only denormalizes the 
service inventory<ref name='SvcInv'>[http://www.whatissoa.com/p13.php sService iInventory]</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/>
(contracted; show full)d 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 consumers can easily identify the required generic functionality as it is not bundled up in a broad functional context that does not correctly represent all of its contained functionality. The application of 
Canonical Expression<ref name='CanonicalExpression'>[http://www.soapatterns.org/canonical_expression.php Canonical Expression]</ref> design pattern can further enhance the effectiveness of such targeted functional contexts by advocating the use of standardized naming conventions that correctly describe these functional contexts.

==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 sService cComposition]</ref> will become complex and difficult to maintain.

== References ==
<!--- See [[Wikipedia:Footnotes]] on how to create references using <ref></ref> tags which will then appear here automatically -->
{{Reflist}}
* Erl et al,(2009)."[http://www.amazon.com/gp/product/0136135161/ref=s9_simi_gw_p14_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=0FBSA23BKC0AXWVZ5Q9G&pf_rd_t=101&pf_rd_p=51471022&pf_rd_i=507846 SOA Design Patterns]". Prentice Hall. ISBN 0136135161
* [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)]]