Service Abstraction

Service Abstraction

One aspect of service orientation that is connected directly to loose coupling and service contracts is abstraction. Through abstraction, we are able to control the parts of the underlying service logic that are to be exposed to the external world. Through ensuring that such parts have been designed in a generic fashion as a means of accommodating numerous potential service requestors, the service may be positioned as a reusable Information Technology asset. In this article, we will take a look at different levels of abstraction before moving on to a discussion about how reuse may support Service Oriented Architecture’s overall strategic goals.

The Abstraction of Technology and Functionality

Abstraction is also known under its full name as service interface level abstraction. It is this principle that allows us to establish services as black boxes, hiding their underlying details from potential customers. Abstraction is achieved through a discipline utilization of service contracts.

Through limiting what is made public about a service to what is documented in the service contract, a high level of separation can often be attained between what emerges as public and private. This is because of the fact that it is supportive of loosely coupled relationships.

The amount of logic that a service may represent is indeed limitless. Services can be designed to perform simple tasks. They may also be positioned to serve as gateways to entire automation solutions. There is no restriction when it comes to the source of automation logic a service is able to draw upon.

A single service, for instance, may expose logic from several different underlying systems. As the standardization of service models is something that is moved towards as a means of establishing functional contexts associated with given Business tasks or entities, it becomes a given that in environments that have a number of different legacy solutions, at least one service will commonly expose functionality that relies on a number of different systems.

Distributed platforms provide service interface level abstraction as one of its main qualities. Distributed platforms also provide web services based architectures. The utilization of web services can be especially synergetic owing to the fact that they elevate the degree of attainable abstraction beyond functionality.

Web services serves to abstract proprietary implementation details of the automation logic that lies beneath the service. This effectively frees up potential consumers of the service from the strain of having to interface with particular vendor technologies.

Despite the fact that abstraction can be viewed as a service characteristic, in truth it is the individual operations that work to collectively abstract the service’s underlying logic. Services merely perform as containers for such operations. Any service’s given level of abstraction will thus be determined to a large degree by the collective levels of abstraction that are acquired by each of its service operations.

This puts a lot of emphasis on the service contract’s design. The more that gets expressed in the service contract, the less details have been abstracted.

The more generic the service contract is made up, then the less customer or process specific the service will be. Thus, the reuse potential of what we choose to expose through the service contract is determined.