Software in general is required to conform to a defined functional interface, and services are no different in this respect. For example, web service interfaces defined in WSDL (Web Service Definition Language) allow the definition of data types, input and output messages, operations, invocation protocols, and even the location of services. WS-Policy may be additionally used to define additional elements of the interface such as security policies.
Interfaces are however very weak on the behavioural aspects (semantics) of services. A service could return structurally correct data to a consumer but still not meet its functional obligations. Ensuring that services satisfy the behavioural contract is best done through automated test suites in my experience. Perhaps one day we will be able to define pre- and post-conditions and have these verified by the service management software but I wouldn't hold your breath.
In addition to functional obligations, services also have operational obligations both the consumers but to their operators. In other words service contracts are much more like SLAs and OLAs than traditional functional interfaces.
Contracts should ideally be kept in the service registry/repository, and where possible in a machine readable format to be used by service management software to help enforce the contracts at runtime.
Of course such runtime enforcement of contracts comes with a performance penalty, but lets not spoil a lovely ideal with picky details... ;-)
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