Difference between revisions 804662963 and 804663066 on enwiki

{{Use dmy dates|date=October 2017}}⏎
{{notability|date=March 2010}}
'''Utility Aabstraction''' 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] {{webarchive |url=https://web.archive.org/web/20120501123049/http://www.whatissoa.com/p11.php |date=1 May 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 a helper functionality for sending out emails, so in this case, the email functionality is not directly required, however, to complete the processing of invoices, the parent processing logic makes use of this non- business related functionality.</ref> related functionality, which can be positioned as utility resources to automate multiple business processes.

==Rationale==
In order tTo automate a business process, the required solution logic is based on the corresponding business work-flow and the business rules. Although the business specific logic can be derived from the business domain, however, in order to complete the automation of the business process, some general purpose logic is normally required that cannot be derived from the business domain. Such logic usually offers low level generic functionality that is commonly required to automate multiple business processes e.g. logging incoming service request messages for metering purposes. As different business processes are analyzed, the corresponding general purpose utility logic is identified and delivered as part of the 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]]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] {{webarchive |url=https://www.webcitation.org/5wB481EYJ?url=http://www.whatissoa.com/p13.php |date=2011-02-01 February 2011 }}</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 tTo 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.] {{webarchive |url=https://www.webcitation.org/5wB4T8QrA?url=http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=2011-02-01 February 2011 }} [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.]]
This design pattern provides practical guidelines for designing the utility service layer as advocated by the [[Service Layers Pattern|Sservice Llayers]] 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 (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] {{webarchive |url=https://www.webcitation.org/5wB4SzA1B?url=http://www.whatissoa.com/p12.php |date=
2011-02-01 February 2011 }}</ref> will become complex and difficult to maintain.

== References ==
{{Reflist}}
* [[Thomas Erl|Erl]] ''et al.'', (2009).[https://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)]]