 |
Logic Centralization is a design pattern within the service-orientation design paradigm that aims to enhance the reusability of agnostic logic. [1] This pattern ensures that services [2] do not contain redundant agnostic logic and that reusable logic is encapsulated within the service that best aligns with its functional context. [3] [4]
As the number of services within a system increases, there is a risk of developing services with redundant functionality. While the application of the Service Normalization design pattern helps eliminate such redundancy, the existence of normalized services alone does not guarantee their intended reuse.
In the case of agnostic services—those containing reusable logic [5] —this issue can significantly hinder actual reuse. For instance, a project team (Team A) may choose not to reuse an existing service if it requires complex data structures and instead develop a simplified service that meets their immediate needs. As a result, the same reusable logic becomes duplicated across multiple services, rather than evolving within the original service. This challenge is further compounded when another team (Team B) searches for the required functionality within the original service but, failing to find a suitable implementation, opts to use the newly created service by Team A. Consequently, the reusability of the original agnostic service decreases, and a governance issue arises due to the decentralized distribution of reusable logic across multiple services.
To mitigate this issue, the Logic Centralization design pattern establishes design standards that enforce the proper use of agnostic services. This approach ensures that a specific type of reusable logic is encapsulated within a single, well-defined service, thereby providing service consumers with confidence that they are accessing functionality through the appropriate service. [6]
The Logic Centralization design pattern establishes designated "official endpoints" (services) that represent specific functional domains. Under this approach, access to alternative services offering the same functionality is restricted, ensuring that only a single service is available for a given type of functionality. [7] By enforcing centralized access to services, governance complexity is reduced, as reusable logic is confined to a single service instance.
When new functionality is required, an assessment is conducted to determine whether it falls within the functional boundaries of an existing service. If so, the functionality is incorporated into that service rather than creating a new one. This approach requires an enterprise-wide standard to enforce the centralization of logic.
To ensure service developers are aware of service boundaries, the Metadata Centralization design pattern [8] can be applied, facilitating the creation of a centralized repository that documents functional contexts and service capabilities. Furthermore, when implemented alongside the Contract Centralization design pattern, [9] Logic Centralization contributes to the Official Endpoint [10] design pattern.
By ensuring that each service contains the appropriate type of reusable functionality, the Logic Centralization design pattern supports the principles of Service Reusability and Service Composability, promoting efficient service composition and reuse.
To implement this design pattern effectively, it is essential that all project teams within the enterprise understand and adhere to the proper use of agnostic services. Teams must avoid creating new services that address only short-term project requirements, as this can lead to redundancy and reduced service reusability.
The application of this pattern may impact project delivery timelines, as integrating existing agnostic services and evolving them in accordance with established guidelines requires additional time and effort. In some cases, services within a project may not be immediately compatible with agnostic services until their design is modified to align with the standardized approach.
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.
In computing and systems design, a loosely coupled system is one
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.
A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.
Service-oriented programming (SOP) is a programming paradigm that uses "services" as the unit of computer work, to design and implement integrated business applications and mission critical software programs. Services can represent steps of business processes and thus one of the main applications of this paradigm is the cost-effective delivery of standalone or composite business applications that can "integrate from the inside-out". It inherently promotes service-oriented architecture (SOA), however, it is not the same as SOA. While SOA focuses on communication between systems using "services", SOP provides a new technique to build agile application modules using in-memory services as the unit of work.
A document-oriented database, or document store, is a computer program and data storage system designed for storing, retrieving and managing document-oriented information, also known as semi-structured data.
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.
Responsibility-driven design is a design technique in object-oriented programming, which improves encapsulation by using the client–server model. It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares. It was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.
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.