This post dives into the technicalities of what a service in WCF can do and how you can configure this. We are going to start with the ServiceContractAttribute and its properties. We proceed with the OperationContractAttribute and finish with the ways an operation can be invoked in WCF.

ServiceContractAttribute

  1. We will learn the following:
  2. Mapping of service to a .Net class/interface
  3. Why you should always use the Namespace Property
  4. Session mode and the other properties
  5. How to specify contract operations with the OperationContractAttribute

The ServiceContractAttribute is defined as follows:

Because WCF uses SOAP internally, you need this ServiceContract to map a C# class or preferably an interface to an exposed service. Preferably an interface, because it is easier to implement a new service, and to not mix servicebehavior and method definition.

For a service to be visible for WCF a .Net interface needs to apply the contractattribute. Remember that visibility, and other CLR concepts are not applicable. Only methods are relevant. And only if they are decorated with the OperationContractAttribute.

So this service would be visible, but only the InvokeableServiceMethod can be seen by a consuming client, because it has the OperationContractAttribute. So the method NonInvokeableMethod can not be invoked by a client (as the method name implies).

To make use of such a service you’ll need to create a class that implements the IMyWcfService interface. Note that WCF only calls the default constructor on this class. We will look into this with hosting and setting up a client and a service. (see)

Why you should always specify a Namespace and Name

Again, because WCF maps to SOAP messages, everthing you configure, or do not configure is translated to WSDL. So if you do not give your ServiceContract a namespace it will use http://tempuri.org in the WSDL.

It is a best practice to define the namespace as well as the name. This not only aids debugging but also makes your service explicit. It shows clear intent, which is always a good thing in programming. But most importantly it will help you to version your service explicitly on the URI.

Typically you use the domain for the namespace and the classname of the service for the Name property:

As you can see I silently put in parameters in the InvokeWithParameters method. This is only to show that it is totally applicable in WCF to have parameters and return types (again as would be in SOAP).

For primitive types like String, int and so on it is not a big deal. Yet I supplied a CustomType parameter. To use a custom type you will need to supply this type with the DataContractAttribute. This is a topic on its own. Therefor in this post I will proceed with the SessionMode and will revisit the DataContractAttribute in another post, just remember that there is a way to supply your custom types with WCF services.

On to the other properties and their meaning.

SessionMode

The Sessionmode is used to specify a required binding, that explicitly allows the defined session mode. It has three modes: Allowed, NotAllowed and Required.

The sessionmode can be best used with the InstanceContextMode property on the ServiceBehaviorContractAttribute on the implementing class to further define the execution behavior of a service.
We will explore how they work together in my post about InstanceManagement.

CallBackContract

When supply a Type for the CallBackContract property and use an appropriate binding for duplex calls, like WsHttpBinding, NetTcpBinding or NamedPipeBinding (see Endpoint) and register it with the client or service (see WCF Callbacks) you can use service side callback invocation on this type.

ConfigurationName and ProtectionLevel

The ConfigurationName is simply used to match the name that is supplied in a configuration file like the app.config/exe.config or web.config.
The ProtectionLevel property is used to specify how the service requires encryption and digital signatures, or both. Whatever value is applied here is used for all operation messages, which also includes fault propagation.

Summary

We saw what the ServiceContractAttribute is made of and on a basic level how to apply the Attribute in conjuction with the OperationContractAttribute and the DataContractAttribute to specify the details of your exposed service.

Next up we will look what the OperationContractAttribute supplies.

Leave a Reply