 | This article's tone or style may not reflect the encyclopedic tone used on Wikipedia.(March 2011) |
Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service [1] so that either the service logic or its implementation can be changed without affecting the service consumers.
It is natural for a service to undergo changes for various reasons. The change could be required because the underlying implementation e.g. databases, legacy systems, etc. needs to be upgraded or simply because the original service logic was not making efficient use of memory. In other cases, the change could be initiated by the service consumers themselves. For example, with limited concurrent usage, the service performs as stated in its SLA, however, with an increase in its concurrent usage, the service is unable to fulfill its SLA, consequently the service needs to respond to the increasing performance demands from its service consumers. [2]
This situation needs to be dealt with in a manner so that the service is upgraded without affecting its consumers that have already formed dependencies on the service. Although one could argue that responding to any of the aforementioned requirements should not be problematic as long as the service honors its contract. However, we are concerned with both the outcome from the execution of service capabilities [3] and also with the behavior and reliability of the service. The Service Refactoring design pattern provides a strategy that strives to ensure a service can evolve without negatively affecting its consumers. [4]
The application of this design pattern advocates the use of traditional software refactoring techniques. The focus is on refactoring the service in smaller steps so that the impact of each step is small enough to the reversed in case such a change negatively affects the service consumers. Secondly, to ensure the service contract remains unaffected by changes in logic or implementation, the service contract must be decoupled as much as possible. [5] This can be done by introducing a façade component [6] between the service contract and the service logic. However, this is only possible if the service contract is physically decoupled from its implementation in the first place, which could be accomplished by the application of the Decoupled Contract [7] design pattern. This could further be strengthened by the application of the Contract Centralization [8] design pattern that advocates establishing the service’s contract as the only official entry point into the service.
On the other hand, to insulate service logic from negative effects from changes in the service implementation, the Service Façade design pattern could be reapplied to introduce another façade component between the service implementation and the service logic. The application of the Service Abstraction principle can further help to reduce the possibilities of any detrimental effects caused by the application of this design pattern. [9]
The application of the Service Refactoring design pattern requires extensive testing to ensure a reliable and proven service, although inefficient, carries on the same level of behavioral stability and reliability. This might increase the project costs and would require additional quality assurance procedures and strict governance.
On the other hand, with its application, there might be a change to the current abstraction levels of the service, which would in turn require reapplication of the Service Abstraction design principle to ensure the service maintains the right level of abstraction. In some situations it might be impossible to constrain the effect of changes in the service logic or its implementation, and inadvertently the service contract must be updated. In this case, the Concurrent Contracts [10] design pattern could be applied so that the service continues to entertain its consumers that have formed dependencies on its old contract while at the same time providing the updated contract that is in line with the updated service logic or service implementation.
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these. Some computer hardware devices, such as a touchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.
In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. 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 software, a data access object (DAO) is a pattern that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence layer, the DAO provides data operations without exposing database details. This isolation supports the single responsibility principle. It separates the data access the application needs, in terms of domain-specific objects and data types, from how these needs can be satisfied with a specific DBMS.
In computing and systems design, a loosely coupled system is one
An open service interface definition (OSID) is a programmatic interface specification describing a service. These interfaces are specified by the Open Knowledge Initiative (OKI) to implement a service-oriented architecture (SOA) to achieve interoperability among applications across a varied base of underlying and changing technologies.
Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.
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.
The event-driven messaging is a design pattern, applied within the service-orientation design paradigm to enable the service consumers, which are interested in events that occur within the periphery of a service provider, to get notifications about these events as and when they occur without resorting to the traditional inefficient polling based mechanism.
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.
Logic Centralization is a design pattern, applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic by ensuring that services 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.
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.