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.
Agility via Reuse
Service orientation promises reuse in all services, no matter whether or not immediate requirements for reuse are present. Such a fundamental principle impels us to pay close attention to each of the units delivered of automation logic that we wish to deem services.
The main strategic goal that is generally associated with the idea of reuse is the need to position every service as an Information Technology asset with repeatable value. As the quantity of reusable assets increases, so do the chances of fulfilling new Business automation requirements through building less and utilizing more of what already exists.
Such an action is expected to reduce the amount of time it takes to construct automation logic, thus improving the Business’s overall responsiveness to change. Through decreasing the associated effort, fulfilling automation requirements also becomes more cost effective. This leads to a major potential of streamlining Information Technology development environments.
While this might sound unlikely, a lot of Businesses nowadays are heavily investing in creating reusable service inventories as a means of capturing such benefits. Such a principle facilitates all forms of reuse, including composition, inter application interoperability, as well as the creation of utility services and cross cutting.
As has been discussed earlier, a service is merely a collection of operations that are related in some way. It is thus the logic that is encapsulated by the individual operations that has to be deemed reusable in order to warrant representation as a service that is reusable.
By emphasizing far reaching reuse, the suitability of utilizing web services as an implementation option for services is also highlighted. Through making every available through an industry standard communications framework, the potential of reuse is drastically enriched owing to the fact that the logic that is encapsulated by a service now becomes readily accessible to service requestors that have been built with several underlying technologies.
The Service Contract
Both principles reiterate the need of a quality service contract. The content of such a contract should determine what shall be and what shall not be abstracted. Through the design of such content, we will be able to determine how reusable and generic non abstracted parts shall actually be.
This raises the need to view a service’s design as an investment. The construction of service oriented solution logic is nearly always infinitely more expensive and time consuming owing to the fact that considerations have to be taken into account that transcend immediate tactical requirements. Thus, it is necessary to fully understand and appreciate what service orientation is meant to accomplish in order to justify the heavy investment.
