SOA Patterns > Logical Inventory Layer Patterns > Utility Abstraction
Utility Abstraction (Erl)
How can common non-business centric logic be separated, reused, and independently governed?
Problem
When non-business centric processing logic is packaged together with business-specific logic, it results in the redundant implementation of common utility functions across different services.
Solution
A service layer dedicated to utility processing is established, providing reusable utility services for use by other services in the inventory.
Application
The utility service model is incorporated into analysis and design processes in support of utility logic abstraction, and further steps are taken to define balanced service contexts.
Impacts
When utility logic is distributed across multiple services it can increase the size, complexity, and performance demands of compositions.
Architecture
Inventory, Composition, Service
Cross-cutting utility logic is identified with the help of enterprise technology architecture specifications and then abstracted into a layer of dedicated services based on the utility service model.
Related Patterns in This Catalog
Agnostic Context, Agnostic Sub-Controller, Canonical Expression, Concurrent Contracts, Cross-Domain Utility Layer, Exception Shielding, Legacy Wrapper, Logic Centralization, Message Screening, Metadata Centralization, Process Abstraction, Redundant Implementation, Rules Centralization, Service Agent, Service Decomposition, Service Layers, Service Perimeter Guard, Stateful Services
Related Service-Oriented Computing Goals
Increased ROI, Increased Vendor Diversification Options, Reduced IT Burden