WCF allows you to communicate with clients over any protocol you wish. Unlike ASMX web services, which were just over Http, you now have a choice depending on your client.

The [ServiceBehavior] attribute allows you to apply rules and behavior on a service-wide level. At design time, this allows you to control things such as Concurrency, Instancing, Throttling, Transaction, Session Management, and Thread behavior by setting its properties:

To use the [ServiceBehavior], as with any other attribute in .NET, you can mark the service class and set the appropriate properties — as seen in Listing 3-1.

using System;
using Wrox.CarRentalService.Contracts;

namespace Wrox.CarRentalService.Implementations.Europe
{
    [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
    public class CarRentalService : ICarRentalService
    {
        // service operations
    }
}

In this sample code the [ServiceBehaviorAttribute] is used to establish the service instance lifetime by using the PerCall mode. The ServiceBehaviorAttribute is only a special case of service behavior. Indeed, any ServiceBehavior implements a specific interface called IServiceBehavior with the following methods:

Besides the ServiceBehaviorAttribute, there are many other behaviors implementing the IServiceBehavior interface configurable by using both the config file and the programmatic approach. One of the most used behaviors is the ServiceMetadataBehavior that allows you to publish the service metadata.

As demonstrated in the Listing 3-2, in the config file, under the <system.serviceModel> <behaviors> section, you can set the service behaviors you would like to use.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="Wrox.CarRentalService.Implementations.Europe.CarRentalService"
      behaviorConfiguration="CarRentalServiceBehavior">
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8000/CarRentalService"/>
          </baseAddresses>
        </host>
        <endpoint address=""
                  contract="Wrox.CarRentalService.Contracts.ICarRentalService"
                  binding="basicHttpBinding">
        </endpoint>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="CarRentalServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

This sample config enables the publishing of the metadata information about your service by using the ServiceMetadataBehavior. This allows a client to make a request and get a set of information that describes your service in a standard format based on a WSDL (Web Services Description Language) standard specification or a WS-Metadata Exchange. Alternatively you could also use the programmatic approach to set the behaviors, as in Listing 3-3.

using Wrox.CarRentalService.Implementations.Europe;
using Wrox.CarRentalService.Contracts;
...

ServiceHost host = new ServiceHost(typeof(CarRentalService));

ServiceMetadataBehavior serviceMetadata =
host.Description.Behaviors.Find<ServiceMetadataBehavior>();
if (serviceMetadata == null)
{
    serviceMetadata = new ServiceMetadataBehavior();
    host.Description.Behaviors.Add(serviceMetadata);
}
serviceMetadata.HttpGetEnabled = true;

BasicHttpBinding binding = new BasicHttpBinding();
host.AddServiceEndpoint(typeof(ICarRentalService),
                        binding,
                        "http://localhost:8080/CarRentalService");

This code checks whether the current ServiceHost instance already has an instance of the ServiceMetadataBehavior. It creates a new one if it does not exist and then sets to true the HttpGetEnabled property, as in the configuration file. Only one instance of the same ServiceBehavior type can exist at the same time for each ServiceDescription.

Using the OperationBehavior attribute you are able to control class methods, which allow you to be more specific with certain areas of your service. The things you are able to control at this level are Transactional, Caller Identity, and Object recycling.

The OperationBehaviorAttribute allows managing settings that are strictly related with the service operations. You can simply apply the attribute on the operation you want to manage and then set the appropriate properties to obtain the desired behavior, based on the specific needs. See Listing 3-4.

using System;
using Wrox.CarRentalService.Contracts;

namespace Wrox.CarRentalService.Implementations.Europe
{
    public class CarRentalService : ICarRentalService
    {
        [OperationBehavior(
            AutoDisposeParameters = true,
            Impersonation = ImpersonationOption.NotAllowed,
            ReleaseInstanceMode = ReleaseInstanceMode.None,
            TransactionAutoComplete = true,
            TransactionScopeRequired = false)]
        double CalculatePrice(DateTime pickupDate, DateTime returnDate,
   string pickupLocation, string vehiclePreference)
        {
            // method code here
        }
    }
}

In this sample code, all the properties of the OperationBehaviorAttribute are set with the default values.

Although the service behavior is only usable on the service side, the endpoint behaviors could be used both in services and client side. Some things, such as client credential usage or serializer settings, can be managed by applying the specific behavior to the endpoint. WCF provides a predefined set of behaviors, each of which implements the IEndpointBehavior interface:

You are able to set the various endpoint behaviors by using the config file, the programmatic approach, or a combination. Unlike ServiceBehaviorAttribute, an Endpoint Behavior can be used on both the client and the service. Another big difference, on the service side, is that the endpoint behavior settings are valid only at endpoint level, while the service behavior settings are valid at service level. By the way, some special implementation may allow only client usage, as in the ClientCredential behavior.

By using the config file, you can specify and configure the endpoint behaviors. For example, on the client side, if you want to indicate the credentials that a client must use when calling the relative endpoint, you can use the ClientCredential behavior. See Listing 3-5.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <client>
      <endpoint address="http://localhost:8080/CarRentalService"
                binding="basicHttpBinding"
                bindingConfiguration="carRentalServiceBinding"
                contract="Wrox.CarRentalService.Implementations.Europe.ICarRentalService"
                behaviorConfiguration="carRentalEndpointBehavior">
        <identity>
          <dns value="service_cert"/>
        </identity>
      </endpoint>
    </client>
    <bindings>
      <basicHttpBinding>
        <binding name="carRentalServiceBinding">
          <security mode="Message">
            <message clientCredentialType="Certificate"/>
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <endpointBehaviors>
        <behavior name="carRentalEndpointBehavior">
          <clientCredentials>
            <clientCertificate findValue="CN=client_cert"
              storeLocation="CurrentUser"
              storeName="My"
              x509FindType="FindBySubjectDistinguishedName"/>
            <serviceCertificate>
              <authentication certificateValidationMode="None"/>
              <defaultCertificate findValue="CN=service_cert"

storeLocation="CurrentUser"
              storeName="My"
              x509FindType="FindBySubjectDistinguishedName"/>
            </serviceCertificate>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

If the config file is not the right solution, it is also possible to set the behavior programmatically on the client side. See Listing 3-6.

CarRentalServiceClient client = new CarRentalServiceClient();

try
{
    client.ClientCredentials.ClientCertificate.SetCertificate(
        StoreLocation.CurrentUser,
        StoreName.My,
        X509FindType.FindBySubjectDistinguishedName,
        "CN=client_cert");

    // other code

    client.Close();
}
catch (Exception ex)
{
    client.Abort();
    throw;
}

The code is different if you want to set an endpoint behavior on the server side (see Listing 3-7). As seen for service behavior, if you don't use the config file, the ServiceHost class helps us.

using Wrox.CarRentalService.Implementations.Europe;
...

ServiceHost host = new ServiceHost(typeof(CarRentalService));

try
{
    BasicHttpBinding binding = new BasicHttpBinding();
    ServiceEndpoint serviceEndpoint =
        host.AddServiceEndpoint(typeof(ICarRentalService),

binding,
        "http://localhost:8080/CarRentalService");

    ServiceCredentials credentials = new ServiceCredentials();
    credentials.ServiceCertificate.SetCertificate(
        StoreLocation.CurrentUser,
        StoreName.My,
        X509FindType.FindBySubjectDistinguishedName,
        "CN=service_cert");

    host.Open();

    // other code here ...

    host.Close();
}
catch (Exception)
{
    host.Abort();
}

The ClientCredentials behavior is not usable on the service side. In this sample code you see how to set the service certificate by using the ServiceCredentials behavior. Security settings and the other WCF security topics are addressed Chapters 7, 8, and 9.

The IContractBehavior interface can be implemented to extend or modify any aspect of your contracts. This is applied throughout the use of your contract. This interface has four methods which you can implement to modify contracts. You cannot apply contract behaviors in configuration so you must do it in code or by attributes. The four methods are shown here:

As for the IEndpointBehavior, the IContractBehavior can be applied both on client and service side to the contract interface. But otherwise, an IContractBehavior implementation cannot be added at runtime with the configuration file. It can be added only at design time by using attributes or programmatically.

There is only one predefined IContractBehavior implementation: the DeliveryRequirementsAttribute. This behavior acts as a validator versus a feature that is loaded at runtime from a configuration file. See Listing 3-8.

using System;

namespace Wrox.CarRentalService.Contracts
{
    [DeliveryRequirements(
    QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.NotAllowed,
    RequireOrderedDelivery = true)]
    public class ICarRentalService
    {
        // service operations
    }
}

The DeliveryRequirements, in this example, indicates that this contract does not allow the queued contracts but requires the message ordered delivery. You can also set the behavior programmatically (see Listing 3-9).

DeliveryRequirementsAttribute deliveryRequirements =
    new DeliveryRequirementsAttribute();
deliveryRequirements.RequireOrderedDelivery = true;
deliveryRequirements.QueuedDeliveryRequirements =
    QueuedDeliveryRequirementsMode.NotAllowed;

CarRentalServiceClient client = new CarRentalServiceClient();
client.Endpoint.Contract.Behaviors.Add(deliveryRequirements);

On the server side, instead, you can do it by using the ServiceHost, as shown in Listing 3-10.

using Wrox.CarRentalService.Implementations.Europe;
...

ServiceHost host = new ServiceHost(typeof(CarRentalService));

WSHttpBinding binding = new WSHttpBinding();
binding.ReliableSession.Enabled = true;
binding.ReliableSession.Ordered = true;

ServiceEndpoint serviceEndpoint =
    host.AddServiceEndpoint(typeof(ICarRentalService),
    binding,
    "http://localhost:8080/CarRentalService");

DeliveryRequirementsAttribute deliveryRequirements = new
DeliveryRequirementsAttribute();
deliveryRequirements.RequireOrderedDelivery = true;

deliveryRequirements.QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.NotAllowed;
serviceEndpoint.Contract.Behaviors.Add(deliveryRequirements);

host.Open();

In a scenario with a lot of heterogeneous clients that should have access to your service, the use of interoperable protocols is a prerequisite that must be respected. WCF provides the BasicHttpBinding and the WSHttpBinding as two kinds of bindings that use Http (HyperText Transfer Protocol) as transport protocol. These are the most interoperable bindings that are useable.

The BasicHttpBinding provides a high level of interoperability between WCF and the other framework for building services such as ASP.NET ASMX. In terms of standards, it is the implementation of the WS-I Basic Profile 1.1 specification. It supports SOAP 1.1 as a messaging protocol. The security is based on the underlying transport protocol (Http) for authentication and encryption, or on WS-Security 1.0 for message security. Because the usage of BasicHttpBinding is useful only for backward interoperability with ASP.NET ASMX, because the ASMX ASP.NET doesn't support WS-Security, and the entire payload is sent in plain text, there aren't many reasons to use it.

Though it offers a great level of interoperability, there are many scenarios where it is unusable. The WSHttpBinding, as the name suggests, allows you to use various WS-* specifications such as WS-Security 1.1, WS-Reliable Messaging (for reliable and ordered message delivery), WS-Atomic Transaction, WS-Trust, and so on. This allows you to create a great and robust service infrastructure.

Obviously, using all these specifications could generate a lot of message exchanges between the client and the services. Definitively, the support of standards make WSHttpBinding more secure and reliable than BasicHttpBinding. Finally, if compatibility is not required, WSHttpBinding is the choice.

NetTcpBinding allows using the TCP protocol with the message binary encoding. By default, all the binding settings are turned off. If you want to use the security, you have to set it. If you want to use the reliable and ordered delivery with WS-ReliableMessaging or if you want to make atomic your communication, you have to enable it.

NetTcpBinding is a faster and more reliable protocol, compared with the Http protocol bindings. However, it is only usable when communication is WCF-to-WCF. This scenario represents the best applicable solution.

BasicHttpBinding, WSHttpBinding, and NetTcpBinding are solutions for connected scenarios. Sometimes you want or have the need to decouple the service provider and consumer. This usually happens if the service processes the message at a different time than the client. The client, in turn, doesn't know the exact endpoint of the services that consume and process the message.

NetMsmqBinding allows using a MSMQ to enqueue and dequeue messages. A typical scenario uses a service to receive messages from clients, enqueue the messages, then dequeue the message and process it at the backend. This allows decoupling the client and service, while the queue is the duty free zone where messages are exchanged.

In the .NET Framework you can find another binding that uses MSMQ as a message transport protocol: the MsmqIntegrationBinding. This binding differs from the NetMsmqBinding because it allows communication with the existing applications that use the System.Messaging or COM API. You cannot use NetMsmqBinding to read messages written with MsmqIntegrationBinding or vice versa because of their totally different message formatting.

WCF provides a special set of context management–enabled bindings for a range of different standard bindings. Context-enabled bindings allow you to send extra parameters to the service to exchange context by using the HttpCookies or the SOAP Header. These bindings are inherited from their main binding, and are utilized in the same way as that binding.

The following context bindings are provided for you by WCF:

These bindings allow the implementation of durable services. A WCF durable service is a service in which the state is maintained during the different calls. The following SOAP message demonstrates the usage of a SOAP Header to transfer the context between client and services. See Listing 3-11.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
        <a:Action s:mustUnderstand="1">
            http://tempuri.org/IService1/GetData
        </a:Action>

<a:MessageID>
            urn:uuid:32186d9f-573f-4252-989f-ad94a469271b
        </a:MessageID>
        <a:ReplyTo>
            <a:Address>
                http://www.w3.org/2005/08/addressing/anonymous
            </a:Address>
        </a:ReplyTo>
        <Context xmlns="http://schemas.microsoft.com/ws/2006/05/context">
            <Property name="instanceId">
                1507fdf6-a27b-40f2-b339-f331baa937f1
            </Property>
        </Context>
        <a:To s:mustUnderstand="1">http://fabio-nb:10101/IService</a:To>
    </s:Header>
    <s:Body>
        <GetData xmlns="http://tempuri.org/">
            <value>1</value>
        </GetData>
    </s:Body>
</s:Envelope>

The Context SOAP Header has a child element named Context that maintains the service instance ID in an element property. This is used on server side to retrieve the instance and resume the persisted durable service.

All these built-in bindings are built on standards that work for specific scenarios, but will also work if you choose the wrong or less-efficient one. So how do you choose which one is right for your situation?

The most obvious decision is if you need to interact with non-WCF applications. If your service is to communicate with WCF clients, then you can use one of the bindings prefixed with "net." Remember you can define several endpoints for the same service which would use different bindings. This allows you to take advantage of performance optimizations for WCF clients, but still provide support for ASMX services and WS-* standards. These provide further security and other features which many clients take advantage of.

For example, if you want to establish a WCF-to-WCF communication, choosing a NetTcpBinding with a binary encoding makes the communication four or five time faster than a BasicHttpBinding with text encoding.

These WCF-provided bindings should cover most cases that you need: however, if you need to change or create an entirely new binding, WCF allows you do this very simply. This will be discussed later in this chapter.

You don't have to explicitly set your address in each endpoint. You can set a base address in your configuration, and then use a relative address inside each of your endpoints. This allows you to have multiple endpoints which all use the same base address, meaning that if you change the URL of the service location, you can do it in one place instead of having to do it in multiple places for each endpoint. This might not sound like a big issue when you have only one or two endpoints, but if you have a whole library of endpoints it quickly becomes a chore. This also leaves you less prone to spelling mistakes of each address and allows for more reuse.

Listing 3-14 appends the relative address set inside the endpoint with the base address. So essentially it is the same as the previous configuration.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="HelloWorldService" >
        <endpoint
          address="HelloWorldService"

binding="wsHttpBinding"
          contract="IMyService" />
<host>
      <baseAddresses>
            <add baseAddress="http://localhost:8080/" />
      </baseAddresses>
</host>
      </service>
    </services>
    <bindings>
      <wsHttpBinding>
      </wsHttpBinding>
   </bindings>
  </system.serviceModel>
</configuration>

You can have multiple base addresses for each service, but only one for each protocol. WCF will then automatically map the correct address based on the binding configuration of the endpoint.

Listing 3-15 defines two endpoints, one which has no address using the basicHttpBinding. This means it will be mapped to the base address path for the base address defined with Http. And the second, which has TCP as the address using the netTcpBinding, has the full address as net.tcp://localhost:9090/tcp.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="HelloWorldService" >

        <endpoint
          address=""
          binding="basicHttpBinding"
          contract="IMyService" />
        <endpoint
          address="tcp"
          binding="netTcpBinding"
          contract="IMyService" />
<host>
      <baseAddresses>
            <add baseAddress="http://localhost:8080/" />
            <add baseAddress="net.tcp://localhost:9090/" />
      </baseAddresses>
</host>
      </service>
    </services>
  </system.serviceModel>
</configuration>

A new group of features to WCF 4.0 tries to simplify configurations by defining default configurations for several aspects of WCF. As a whole this allows for much smaller (or nonexistent) configuration files. The WCF configuration schema is very large and difficult to configure features. Mistakes also happen and services are deployed with missing configuration information. (This is especially useful for development purposes.) Although it may not be apparent with very simple services, when you have large-scale enterprise services with many endpoints and many different configuration settings for each, you can see where editing these settings becomes a difficult prospect for developers and administrators alike. (This is especially true for administrators who won't necessarily know the implications of changing these configuration files, but are responsible for them on production servers.)

The following changes are new to WCF 4.0 and will generate runtime exceptions if using these configurations in pre-4.0. However, when you upgrade your WCF 3/3.5 app to WCF 4.0, it still works with the WCF 3.x configuration. But you are able to re-factor your configuration files to take advantage of this increased simplicity if you wish.

<system.serviceModel>
    <protocolMapping>
        <add scheme="http" binding="basicHttpBinding"/>
        <add scheme="net.tcp" binding="netTcpBinding"/>
        <add scheme="net.pipe" binding="netNamedPipeBinding"/>
        <add scheme="net.msmq" binding="netMsmqBinding"/>
    </protocolMapping>
</system.serviceModel>

<system.serviceModel>
  <protocolMapping>
    <add scheme="http" binding="wsHttpBinding"/>
  </protocolMapping>
</system.serviceModel>

<system.serviceModel>
  <protocolMapping>
    <add scheme="https" binding="wsHttpBinding"/>
  </protocolMapping>
</system.serviceModel>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="MyService"
               behaviorConfiguration="MyServiceBehavior">

        <endpoint address="http://localhost/MyService/"
                  binding="wsHttpBinding"
                  contract="IMyService" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceMetadata httpGetEnabled="True" />
       </behavior>
     </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <system.serviceModel>
    <behaviors>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled ="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
 </system.serviceModel>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="MyService1">
        <endpoint kind="mexEndpoint">
      </service>
    </services>
  </system.serviceModel>
<configuration>

You will often have clients connecting to your service from many different types of systems and applications, i.e., WCF, ASMX, and JSON. You can specify multiple endpoints with different bindings allowing different clients to connect to your service using whichever transport they support.

Listing 3-22 adds two endpoints with different bindings: wsHttpBinding and basicHttpBinding.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="HelloWorldService" >
        <endpoint
          address="http://localhost:8080/HelloWorldService"
          binding="wsHttpBinding"
          contract="IMyService" />

<endpoint
          address="http://localhost:8080/HelloWorldService/basic"
          binding="basicHttpBinding"
          contract="IMyService" />
      </service>
    </services>
    <bindings>
      <wsHttpBinding>
      </wsHttpBinding>
   </bindings>
  </system.serviceModel>
</configuration>

Notice the two differences in declaring these endpoints: the first is obviously the binding, which is exactly as it should be. Also, the addresses are different. Remember that addresses must be unique. You have to create a new address for the basicHttpBinding to use. If you add a netTcpBinding, it would have a unique address, as the protocol scheme at the beginning would no longer be http:// and would be replaced by net.tcp://. Also, if you are using a different contract, your endpoint can have the same address and also the same binding. If the address is not unique, and the contracts are the same, then an exception will be thrown.

The WCF-provided bindings all have default properties which you are able to modify to suit your own scenarios. Each binding has similar properties but differ from binding to binding.

For this example, the basicHttpBinding is used, which is the binding you would use to communicate with ASMX web services. Table 3-4 shows the basicHttpBinding properties, a brief description, and the default value for each of them.

You modify the MessageEncoding property from its default Text to Mtom. Mtom (Message Transmission Optimization Mechanism) allows for smaller messages when sending large amounts of data by sending SOAP messages as raw bytes. You should see a big performance difference in changing this.

To change this property, first create a new config section inside your basicHttpBinding section. This includes a name to reference, and then set the property (or multiple properties) that you want to change. You can then reference that in your endpoint configuration by the name created (in the following example, the name is Encode). You do this by using the bindingConfiguration property in the endpoint configuration. You can then re-use this configuration for other endpoints in your configuration, or maybe more importantly, choose to not use this configuration for other endpoints. This gives you complete flexibility with the configuration, but minimizes duplicating the configuration of properties by allowing this re-use. Listing 3-23 shows how you can change the default property values in app.config.

<system.serviceModel>
    <services>
      <service name="MyService1">
        <endpoint address="http://localhost:8080/MyService1"
                  contract="Service1"
                  binding="basicHttpBinding"
                  bindingConfiguration="Encode">
        </endpoint>
      </service>
    </services>
    <bindings>
      <basicHttpBinding>
        <binding name="Encode" messageEncoding="Mtom"></binding>
      </basicHttpBinding>
    </bindings>
  </system.serviceModel>

The same can be done programmatically when you create the new basicHttpBinding object. As shown in Listing 3-24, you can then change the properties of that object just as any other object's property. This also gives you the beauty of Visual Studio's Intellisense so you can see all the options for the binding you are configuring.

ServiceHost host = new ServiceHost(typeof(MyService1.Service1));

BasicHttpBinding binding = new BasicHttpBinding();
binding.MessageEncoding = WSMessageEncoding.Mtom;

host.AddServiceEndpoint(
    typeof(MyService1.IService1),
    binding,
    "http://localhost:8080/MyService1");

When editing the App.config, you need to explicitly set the bindingConfiguration to use, but within the code you just modified the actual instance of the BasicHttpBinding class that you created.

There are times when you must create your own binding; a couple of examples would be custom security and additional transport protocols. This can be done within your configuration or in code.

To create your own custom binding, build up a collection of binding elements. You need to be familiar with the binding elements that are defined within WCF. This allows you to define the specifics of your custom binding.

<customBinding>
  <binding name="binHttp">
      <binaryMessageEncoder />
      <httpTransport />
  </binding>
</customBinding>

using Wrox.CarRentalService.Implementations.Europe;
...

CustomBinding binding = new CustomBinding();
binding.Elements.Add(new BinaryMessageEncodingBindingElement());
binding.Elements.Add(new HttpTransportBindingElement());

ServiceHost host = new ServiceHost(typeof(CarRentalService));

ServiceEndpoint serviceEndpoint =
host.AddServiceEndpoint(typeof(ICarRentalService),
                        binding,
                        "http://localhost:8080/CarRentalService");

host.Open();

Sometimes you may need to create a custom binding and reuse it in various solutions. Because each binding inherits from the base abstract class System.ServiceModel.Channels.Binding, you can simply create your own binding class and implement the CreateBindingElements to achieve this requirement. Listing 3-27 shows how you can extend the Binding base class to create and reuse your own implementation.

public class NetTcpTextBinding : Binding
{
    private TcpTransportBindingElement transport;
    private TextMessageEncodingBindingElement encoding;

    public NetTcpTextBinding()
        : base()
    {
        this.Initialize();
    }

    public override BindingElementCollection CreateBindingElements()
    {
        BindingElementCollection elements = new BindingElementCollection();
        elements.Add(this.encoding);
        elements.Add(this.transport);
        return elements;
    }

    public override string Scheme
    {
        get { return this.transport.Scheme; }
    }

    private void Initialize()
    {
        this.transport = new TcpTransportBindingElement();
        this.encoding = new TextMessageEncodingBindingElement();
    }
}

In the sample NetTcpTextBinding shown in Listing 3-28, a custom binding is set that encodes messages using text encoding protocol on a TCP transport. It is a very simple implementation that demonstrates how you can customize WCF to achieve every need.

As with every other binding, you can use it with ServiceHost or ChannelFactory to configure the service endpoint.

NetTcpTextBinding binding = new NetTcpTextBinding();

ServiceHost host = new ServiceHost(typeof(Service1));
host.AddServiceEndpoint(typeof(IService1),
                        binding,
                        "net.tcp://localhost:10101/IService");

host.Open();

One step over allows developers to use the custom binding via configuration file. As shown in Listing 3-29, you must extend the BindingCollectionElement abstract base class and then implement the required methods.

using System.Configuration;
...

public class NetTcpTextBindingCollectionElement : BindingCollectionElement
{
    public override Type BindingType
    {
        get { return typeof(NetTcpTextBinding); }
    }

    public override ReadOnlyCollection<IBindingConfigurationElement>
    ConfiguredBindings
    {
        get
        {
            return new ReadOnlyCollection<IBindingConfigurationElement>(
                        new List<IBindingConfigurationElement>());
        }
    }

    public override bool ContainsKey(string name)
    {
        throw new NotImplementedException();
    }

    protected override Binding GetDefault()
    {
        return new NetTcpTextBinding();
    }

    protected override bool TryAdd(
        string name, Binding binding, Configuration config)
    {
        throw new NotImplementedException();
    }
}

The property that you must implement is BindingType. It allows defining the binding type target of the current configuration. The other important property is the ConfiguredBindings that retrieves all the binding configuration elements.

The code shown in Listing 3-29 is a really simple implementation that could be extended, for example, with the definition of custom binding elements. You should implement the IBindingConfigurationElement interface to permit a great level of customization at runtime.

Now, if you want to use the NetTcpTextBinding in the configuration file, you have to configure the NetTcpTextBindingCollectionElement by using the binding extensions (see Listing 3-30). Indeed, if you want to use your custom binding implementation, you have to define it.

<system.serviceModel>
  <services>
    <service name="WcfServiceLibrary2.Service1">
      <endpoint address="net.tcp://localhost:10101/IService"
                binding="netTcpTextBinding"
                contract="WcfServiceLibrary2.IService1">

      </endpoint>
    </service>
  </services>
  <extensions>
    <bindingExtensions>
      <add name="netTcpTextBinding"
           type="ConsoleApplication1.NetTcpTextBindingCollectionElement,
           ConsoleApplication1,
           Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </bindingExtensions>
  </extensions>
</system.serviceModel>

The value of the name attribute defined in the binding extensions section corresponds to the name usable in the service element. Finally, you can use the binding in the endpoint element of the service section.

Not all context bindings support the duplex durable correlation services. In effect, the BasicHttpContextBinding doesn't support the ClientCallbackAddress property — it instead supports both in the WSHttpContextBinding and NetTcpContextBinding.

To enable the correlation, you have to set ClientCallbackAddress in your context binding configuration, as shown in Listing 3-31.

<system.serviceModel>
    <client>
      <endpoint address="http://localhost/BackEndDurableDuplex/WorkflowService2.xamlx"
        binding="wsHttpContextBinding" bindingConfiguration="contextCorrelationBinding"
        contract="IWorkflowService2" name="WSHttpContextBinding_IWorkflowService2">
      </endpoint>
    </client>
    <services>
      <service name="WorkflowService1">
        <endpoint address=""
                  binding="wsHttpContextBinding"
                  contract="IWorkflowService"
                  bindingConfiguration="contextCorrelationBinding">
        </endpoint>
        <endpoint address=""
                  binding="wsHttpContextBinding"
                  contract="IWorkflowServiceCallback"
                  bindingConfiguration="contextCorrelationBinding">
        </endpoint>
      </service>
    </services>

    <bindings>
      <wsHttpContextBinding>

<binding name="contextCorrelationBinding" clientCallbackAddress="http://localhost/DurableDuplex/WorkflowService1.xamlx" />
      </wsHttpContextBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceDebug includeExceptionDetailInFaults="true"/>
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>

  </system.serviceModel>

In the previous configuration section, two endpoints were defined: one for the service and the other for the callback calls. Both endpoints use the WSHttpContextBinding and the value of the clientCallbackAddress property in the relative section named contextCorrelationBinding. This is the only setting you need to create the correlation.

It is also possible to create your custom binding and define the context binding element, as shown in Listing 3-32.

<bindings>
    <customBinding>
        <binding name="netMsmqContextBinding">
            <context clientCallbackAddress="net.msmq://localhost/private/
WorkflowService1.xamlx"/>
            <msmqTransport />
        </binding>
    </customBinding>
</bindings>

The context bindings and the correlation system is an implementation of the Microsoft Context Exchange Protocol (http://msdn.microsoft.com/en-us/library/bb924468.aspx).

With Silverlight 4 you are able to handle a duplex connection between a Silverlight client and a WCF Service by also using a net.tcp transport protocol.

Compared with the PollingDuplexHttpBinding, the net.tcp in Silverlight 4 dramatically affects the performance, and it should be the preferred solution only when you are in an intranet environment. Indeed, the net.tcp protocol is subject to some restrictions. You can use only ports 4502–4534, and in intranet environments you can control the firewall settings to meet the requirements. Finally, the transport security settings (SSL) with the net.tcp transport protocol in Silverlight are not supported. If you don't need to use transport security, then this limit is not as important.

The net.tcp protocol in Silverlight is a great improvement and a good alternative to the Http protocol, although it has a limited usage due to the above-mentioned constraints.