Services must be abstract in the sense that they offer a functional interface that is not tied to any particular underlying implementation of that interface. In other words they should hide implementation details such as programming language, operating system platform, database structure, internal object model, etc. Abstraction supports other service characteristics such as reusability, extensibility and reduces coupling between producer and consumer.
The degree of service abstraction that is achieved is often linked to whether the service was designed top down or bottom up.
Top down services begin with business domain model and processes which translate ultimately to service operations and types, e.g. in the form of WSDL and XML schema in the case of web services. Such services will offer the highest level of abstraction since are designed without an implementation in mind. However, top down services require a translation between the interface and implementation which can sometimes introduce a performance penalty, e.g. translating business keys to database identifiers.
Bottom up services begin with an implementation and typically involve the use of toolkits to generate the service interfaces. Such services are closely coupled to their implementations and consumers. However, bottom up services are enticing because firstly they offer the ability to quickly expose existing code as services, and secondly because they allow the use of implementation specifics such as database identifiers to improve performance.
These gains offer a false economy and should be resisted. The long term gains of well designed, adaptable services that reflect a business domain far outweigh any short term performance or time to market gains.
You may also like:
Service Characteristics - Contract
Service Characteristics - Abstract
Service Characteristics - Composable
Service Characteristics - Autonomous
Service Characteristics - Discoverable
Service Characteristics - Distributed
Service Characteristics - Reusable