Define Service contracts

A service contract is used to define the set of operations a service exposes, its signature, the data types used, the location of the operations and the specific protocols and serialization format of the service.

In WCF, the best practice is to define the service contract as a .NET interface, and implement that interface by your service class. If you expose only some static and not-too-often changing methods in your service, you can omit the interface, and define the contract in the class.

To define the WCF service contract, you’d typically mark your contract interface with the ServiceContractAttribute, but more on this a little bit later.

At the end of the day, XML service contracts will be generated based on your interfaces and contracts, which can be exposed (and understood) by other applications, even those running on different platforms. This is the real power of services, in one word: interoperability.

Now enough of such high level abstraction, let’s dig ourselves into the layer where the actual work is done, and see how to design and implement our service contracts. First the design:

In SOA (Service Oriented Architecture) a service is a self-explaining unit of functionality. Viewed from this aspect, a class or interface is nothing more than a group of related methods and functions, exposed to the client.

Generally, it’s a better idea to use .NET interfaces as service contracts, because:

• Service contract interfaces can extend any number of other contract interfaces
• A class can implement any number of interfaces, thereby any number of contracts
• You can easily modify the service implementation in the class, while the service contracts encapsulated in an interface remains the same
• Versioning is enabled by implementing the old interface in a new one