Introduction
The service contract is probably the most important thing/document/artifact that you'll be creating or using concerning a SOA implementation. This is what technically defines a service, what it will look like, what it is capable of doing and how it's going to do it.

Standardized Service Contract
A service contract should be standardized by industry and design standards, this will greatly enhance interoperability with other vendor platforms and internal applications/services. The contract is created after the service analysis and modeling but before the implementation of the service. It's important to use contract-first design to avoid any dependencies from the contract on a specific implementation or technology. The service implementation and consumers must depend on the contract but not the other way around.

Contents
The contract will contain the following technical "documents" (not necessarily human readable documents):
- service definition, this contains the technical details of the service and its capabilities (headers, methods...)
- data definitions, this shows what the exchanged data will look like

When implementing the services as Web Services this will correspond to WSDL and XSD respectivelay. Besides these documents you might also have policy definitions when using Wew Services (WS-Policy) to enforce security or other enterprise policies.

Besides the technical documents there can also be other (non-technical) documents included in the contract such as an SLA.

The above documents can all be created independently from each other. Data and policy definitions can and should be used by different services when appropriate. This will greatly enhance the interoperability between applications and services, if different services in the enterprise use the same data but use different definitions you'll have to make data transformation and integration efforts, this is exactly what SOA wants to avoid.

Governance
The governance is also important to contracts, someone must "own" the contract and preferably not by a specific project. This is necessary to have a successful evolution of the service an to avoid that one party can make breaking changes to the contract.