Service Abstraction
Encyclopedia
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 i.e. 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 (technical contract and the SLA
) only i.e. no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.
A service contract that contains details about what is encapsulates e.g. the logic, implementation and the technology used to build the service, may end up being used in a particular manner as now the service consumer has more knowledge about the working of the service. Under normal circumstances, the more knowledge we have, the better it is but in case of service-orientation, there is a chance that the additional information could impede the reusability of the service as the service consumer designer may streamline his design based on this knowledge, however, this would affect the evolution of the service contract as now the service consumer is indirectly coupled to the service implementation, which may need to be replaced in the future. In a way, this increases the consumer-to-contract type of coupling, which although is a positive type of coupling but having too much dependence can negatively impact the evolution of both the service provider and the service consumer.
Information hiding
remains one of the key principles within object-oriented paradigm that promotes abstracting away the inner workings of a software program. A classic example would be the use of abstract classes to hide the actual method logic. The same concept is applied by the Service Abstraction principle in order to hide the unnecessary details about the working of the service with a view to ease the evolution of the service.
This form of abstraction is dependent upon how much of the service logic is exposed as service capabilities. An example would be of a class whereby some of its methods are private while others are public. A class would only expose those methods as public that it deems to be important to its objects, any helper methods that are not relevant to the objects are kept hidden.
A service contract which has not been subjected to this principle could be termed as a 'detailed contract' that reveals much of business rules and the validation logic. Once this principle has been applied to a fair degree, the contract could be termed as a ‘concise contract’. Further application of this design principle would result in a 'optimized contract' that maximizes the reuse potential of the service.
Any information about the underlying technology used within the service would result in a low technology information abstraction as the service contract explicitly tells the service consumers how the service logic and its implementation are designed. This extra information might result in service consumers being designed in a way that specifically targets that particular implementation, thereby developing consumer-to-implementation coupling.
The programmatic details about the service logic need to be abstracted as knowledge about how the service actually performs its functionality can result in service consumers that factor in this information and are consequently designed under these assumptions. This can seriously hamper service logic refactoring efforts and can be considered as an anti-pattern towards the application of the Service Refactoring
design pattern.
This kind of abstraction relates to the details provided within the service’s accompanying SLA. It’s important to concentrate only on that kind of information that would actually help in determining the reliability and availability of the service, no other information should be included that exposes unnecessary details e.g. details about how does a service sits within the overall business process and which other services it uses for fulfilling its functionality.
The level of access control applied to a service would decide how much of technology, logic and QoS abstractions are in place. An 'open access' would provide free access to everyone that is interested in finding out the design specifications of a service. In a 'controlled access', only authorized people are granted access and a 'no access' policy would totally deny any access to the design documents.
Although information hiding is considered a healthy practice, however, too much of information hiding could be counter productive as it can limit the reusability level of the service. This can also result in redundant services as service designers don’t have enough information about the capabilities of the service. For this, each service contract needs to be designed in a concise yet comprehensive manner so that the service’s capabilities can be effectively discovered and interpreted as dictated by the Service Discoverability Principle
.
The kind of information exposed in the service contract can lead to some security related concerns as well. For example, a service that propagates the details about the database in use as result of an internal error can fall a victim to an attack where the attacker makes use of the reported error details and attempts to connect to the database. This could be addressed by the application of the Message Screening and Exception Shielding design patterns.
Service-orientation
Service-orientation is a design paradigm to build computer software in the form of services. Like other design paradigms , service-orientation provides a governing approach to automate business logic as distributed systems...
design paradigm
Design paradigm
The term Design paradigm derives from the rather ambiguous idea of paradigm originating in Sociology of Science, which carries at least two main meanings:...
so that the information published in a service contract is limited to what is required to effectively utilize the service i.e. 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 (technical contract and the SLA
Service Level Agreement
A service-level agreement is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time or performance...
) only i.e. no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.
Purpose
A service contract that contains details about what is encapsulates e.g. the logic, implementation and the technology used to build the service, may end up being used in a particular manner as now the service consumer has more knowledge about the working of the service. Under normal circumstances, the more knowledge we have, the better it is but in case of service-orientation, there is a chance that the additional information could impede the reusability of the service as the service consumer designer may streamline his design based on this knowledge, however, this would affect the evolution of the service contract as now the service consumer is indirectly coupled to the service implementation, which may need to be replaced in the future. In a way, this increases the consumer-to-contract type of coupling, which although is a positive type of coupling but having too much dependence can negatively impact the evolution of both the service provider and the service consumer.
Information hiding
Information hiding
In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed...
remains one of the key principles within object-oriented paradigm that promotes abstracting away the inner workings of a software program. A classic example would be the use of abstract classes to hide the actual method logic. The same concept is applied by the Service Abstraction principle in order to hide the unnecessary details about the working of the service with a view to ease the evolution of the service.
Application
The application of this design principle requires looking into four different types of abstractions that could be applied to a service.Functional Abstraction
This form of abstraction is dependent upon how much of the service logic is exposed as service capabilities. An example would be of a class whereby some of its methods are private while others are public. A class would only expose those methods as public that it deems to be important to its objects, any helper methods that are not relevant to the objects are kept hidden.
A service contract which has not been subjected to this principle could be termed as a 'detailed contract' that reveals much of business rules and the validation logic. Once this principle has been applied to a fair degree, the contract could be termed as a ‘concise contract’. Further application of this design principle would result in a 'optimized contract' that maximizes the reuse potential of the service.
Technology Information Abstraction
Any information about the underlying technology used within the service would result in a low technology information abstraction as the service contract explicitly tells the service consumers how the service logic and its implementation are designed. This extra information might result in service consumers being designed in a way that specifically targets that particular implementation, thereby developing consumer-to-implementation coupling.
Logic Abstraction
The programmatic details about the service logic need to be abstracted as knowledge about how the service actually performs its functionality can result in service consumers that factor in this information and are consequently designed under these assumptions. This can seriously hamper service logic refactoring efforts and can be considered as an anti-pattern towards the application of the Service Refactoring
Service Refactoring
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.-Rationale:...
design pattern.
Quality of Service Abstraction
This kind of abstraction relates to the details provided within the service’s accompanying SLA. It’s important to concentrate only on that kind of information that would actually help in determining the reliability and availability of the service, no other information should be included that exposes unnecessary details e.g. details about how does a service sits within the overall business process and which other services it uses for fulfilling its functionality.
The level of access control applied to a service would decide how much of technology, logic and QoS abstractions are in place. An 'open access' would provide free access to everyone that is interested in finding out the design specifications of a service. In a 'controlled access', only authorized people are granted access and a 'no access' policy would totally deny any access to the design documents.
Considerations
Although information hiding is considered a healthy practice, however, too much of information hiding could be counter productive as it can limit the reusability level of the service. This can also result in redundant services as service designers don’t have enough information about the capabilities of the service. For this, each service contract needs to be designed in a concise yet comprehensive manner so that the service’s capabilities can be effectively discovered and interpreted as dictated by the Service Discoverability Principle
Service Discoverability Principle
Service Discoverability is a design principle, applied within the service-orientation design paradigm, which emphasizes making services discoverable by adding interpretable meta-data to increase service reuse and decrease the chance of developing services that overlap in function...
.
The kind of information exposed in the service contract can lead to some security related concerns as well. For example, a service that propagates the details about the database in use as result of an internal error can fall a victim to an attack where the attacker makes use of the reported error details and attempts to connect to the database. This could be addressed by the application of the Message Screening and Exception Shielding design patterns.