In SOA, by keeping specific details hidden, we protect the integrity of the relationship formed between a service and its consumers. Using abstraction, we allow the service business logic and its underlying implementation to evolve over time while continuing to fulfill its duties in relation to what was originally published in the service's contract.
In the real world, abstraction is really existed; For instance, when you want to buy a car, you don’t need to know everything about the engine and its internal components. Why? Because it will confuse you. Hiding unnecessary information from the buyer protects and simplifies the selling process. In SOA, the scenario is quite similar except we don’t have cars to sell, we have services to publish.
Why Service Abstraction is Needed?
The more details we publish in a service contract, the deeper coupling between service and consumers can become. Or in other words, less Abstraction means that the consumers are more awareness of the underlying service logic, technologies, and internal details of the service. Consequently, the service consumers will naturally judge on the service based on the metadata or extra information.
Another reason why Abstraction is required is to empower the service providers the freedom to enhance their services. By abstracting the implementation details from the service contract, the service provider can modify the underline logic without effecting the coupling between the published service and its consumers.
Design Characteristics
Providers hide unnecessary information (underlying technology, logic, internal constrains, etc) from the service consumers. The information altogether is hidden in a particular environment that may be accessed by the internal members of the service's organization.
Requirements
Providers need to spend more time on the design phase to concisely define the interaction requirements and public service constrains. This process can be integrated with a governance methodology.
Types of Metadata
In order to abstract non-essential metadata, we need to classify them first. Generally, there are four types of metadata in service oriented architecture:
Technology metadata
the metadata that declares the implementation technology of the service. Abstracting the technical metadata from the service contract reduces technology-to-contract coupling. An example of technology metadata is the underline implementation technology of the service such as "this service has been built using .Net technology and for implementation we used Visual Studio 2005".
However, some technical metadata are required to be published. For instance, How the service can be invoked? What technology required to invoke the service? Is it SOAP or REST? Publishing these details does not affect the integrity of coupling. It just guides the consumers.
Systematic Logic metadata
The metadata that explains the underline logic and how it maintains its goals and capabilities. The underline design details (such as logging details, algorithms, database drivers, etc) are usually hidden from the service consumer. Without abstracting this metadata, a service consumer can easily become coupled to the low-level implementation of the service. Consequently, the service publisher may not be abile to modify or adjust the internal implementation.
Functional metadata
The metadata that explains the functional scope of the service. A function scope determines service's capabilities that are made publicly available through the service contract. In OOP, API often abstracts and maintains a set of generic functions considered those most likely to be used to clients that may need to develop an application capable of connecting with the product, In SOA, the technical contract is the service API.
Quality of Service metadata
In the field of computer science, the Quality of Service (QaS) term refers to resource reservation control mechanisms rather than the achieved service quality. Similarly, In SOA, it refers to the behavioral, runtime polices, reliability-related information about the service.
Web service policies are a common form of service description document that explains the QaS of the XML service. Depending on the runtime environment and the capabilities of the hosting service provider, the qulity of service metadata may need to be placed in the non-technical service document. or SLA (Service Level Agreement).
Like other metadata, it is a good idea to publish some of the Quality of Service metadata to the service consumer. An example of the Quality of Service metadata is 'the availability of the service' as shown:
Posts
