Logic centralization pattern

Last updated

Logic Centralization is a design pattern applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic [1] by ensuring that services [2] do not contain redundant agnostic logic, and that any reusable logic should only be represented by a service that has the most suitable functional context. [3] [4]

Contents

Rationale

As more and more services are developed, there is a constant risk that services with redundant functionality may be created. Although the application of the Service Normalization design pattern does help to eliminate this redundancy, however, just having a set of normalized services on its own, does not guarantee that they would be reused as originally envisaged. In the case of agnostic services, [5] this issue can severely restrict the actual reuse of such services because a project team (Team A) may decide not to reuse an existing service, e.g. it requires data that corresponds to a complex scheme, and instead develop a lightweight service that does the job. As a result, the same reusable logic now exists with two different services, whereas the existing service should have evolved even if it did not contain the most suitable flavor of the functionality. This effect is exacerbated when another team (Team B) hoping to find the functionality within the existing service, as the boundary of the service does cover the required functionality, fails to find it and instead starts using the newly created service by Team A. Consequently, the actual reusability of the original agnostic service drops and at the same time creates governance problem as far as the maintenance of the original and new services is concerned because now reusable logic exists in a decentralized manner.

To ensure that a particular type of reusable solution logic is only enclosed by one specific agnostic service, the Logic Centralization design pattern dictates that design standards need to be established that force the proper use of agnostic services. This gives the service consumers the confidence that they are accessing the functionality through the correct service. [6]

Usage

Diagram A Instead of using the existing red service, Project Team 1 resort to creating a new redundant red service as it was easy to develop a new service that was more streamlined with their short-term requirements. SOA DP Logic Centralization A.JPG
Diagram A
Instead of using the existing red service, Project Team 1 resort to creating a new redundant red service as it was easy to develop a new service that was more streamlined with their short-term requirements.
Diagram A In the presence of an enterprise-wide design standard, service consumers' access to the redundant red service created by Project Team 2 is prohibited, and instead are forced to use the existing red service created by Project Team 1. Similarly, Project Team 3 is prohibited from creating any new service whose functionality falls within the existing red service, as a result, Project Team 3 uses/evolves the existing red service created by Project Team 1. SOA DP Logic Centralization B.JPG
Diagram A
In the presence of an enterprise-wide design standard, service consumers' access to the redundant red service created by Project Team 2 is prohibited, and instead are forced to use the existing red service created by Project Team 1. Similarly, Project Team 3 is prohibited from creating any new service whose functionality falls within the existing red service, as a result, Project Team 3 uses/evolves the existing red service created by Project Team 1.

The application of this design pattern requires setting up 'official endpoints' (services) that represent a particular type of functionality i.e. the functionality that falls under a particular type of functional domain. Access to any other services, that may offer the same functionality, is prohibited and only one service is made accessible for a particular type of functionality. [7] By restricting access to other services, the governance burden is reduced as now the logic is confined within a single service. Whenever new functionality is required, that is not currently offered by any of the existing services, then first the functional contexts of the existing services need to be checked and if the new functionality falls under the boundary of an already existing service, then it should be added to that service. This requires an enterprise-wide standard that enforces the centralization of logic. To make sure that service developers are aware of the service boundaries, Metadata Centralization [8] design pattern could be applied. This helps in creating a centralized repository of information about the functional contexts and the functionality provided by the services. The Logic Centralization design pattern when applied together with the Contract Centralization [9] design pattern, constitute the Official Endpoint [10] design pattern. The application of the Logic Centralization design pattern further helps in the application of the Service Reusability and the Service Composability design principles by ensuring that each service contains the right type of reusable functionality so that it can be composed repeatedly.

Considerations

To apply this design pattern, it needs to be ensured that all the project teams across the enterprise understand and agree to the proper use of agnostic services and do not create any new services that only serve the short-term requirements of a project. This can also impact the project delivery times as the use of existing agnostic services (and to evolve them as per the guidelines of this pattern) would require increased time and effort. This is because the services in the current project may not be able to make use of the agnostic services until their design is changed.

Related Research Articles

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. SOA is a good choice for system integration. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

<span class="mw-page-title-main">Web API</span> HTTP-based application programming interface used in web development

A web API is an application programming interface (API) for either a web server or a web browser. As a web development concept, it can be related to a web application's client side. A server-side web API consists of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML by means of an HTTP-based web server. A server API (SAPI) is not considered a server-side web API, unless it is publicly accessible by a remote web application.

Security patterns can be applied to achieve goals in the area of security. All of the classical design patterns have different instantiations to fulfill some information security goal: such as confidentiality, integrity, and availability. Additionally, one can create a new design pattern to specifically achieve some security goal.

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).

Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).

In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory that fosters repeated service composition.

Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.

The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.

Service abstraction is a design principle that is applied within the service-orientation design paradigm so that the information published in a service contract is limited to what is required to effectively utilize the service The service contract should not contain any superfluous information that is not required for its invocation. Also that the information should be limited to the serviced contract only, no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.

The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services that can be reused across a business. These reusable services are designed so that their solution logic is independent of any particular business process or technology.

Service autonomy is a design principle that is applied within the service-orientation design paradigm, to provide services with improved independence from their execution environments. This results in greater reliability, since services can operate with less dependence on resources over which there is little or no control.

Service statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in reduction of the resources consumed by a service as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner.

Discoverability is the degree to which something, especially a piece of content or information, can be found in a search of a file, database, or other information system. Discoverability is a concern in library and information science, many aspects of digital media, software and web development, and in marketing, since products and services cannot be used if people cannot find it or do not understand what it can be used for.

In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.

Service normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.

In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.

Entity abstraction is a design pattern, applied within the service-orientation design paradigm which provides guidelines for designing reusable services whose functional contexts are based on business entities.

A canonical model is a design pattern used to communicate between different data formats. Essentially: create a data model which is a superset of all the others ("canonical"), and create a "translator" module or layer to/from which all existing modules exchange data with other modules. The canonical model acts as a middleman. Each model now only needs to know how to communicate with the canonical model and dont need to know the implementation details of the other modules.

In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA).

References

  1. ↑ Logic that does not belong to a specific business process and hence can be reused to automate multiple business processes
  2. ↑ "Services". Archived from the original on 2012-05-01. Retrieved 2010-03-09.
  3. ↑ The type of the functionality provided by the service.
  4. ↑ Kanu Tripathi.Service Transaction Handling Without WS-AtomicTransaction[Online].Date accessed: 25 April 2010.
  5. ↑ Services that contain agnostic logic
  6. ↑ Dennis Wisnosky.Principles and Patterns at the U.S. Department of Defense Archived 2010-09-20 at the Wayback Machine [Online].Date accessed: 25 April 2010.
  7. ↑ Matthew Dailey.Software Architecture Design Service-Oriented Architectures (Part II) Archived 2011-07-24 at the Wayback Machine [Online]. Date accessed: 25 April 2010.
  8. ↑ Metadata Centralization pattern
  9. ↑ Contract Centralization pattern
  10. ↑ Official Endpoint pattern
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.