WCF 4.0 Features

After being unavailable for such a long time I am back with The Windows Communication Foundation (WCF) 4.0 Features. Let’s Begin with enlisting few new features of WCF 4.0

•         Simplified Configuration
•         Standard End Points
•         Fileless Activation
•         Protocol bridging and Fault tolerance
•         Dynamic Service and End Point discovery
•         Routing Services
•         Improved REST Support

I will discuss details of each feature in subsequent articles. 

 

Simplified Configuration …

The programming model offered by WCF in 3.x simplifies writing service logic for a variety of different communication scenarios, however it also increases the complexity on the configuration side of things because it provides so many different underlying communications options that you’re forced to understand before you can get started...

WCF 4 comes with a new “default configuration” model that completely removes the need for any WCF configuration. If you don’t provide any WCF configuration for a particular service, the WCF 4 run time automatically configures your service with some standard endpoints and default binding/behavior configurations. This makes it much easier to get a WCF service up and running, especially for those who aren’t familiar with the various WCF configuration options and are happy to accept the defaults, at least to get started. Let’s see how this works –

   1) Service Contract :-   [ServiceContract]

                           public interface IService1

                           {

                            [OperationContract]

                             string GetData(int value);
                           }

              

S   2) Service :-   public string GetData(int value)

                           {

            return string.Format("You entered: {0}", value);                                 }

    3) Now add ConsoleApplication1 in the Solution. 

        ServiceHost serviceHost = new ServiceHost(
        typeof(WcfService1.Service1), new Uri("http://localhost:8080/Service1"));

        
        serviceHost.Open();

        System.Console.WriteLine("The Service has started");

        foreach (ServiceEndpoint se in  serviceHost.Description.Endpoints)

        {

        System.Console.WriteLine("Address:{0}, Binding:{1}, Contract:{2}", se.Address, se.Binding.Name, se.Contract.Name);

        }

    System.Console.WriteLine("Please, press any key to finish");

    System.Console.ReadLine();

    serviceHost.Close();

   4) Add following in App.config.

<configuration>

  <system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior>

          <serviceMetadata httpGetEnabled ="true"/>

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <protocolMapping>

      <add binding="wsHttpBinding" scheme ="http"/>

    </protocolMapping>

  </system.serviceModel>

</configuration>

Output Window

When you run this program, you will see that the IService1 service contract can be accessed from the http://localhost:808/Service1 using WSHttpBinding as shown in image…

Standard endpoints in WCF 4…

Related to default endpoints is another new WCF 4 feature known as “standard endpoints”.  We can think of a standard endpoint as a common preconfigured endpoint definition built into the WCF 4 framework that we can simply use. Enlisting few of them:-

•         mexEndpoint
•         dynamicEndpoint
•         discoveryEndpoint
•         udpDiscoveryEndpoint
•         webHttpEndpoint

Although the standard endpoints shield us from most of the configuration details and we can use them as follows 
  

<system.serviceModel>
   <services>
      <service name="GreetingService">
        <endpoint binding="basicHttpBinding" contract="IHello"/>
        <endpoint kind="mexEndpoint" address="mex“/>
      </service>
   </services>
</system.serviceModel>

Fileless Activation of WCF Service …

Every WCF service needs to have a host process. It can be a windows service, IIS or any other .NET program. This host process will create an instance of the System.ServiceModel.ServiceHost class or any custom class deriving from ServiceModel.ServiceHostBase.

This host class will manage the service configurations, behaviors, channels and make it accessible to the outside world. When a service is hosted in IIS it behaves a little bit differently. Here we need to create a physical file with .svc extension in the virtual directory of the web server. This file actually points to the service class implementing the Service Contract and System.ServiceModel.Activation.ServiceHostFactory or a derived class ServiceModel.Activation.ServiceHostFactoryBase. 

When IIS receives a request with that .svc file in URI the corresponding ServiceHostFactory creates an instance of the Service Host. The mark-up contained in a .svc file is shown below:-

<%@ ServiceHost Language="C#" Debug="true" Factory="System.ServiceModel.Activation.ServiceHostFactory" Service="TestService" CodeBehind="TestService.svc.cs" %>

In WCF 4.0 we can create and deploy services in IIS without a physical file in the virtual directory. This can be done using the serviceActivations configuration in the system.serviceModel configuration in web.config as shown below:-

<serviceHostingEnvironment > 

  <ServiceActivations>

    <add factory="System.ServiceModel.Activation.ServiceHostFactory"   

     relativeAddress="/Payment" service="PaymentService"/>

  </ServiceActivations >

</serviceHostingEnvironment>

There is no physical file named Payment.svc but still we’ll able to access the service at http://localhost/Payment.svc , This is the new Fileless Activation feature introduced in .NET 4.0.

Protocol bridging and Fault tolerance …

Protocol bridging is basically used for transportation. Client sends message to Routing Service via HTTP .Routing Service will send the message to Back end WCF Service via TCP/IP. Here we are using Protocol bridging between HTTP AND TCP/IP.

 

The Routing Service also provides a built-in mechanism to deal with run time communication errors and to support a basic level of fault tolerance. When defining your filter table, you can define different lists of alternate endpoints that will be used by the Routing Service if communicating with the initial target endpoint results in an error. This essentially makes it possible to have lists of “backup” endpoints. 

I’ll try to explain these more when discussing Routing Service. In Next article we will discus more about routing service, Rest Improvements & End Point discovery etc.... 

Courtesy: Random Web Images, MSDN, Microsoft .NET 4.0 WCF Book, Several online resources