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

Another design consideration comes into the picture when you think about methods. All methods have the following signature:

[Return type] Method Name [Parameter list]

And there are types of types (what a beautiful explanation): value and reference types. Given the nature of services, passing a memory reference as a parameter (or return type) of a method makes little sense. In their case, a reference object is copied and passed. Therefore, when you work with services, you must use serializable types.

There are three MEPs (Message Exchange Patterns) when it comes to services: Request-Reply, One-Way and Duplex. The first two will be explained in the following post about Operation contracts, the third here, because of its setup. As you can guess, in the Duplex pattern both the client and the service can send messages to each other, regardless of previous communication (this is the main difference between Duplex and Request-Reply). To design a Duplex contract, you must create a callback contract, and place its type into the CallbackContract named parameter of the ServiceContractAttribute.

Now let’s see a table about the named parameters of the ServiceContractAttribute, and what do they control:

CallbackContract When the Duplex pattern is used, this defines the type of the callback contract to use.
ConfigurationName The name used to identify the service contract in configuration files.
Name The name of the portType element in WSDL.
Namespace The namespace of the portType element in WSDL.
ProtectionLevel The protection level of the service, can be set to a member of the  System.Net.Security.ProtectionLevel  enumeration.
SessionMode The mode of the session, can be Allowed, NotAllowed and Required.

 

We’ve talked so much about service contracts, let’s see one to end this post:

[ServiceContract]
interface ISayHello
{
[OperationContract]
public string Hello(string name);
}
public class theService: ISayHello
{
public string Hello(string name)
{ return “Hello” + name; }
}

Further Readings

Designing and Implementing Services

Designing Service Contracts

Implementing Service Contracts

One thought on “Define Service contracts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s