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.
As a consumer, he can view and consume all service interfaces without worrying about the implementation.
All the enterprise services by SAp are abstract.Example :Create Sales Order.This operation internally calling many other services,but for the consumer its a simple interface
Regards, Anil
While posting something as a blog on SDN is always appreciated, but it is not expected to be copied from somewhere else directly. It is against SDN rules. Only original works are supposed to be blogs.
I see that the same blog is posted at different places by different users and the same is pasted here.
http://therealsap.blogspot.com/2010/12/soa-design-principles-service.html
http://www.itlconline.com/serviceabstraction.htm
Please see to that you are posting your own content here on SDN.
Regards,
Vijay
This is also fine. At the last of the above site you will notice my name and profile. 🙂
I found the basic message of blog - abstraction is good - valuable, but
+ Services have many cross-cutting concerns
like security, routing, protocoll & transaction
handling. This have to be handeled.
+ You have to divide between design time,
configuation, runtime and "administration" time.
+ Your example each system (SAP & Oracle)
each system deliver a service. Two will be have
a wrapper. The layer layer needs to be connect
by a kind of transformation service.
All the best & Merry chrismas & Happy new year,
Guido
P. S.: Hello Larry, are you alredy for service on buisness object level or SQL your language of choice,. 😉 Alreday driven COLD fusion.
Using SAP Process Integration you can connect to any backend system ( such as database) and expose you SQL query as an enterprise service. JDBC adapter of SAP PI fulfil the feature 🙂