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.
