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 [1] 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 service level agreement) 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.
A service contract that contains details about what it encapsulates (e.g., the logic, implementation and the technology used to build the service) may end up being used in a particular manner by providing the service consumer more knowledge about the working of the service. In the case of service-orientation, more knowledge is not necessarily better. There is a chance that additional information could impede the reusability of the service as the service consumer designer may streamline his design based on this knowledge. However, doing so 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. This increases the consumer-to-contract type of coupling, which is a positive type of coupling. However, 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. [2]
The application of this design principle requires looking into four different types of abstractions that could be applied to a 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 [3] 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.
Quality abstraction relates to the details provided within the service’s accompanying service level agreement. It is 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 sit 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 quality of service 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 re-usability 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 [4] and exception shielding [5] design patterns.
Service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies. 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.
In computer software, a data access object (DAO) is an object 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 some specific data operations without exposing details of the database. This isolation supports the single responsibility principle. It separates what 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, database schema, etc..
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 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.
Within the service-orientation design paradigm, service loose coupling is a design principle that is applied to the services in order to ensure that the service contract is not tightly coupled to the service consumers and to the underlying service logic and implementation. This results in service contracts that could be freely evolved without affecting either the service consumers or the service implementation.
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 of 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 something cannot be used if people cannot find it or do not understand what it can be used for. Metadata, or "information about information," such as a book's title, a product's description, or a website's keywords, affects how discoverable something is on a database or online. In the 2010s, adding metadata to a product that is available online can make it easier for end users to find the product. For example, if a song file is made available online, making the title, name of the band, genre, year of release, and other pertinent information available in connection with this song file will make it easier for users to find this song file. Organizing information by putting it into alphabetical order or including it in a search engine is an example of how to improve discoverability. Discoverability is related to, but different from, accessibility and usability, other qualities that affect the usefulness of a piece of information.
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.
Service layer is a design 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.
Canonical Protocol is a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory, interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.
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.
Utility abstraction is a design pattern, applied within the service-orientation design paradigm, which advocates designing services that provide cross-cutting non-business related functionality, which can be positioned as utility resources to automate multiple business processes.
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.