SOA Design Principles – Service Abstraction

Service Abstraction is one of the important principles of service design. Using service abstraction, provider can abstract technical and implementation service logic from the consumers. Application of this principle converts services into back box. The consumer has only required functional and technical information, which goes in service contract.

The key question is why we understand and apply service abstraction during the Service design? To answer this question let’s take an example a service ValidatePassport.

A service ValidatePassport contains different service operations. GetPassportDetails, for instance, is one of the operations that takes the passport details such as passport number, country of issue, etc and return the passport details. The moment consumers trigger the service he wants response back. To full fill this contract, a provider implemented a service and used different systems resources such as Middleware, SAP system, and Oracle database. At runtime service ValidatePassport check the system which is up and running. And accordingly it will read the details from one of the system and send the response back to the caller.

In this instance a provider uses different systems, applications, and programming logics. If provider does not abstract this information from the consumer then consumer can assume many things and make wrong judgment at the time of implementing the service at his end. Moreover, each time provider has to notify consumer if there is change in system, programming language, or implementation logic. Hence service abstraction gives freedom to owners to evolve their service and change implementation logic as required.

What is Service Abstraction?

• Hiding design details and implementation logic from the outside world.
• Turning service to a black box by hiding systems information, processing logic, and programmatic (Java, ABAP etc) approaches.

Why Service Abstraction require?

• Encourage provider to share less information with outside world.
• Give freedom to consumers to implement service efficiently – without any assumptions and wrong judgments.
• Encourage service provider to advance the service using different IT technologies and IS systems.

What shouldn’t goes in service contract is identified by the service abstraction?

• Technical and implementation logic of the service
• Programmatic logic such as technical systems, programming languages, and technical frameworks.
• Systems processing details –involvement of systems when service is executed.
• Business rules that process service request for different input messages.
• Systems resources, internal validation, error handling, authentication, certificates, and business process etc.
• Uncertain conditions such as availability of the service, possibility when service can become less responsive, etc.
• Composite services description and details – if main service is composed of many other services.