Entity Abstraction Pattern
Entity Abstraction is a design pattern, applied within the service-orientation design paradigm which provides guidelines for designing reusable services[1] whose functional contexts[2] are based on business entities.[3]
Rationale
The automation of a business process involves the analysis of the business domain and then designing solution logic that represents the different steps within the business process. Some of these steps relate just to that specific business process while others may be of use to other business processes as well. Part of this reusable logic pertains to the business entities[3] that usually remains the same when compared to the rules and processing steps that may change in future. If services are designed that contain both process-specific logic and entity-specific logic, the chances of reusing the same entity-specific logic, from another business process, become somewhat negligible. On the other hand, if this kind of logic is split up into a separate container i.e. a service, then any new business processes, which make use of the same business entity, can reuse this logic. Apart from the reusability problem, in order to address the change in the behavior of a business entity, updating the entrenched entity related logic across multiple business processes requires extra efforts and makes the maintenance of such services a complex task.
In response to the aforementioned issues, the Entity Abstraction pattern advocates that logic that relates to the processing of business entities be separated from the process-specific single purpose logic and designed as independent logic that has no knowledge of the overall business process in which such logic is being utilized.[4]
Usage
An ERD showing the relationships between different business entities and their attributes.
Entity specific logic is identified from the above ERD and abstracted away in relevant functional contexts that constitute the entity services.
The separation of reusable entity specific logic requires identification of such logic before the actual services are designed. This requires a top-down Service-oriented analysis and design[5] service delivery process. During the analysis phase,[6] different types of actions that are performed on and by business entities are identified and placed in a relevant process-neutral functional context that forms the basis for entity services.[7] These entity services specifically contain functionality, including CRUD functions,[8] that is only relevant to the physical or logical business entities, represented by their corresponding functional context. Apart from the identification of different actions, it is also important to discover any relationships between the business entities whether part of the current business process or not. By looking across different business processes, the entity service can be packed with extra functionality that may be required by other business processes. An important source of information for identifying such relationships are the ERDs as they physically display the relationships between different business entities and also identify the different attributes of entities that form the basis of the relationships among the entities. The resulting set of services represents the entity layer, which is one of the layers as advocated by the Service Layers design pattern. The application of the Entity Abstraction design pattern can be viewed as a specialized implementation of the [9] Agnostic Context design pattern as the Agnostic Context pattern advocates separating process-neutral logic from the process-specific logic, however, in case of Entity Abstraction pattern it is the entity-specific process-neutral logic that is being separated.
The process of identifying entity services from business entities might not always result in a one-to-one mapping as on some occasions it might be logical to combine two entities into one because on their own they do not represent a significant part of functionality being performed on the entities.[4]
Considerations
The application of this design pattern requires adopting top-down service-oriented analysis and design service delivery process[5] which may not be suitable for organizations that have limited resources, both in terms of time and man-power. Another important aspect is that once the entity-specific logic has been abstracted away in entity services, the dependency on such entity services increases as they become the sole point of contact for utilization functionality that is of interest to multiple business processes. Consequently, it remain very important to have strict governance mechanisms in place so that a change in the functionality of an entity service does not result in behavior that is not expected by the service consumers that have already formed dependencies on such entity services.
References
- ↑ Services
- ↑ The overall purpose i.e. the type of functionality e.g. a functional context based on processing purchase orders, here the functionality is related to the different actions performed on the purchase orders.
- 1 2 Business entities are physical or logical entities that are of interest to the business or something that is a part of the different processes that the business runs.
- 1 2 Matthew Dailey.Software Architecture Design Service-Oriented Architectures (Part II)[Online].Date accessed: 26 April 2010.
- 1 2 Top-Down Service-oriented Analysis & Design Process
- ↑ Service-oriented Analysis
- ↑ Entity Services
- ↑ Susanne Patig.Cases of Software Services Design in Practice[Online].Date accessed: 27 April 2010.
- ↑ Agnostic Context
- Erl et al.,(2009).SOA Design Patterns.Prentice Hall. ISBN 0-13-613516-1.
- Mauro. et al. 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: 27 April 2010.