Define Message contracts

So far we’ve looked into the ways of controlling the underlying service metadata on the client and the server. This time, we’ll inspect how to customize the message itself, with the help of message contracts.

As you could guess, there are a bunch of attributes which help us implementing this task. It’s good to know your enemy from the beginning, so here are them:

• MessageContractAttriubte: this attribute let’s you control the mappings between your custom types and their SOAP representations.
• MessageBodyMemberAttribute: the given field/property will be serialized as a member of the SOAP body.
• MessageHeaderAttribute: surprise! The given field/property will be serialized into a SOAP header.
• MessageHeaderArrayAttribute: defines that no wrapper element should be written to the specified array (each value in the array will be an independent element).

Well, only four attributes. That’s not a big deal for us, so let’s dive into the details!

Define Operation contracts

It is clear that in order to be able to call your service, you need to mark the contract interface/class with the ServiceContractAttribute. After this post, it’ll be also clear that you must mark your exposed methods with the OperationContractAttribute. In most cases you’ll be satisfied with the default settings, but there are certain cases (one-way or duplex messaging pattern) when you need to customize the OperationContractAttribute.

Fortunately, it exposes a set of named parameters for implementing such behaviors. Here’s a brief list of them:

Named Parameters of OperationContractAttribute
Action	Controls the action on the request message. The default value is the fully qualified name of the method as an address, for example: http://TheServices/IContract/MyMethod. Set it to an asterisk to indicate an operation which handles all unmatched requests. There’s a constraint on this: there can be only one method like this, and it must take a message as parameter.
AsyncPattern	A Boolean value indicating whether the current pattern is asynchronous.
IsInitiating	A Boolean value indicating the marked method is the initiation of a session. The default is true.
IsOneWay	A Boolean value indicating that the operation returns nothing, and has no output parameters. The default is false. When you set this to true, and return anything else than void, an InvalidOperationException will be thrown at run time.
IsTerminating	A Boolean value indicating that after this method the session should be terminated, and the channel closed.
Name	Overrides the operation name from the default value: the contract’s method name. This is interesting from the clients point of view. They can call your through the proxy class by the name you specify here (think about IntelliSense support).
ProtectionLevel	A member of the System.Net.Security.ProtectionLevel enumeration, indicating the level of protection required by the method.
ReplyAction	Controls the action on the reply message. Use it in conjuction

Define Data contracts

If you could recall the previous post about Service contracts, I mentioned that you must use serializable types as return/parameter types in your exposed methods. When you build custom types (and you’ll certainly do so) you’ll need to tell WCF either implicitly or explicitly how to serialize your types.

The implicit way is to mark your custom types as serializable, with the SerializableAttribute class. This isn’t too exciting, and doesn’t require you to use data contracts, which are cooler, and will be covered by the exam test. Anyway, you should know that all publicly visible properties and fields will be serialized when you use the implicit method.

The explicit way is to mark your custom types with the DataContractAttribute and the fields/properties with the DataMemberAttribute. Then you’ll gain a finer control over how WCF will serialize and deserialize those types. The DataContractAttribute has the following named parameters:

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