Wednesday, 19 October 2011

Introdution to WCF 4.0

This article explains about the new features introduced in WCF 4.0.
.Net framework comes with new features and improved areas of WCF. It was mainly focused on simplifying the developer experience, enabling more communication scenario and providing rich integration with WWF.
The following items specifies the new features of WCF 4.0
Simplified configuration
This new feature shows simplification of WCF configuration section by providing default endpoint, binding and behavior configuration. It is not mandatory to provide endpoint while hosting service. Service will automatically create new endpoint if it does find any endpoint while hosting service. These changes make it possible to host configuration-free services.
Discovery service
There are certain scenario in which endpoint address of the service will be keep on changing. In that kind of scenario, client who consume this service also need to change the endpoint address dynamically to identify the service. This can be achieved using WS-Discovery protocol.
Routing service
This new feature introduces routing service between client and actual business service. This intermediated service Act as broker or gateways to the actual business services and provides features for content based routing, protocol bridging and error handling
REST Service
There are few features helps while developing RESTful service.
  • Automatic help page that describes REST services to consumer
  • Support for declarative HTTP catching
Workflow service
  • Improves development experience
  • Entire service definition can be define in XAML
  • Hosting workflow service can be done from .xamlx file, without using .svc file
  • Introduce new “Context” bindings like BasicHttpContextBinding, WSHttpContextBinding, or NetTcpContextBinding
  • In .Net4.0, WorkflowServiceHost class for hosting workflow services was redesigned and it is available in System.ServiceModel.Activities assembly. In .Net3.5, WorkflowServiceHost class is available in System.WorkflowServices assembly
  • New messaging activities SendReply and ReceiveReply are added in .Net4.0

Custom message header

This article explains about customizing the wcf message flowing between service and client.
There are certain scenario in which you to pass some information from client to service, but not as parameter in operation contracts. Example, logging system at the service we need to log user or machine information, which made request to the service. In this kind of scenario we should not pass user or machine information as parameter in operation contract. Instead we can pass the information through message flowing between client and service vice versa. The information we need to send can be appended with message header and it can be received at the server side.
Let as create sample service and client application, in which client will send “User name” information through request message and service will respond with confirmation message.
I have created Math service with Add and Subtract functionality. Client consuming this service will send his user name information as string with requested message. Once request reached the service, it will read the information from the message header and display using console window. When service responding to the client, along with operation result, it will also send confirmation message to client through message header.
Step 1: Create IMathService interface decorated with Service and Operational contract attribute
IMathService.vb
<ServiceContract()> _
Public Interface IMathService
    <OperationContract()> _
    Function Add(ByVal a As Integer, ByVal b As Integer) As Integer
    <OperationContract()> _
    Function Subtract(ByVal a As Integer, ByVal b As Integer) As Integer
End Interface
Step 2:In this class, we have implemented Add and Subtract functionality.
PrintRequestedUserID() method will read the “UserID” message header from incoming message using OperationContext. This User information is displayed in console window.
SendResponseWithMessage() method will send a confirmation message to the client as Message header through Operation context.
MathService.vb
Public Class MathService
    Implements IMathService

    Public Function Add(ByVal a As Integer, ByVal b As Integer) As Integer 
    Implements IMathService.Add
        'This method call will retrive message send from client using MessageHeader
        PrintRequestedUserID()
        'This method call will send message to client using MessageHeader
        SendResponseWithMessage()
        Return a + b

    End Function

    Public Function Subtract(ByVal a As Integer, ByVal b As Integer) As Integer 
    Implements IMathService.Subtract
        'This method call will retrive message send from client using MessageHeader
        PrintRequestedUserID()
        'This method call will send message to client using MessageHeader
        SendResponseWithMessage()
        Return a - b
    End Function

    Private Sub PrintRequestedUserID()
        Dim userID As String = String.Empty
        'Read the message header using "Name" and "NameSpace"
        userID = OperationContext.Current.IncomingMessageHeaders
                                    .GetHeader(Of String)("UserID", "ns")
        Console.WriteLine("Requested user: " + userID)
    End Sub

    Private Sub SendResponseWithMessage()
        'Creating new message header with "Content" value assigned in constructor
        Dim mess As New MessageHeader(Of String)("This is sample message from service")
        'Assigning Name and NameSpace to the message header value at server side
        Dim header As System.ServiceModel.
                    Channels.MessageHeader = mess.GetUntypedHeader("ServiceMessage", "ns")
        'Adding message header with OperationContext 
        'which will be received at the client side
        OperationContext.Current.OutgoingMessageHeaders.Add(header)
    End Sub
End Class
Step 3: Hosting the MathService using console application
MyServiceHost.vb
       Module MyServiceHost

    Sub Main()
        'Hosting the Math service using console application
        Dim host As New ServiceHost(GetType(MyService.MathService))
        host.Open()
        Console.WriteLine("Service is running... Press  to exit.")
        Console.ReadLine()
    End Sub

End Module

Web.Config
      <system.serviceModel>
    <services><service name="MyService.MathService" 
    behaviorConfiguration="MyServiceBehavior">
        <endpoint address ="MathService" binding="basicHttpBinding" 
        contract="MyService.IMathService"/>
        <endpoint  address="mex" binding="mexHttpBinding" 
        contract="IMetadataExchange"/>
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8090/MyService"/>
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors >
        <behavior name ="MyServiceBehavior">
          <serviceMetadata httpGetEnabled ="true"/>
            <serviceDebug includeExceptionDetailInFaults ="True"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Step 4: Created console client application which add “UserID” as message header to service using Operation context before calling Add() functionality. Once the response is received from the service, it is trying to read the confirmation message from service using Operation context.
Sub Main()
        'Creating proxy class for service
        Dim proxy As IMathService = Nothing
        proxy = ChannelFactory(Of IMathService).CreateChannel(New BasicHttpBinding(), 
                    New EndpointAddress("http://localhost:8090/MyService/MathService"))

        'Lifetime of OperationContextScope defines the scope for OperationContext.
        Dim scope As OperationContextScope = Nothing
        scope = New OperationContextScope(proxy)
       
        'Creating new message header with "Content" value assigned in constructor
        Dim mess As New MessageHeader(Of String)
                         (System.Security.Principal.WindowsIdentity.GetCurrent().Name)
        'Assigning Name and NameSpace to the message header value at client side
        Dim header As System.ServiceModel.Channels.MessageHeader 
                                    = mess.GetUntypedHeader("UserID", "ns")
        'Adding message header with OperationContext 
        'which will be received at the server side
        OperationContext.Current.OutgoingMessageHeaders.Add(header)

        'Making service call
        Console.WriteLine("Sum of {0},{1}={2}", 1, 2, proxy.Add(1, 2))
        'Displaying confrimation message from service
        Console.WriteLine("Response Message: " + OperationContext.Current.
                    IncomingMessageHeaders.GetHeader(Of String)("ServiceMessage", "ns"))
        Console.ReadLine()
    End Sub

End Module

<ServiceContract()> _
Public Interface IMathService
    Inherits IClientChannel

    <OperationContract()> _
    Function Add(ByVal a As Integer, ByVal b As Integer) As Integer
    <OperationContract()> _
    Function Subtract(ByVal a As Integer, ByVal b As Integer) As Integer
End Interface

Step 5: Run the MyServiceHost
Step 6: Run the MyClientApplication
Below figure shows the message flowing between service and client
Client application output
Console hosted service output screen
Conclusion:
This article explain about customizing the wcf message header

Handling Exception in Silverlight application from WCF

This article explains about handling the exception in Silverlight application from WCF. I have created the sample Silverlight application, which uses the WCF service for process the data. While testing the application I came to know that exception message thrown from WCF cannot be received at the client side(Silverlight application) even after using the FaultException. I was always getting System.ServiceModel.CommunicationException: The remote server returned an error: NotFound.
Imports System.ServiceModel.ConfigurationrviceModel.Configuration
Imports System.ServiceModel.Description
Imports System.ServiceModel.Dispatcher
Imports System.ServiceModel.Channels
Imports System.ServiceModel

    Public Class SilverlightFaultBehavior
        Inherits BehaviorExtensionElement
        Implements IEndpointBehavior


        Public Overrides ReadOnly Property BehaviorType() As System.Type
            Get
                Return GetType(SilverlightFaultBehavior)
            End Get
        End Property

        Protected Overrides Function CreateBehavior() As Object
            Return New SilverlightFaultBehavior
        End Function

        Public Sub AddBindingParameters(ByVal endpoint As ServiceEndpoint,
                                     ByVal bindingParameters As BindingParameterCollection)
                                     Implements IEndpointBehavior.AddBindingParameters

        End Sub

        Public Sub ApplyClientBehavior(ByVal endpoint As ServiceEndpoint, 
                                       ByVal clientRuntime As ClientRuntime) 
                                       Implements IEndpointBehavior.ApplyClientBehavior

        End Sub

        Public Sub ApplyDispatchBehavior(ByVal endpoint As ServiceEndpoint, 
                          ByVal endpointDispatcher As EndpointDispatcher) 
                          Implements IEndpointBehavior.ApplyDispatchBehavior
            Dim inspector As New SilverlightFaultMessageInspector()
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(inspector)
        End Sub

        Public Sub Validate(ByVal endpoint As ServiceEndpoint)
                                         Implements IEndpointBehavior.Validate

        End Sub

        Public Class SilverlightFaultMessageInspector
            Implements IDispatchMessageInspector

            Public Function AfterReceiveRequest(ByRef request As Message, 
                                     ByVal channel As IClientChannel,
                                     ByVal instanceContext As InstanceContext) As Object 
                                     Implements IDispatchMessageInspector.AfterReceiveRequest
                ' Do nothing to the incoming message. 
                Return Nothing
            End Function

            Public Sub BeforeSendReply(ByRef reply As System.ServiceModel.Channels.Message,
                                       ByVal correlationState As Object) 
                                       Implements IDispatchMessageInspector.BeforeSendReply
                If reply.IsFault Then
                    Dim [property] As New HttpResponseMessageProperty()

                    ' Here the response code is changed to 200. 
                    [property].StatusCode = System.Net.HttpStatusCode.OK
                    reply.Properties(HttpResponseMessageProperty.Name) = [property]
                End If
            End Sub
        End Class

    End Class


Note: Highlighted code shows the conversion for 500 serices to 200 series error code.
Step 2: Build the project
Step 3: Create a new WCF service with Interface and implementation class as follows
Interface
<ServiceContract()> _
Public Interface IService
    <OperationContract()> _
    Function Add(ByVal num1 As Integer, ByVal num2 As Integer) As Integer
    <OperationContract()> _
    Function Subtract(ByVal num1 As Integer, ByVal num2 As Integer) As Integer

   
End Interface

Implementation
Public Class Service
    Implements IService

    Public Sub New()
    End Sub

    Public Function Add(ByVal num1 As Integer, ByVal num2 As Integer)
                                         As Integer Implements IService.Add
        Throw New FaultException("Error thrown by user for Add operation")
        'Return num1 + num2
    End Function

    Public Function Subtract(ByVal num1 As Integer, 
                            ByVal num2 As Integer) As Integer Implements IService.Subtract
        Return num1 - num2
    End Function
End Class


< Add the Silverlight_WCF_FaultBehavior project dll as reference to WCF Service
Step 5:
Step 5: In WCF we can extend the binding and behavior by using <extention> tag. In our case also we are extending the custom endpoint behavior as shown below. In the <behaviorExtensions> tag we need specify the fully qualified name of the cutom behaviour assembly.
Modify the Web.config file as shown bellow
<system.serviceModel>
    <services>
      <service name="Service" behaviorConfiguration="ServiceBehavior">
        <!-- Service Endpoints -->
        <endpoint address="" binding="basicHttpBinding" contract="IService"
         behaviorConfiguration="SilverlightFaultBehavior">
          <!-- 
              Upon deployment, the following identity element should be removed or replaced 
              to reflect the identity under which the deployed service runs.  If removed, 
              WCF will infer an appropriate identity automatically.-->
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
          <!-- To avoid disclosing metadata information, set the value below to false and 
          remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faults for debugging purposes, set the value 
          below to true.  Set to false before deployment to avoid disclosing exception 
          information -->
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="SilverlightFaultBehavior">
          <silverlightFaults/>
        </behavior>
      </endpointBehaviors>
    </behaviorss=“BlueCode”>>
    <extensions>
      <behaviorExtensions>
        <add name="silverlightFaults" 
        type="Silverlight_WCF_FaultBehavior.SilverlightFaultBehavior, 
        Silverlight_WCF_FaultBehavior, Version=1.0.0.0, Culture=neutral, 
        PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensionss=“BlueCode”>>
  </system.serviceModel>
Step 6: Create the any sample silverlight application as “Silverlight_WCF_Exception” and add this WCF service as Service Reference.
url: http://localhost/MathService/Service.svc
Step 7: Add a button to the MainPage.xaml and call the WCF method as shown below
Private Sub Button_Click(ByVal sender As System.Object,
                             ByVal e As System.Windows.RoutedEventArgs)
        Dim proxy As New ServiceProxy.ServiceClient
        AddHandler proxy.AddCompleted, AddressOf AddOperationCompleted
        proxy.AddAsync(5, 6)
    End Sub

    Private Sub AddOperationCompleted(ByVal sender As Object, 
                                    ByVal e As ServiceProxy.AddCompletedEventArgs)
        If e.Error IsNot Nothing Then
            MessageBox.Show(e.Error.Message)
        Else
            MessageBox.Show(e.Result)
        End If
    End Sub

Step 8: Output will look like this
Later I came to know that WCF throws the HTTP 500 series Fault message but Silverlight can handle only 200 series. So we need to convert the 500 series to 200 error message for Silverlight. Here is the sample application for exception handling between WCF and Silverlight.
Step 1: We can customize the Endpoint behavior of the WCF service by inheriting the Beha and implementing the IEndpointBehavior. Actual code for converting the 500 error serice to 200 serivce in BeforeSendReply method.
Create a ClassLibrary project and name it as “Silverlight_WCF_FaultBehavior” and name the class as “SilverlightFaultBehavior”. Copy and paste the follwing code inside the SilverlightFaultBehavior class.

Transaction Protocols

As a developer we no need to concern about transaction protocols and transaction manager used by WCF. WCF itself will take care of what kind of transaction protocols should be used for different situation. Basically there are three different kinds of transaction protocols used by WCF.

Transaction Propagation

In WCF, transaction can be propagated across service boundary. This enables service to participate in a client transaction and it includes multiple services in same transaction, Client itself will act as service or client.
We can specify whether or not client transaction is propagated to service by changing Binding and operational contract configuration
<bindings>
      <netTcpBinding>
        <binding transactionFlow="true"></binding>
      </netTcpBinding>
    </bindings>
Even after enabling transaction flow does not mean that the service wants to use the client’s transaction in every operation. We need to specify the “TransactionFlowAttribute” in operational contract to enable transaction flow.
[ServiceContract]
public interface IService
{

    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Allowed)]
    int Add(int a, int b);

    [OperationContract]
    int Subtract(int a, int b);
}

Note: TransactionFlow can be enabled only at the operation level not at the service level.
TransactionFlowOption Binding configuration
NotAllowed transactionFlow="true"
or
transactionFlow
="false"
Client cannot propagate its transaction to service even client has transaction
Allowed transactionFlow="true" Service will allow to flow client transaction.
It is not necessary that service to use client transaction.
Allowed transactionFlow="false" If service disallows at binding level, client also should disable at binding level else error will be occurred.
Mandatory transactionFlow="true" Both Service and client must use transaction aware binding
Mandatory transactionFlow="false" InvalidOperationException will be throw when serice binding disables at binding level.
FaultException will be thrown when client disable at its binding level.

Two-phase committed protocol

Consider the scenario where I am having single client which use single service for communication and interacting with single database. In which service starts and manage the transaction, now it will be easy for the service to manage the transaction.
Consider for example client calling multiple service or service itself calling another service, this type of system are called as Distributed Service-oriented application. Now the questions arise that which service will begin the transaction? Which service will take responsibility of committing the transaction? How would one service know what the rest of the service feels about the transaction? Service could also be deployed in different machine and site. Any network failure or machine crash also increases the complexity for managing the transaction.
In order to overcome these situations, WCF come up with distributed transaction using two way committed protocol and dedicated transaction manager.
Transaction Manager is the third party for the service that will manage the transaction using two phase committed protocol.
Let us see how Transaction manager will manage the transaction using two-phase committed protocols.

Transaction

A transaction is a collection or group of one or more units of operation executed as a whole. It provides way to logically group single piece of work and execute them as a single unit. In addition, WCF allows client applications to create transactions and to propagate transactions across service boundaries.

Recovery Challenge

Let us discuss more on challenge we will phased and how to recover from it.
  1. Consider a system maintained in consistent state, when application fail to perform particular operation, you should recover from it and place the system in the consistent state.
  2. While doing singe operation, there will be multiple atomic sub operation will happen. These operations might success or fail. We are not considering about sub operation which are failed. We mainly consider about the success operation. Because we have to recover all these state to its previous consistence state.
  3. Productivity penalty has to be payee for all effort required for handcrafting the recovery logic
  4. Performance will be decreased because you need to execute huge amount of code.

Solution

Best way to maintain system consistence and handling error-recovery challenge is to use transactions. Below figure gives idea about transaction.
  • Committed transaction: Transaction that execute successfully and transfer the system from consistence state A to B.
  • Aborted transaction: Transaction encounters an error and rollback to Consistence State A from intermediate state.
  • In-doubt transaction: Transactions fail to either in commit or abort.

Transaction Resources

Transactional programming requires working with a resource that is capable of participating in a transaction, and being able to commit or roll back the changes made during the transaction. Such resources have been around in one form or another for decades. Traditionally, you had to inform a resource that you would like to perform transactional work against it. This act is called enlisting. Some resources support auto-enlisting.

Transaction Properties

Transaction can be said as pure and successful only if meets four characteristics.
  • Atomic - When transaction completes, all the individual changes made to the resource while process must be made as to they were all one atomic, indivisible operation.
  • Consistent - transaction must leave the system in consistent state.
  • Isolated - Resources participating in the transaction should be locked and it should not be access by other third party.
  • Durable - Durable transactions must survive failures.

Streaming

Client and Service exchange message using Streaming transfer mode, receiver can start processing the message before it is completely delivered. Streamed transfers can improve the scalability of a service by eliminating the requirement for large memory buffers. If you want to transfer large message, streaming is the best method.

Supported Bindings

  • BasicHttpBinding
  • NetTcpBinding
  • NetNamedPipeBinding

Restrictions

There are some restriction, when streaming is enabled in WCF
  • Digital signatures for the message body cannot be performed
  • Encryption depends on digital signatures to verify that the data has been reconstructed correctly.
  • Reliable sessions must buffer sent messages on the client for redelivery if a message gets lost in transfer and must hold messages on the service before handing them to the service implementation to preserve message order in case messages are received out-of-sequence.
  • Streaming is not available with the Message Queuing (MSMQ) transport
  • Streaming is also not available when using the Peer Channel transport

I/O Streams

WCF uses .Net stream class for Streaming the message. Stream in base class for streaming, all subclasses like FileStream,MemoryStream, NetworkStream are derived from it. Stream the data, you need to do is, to return or receive a Stream as an operation parameter.
[ServiceContract]
public interface IMyService
{
    [OperationContract]
    void SaveStreamData(Stream emp);

    [OperationContract]
    Stream GetStreamData();

}
Note:
  1. Stream and it's subclass can be used for streaming, but it should be serializable
  2. Stream and MemoryStream are serializable and it will support streaming
  3. FileStream is non serializable, and it will not support streaming

Streaming and Binding

Only the TCP, IPC, and basic HTTP bindings support streaming. With all of these bindings streaming is disabled by default. TransferMode property should be set according to the desired streaming mode in the bindings.
public enum TransferMode
{
   Buffered, //Default
   Streamed,
   StreamedRequest,
   StreamedResponse
}
public class BasicHttpBinding : Binding,...
{
   public TransferMode TransferMode
   {get;set;}
   //More members
}
  • StreamedRequest - Send and accept requests in streaming mode, and accept and return responses in buffered mode
  • StreamResponse - Send and accept requests in buffered mode, and accept and return responses in streamed mode
  • Streamed - Send and receive requests and responses in streamed mode in both directions
  • Buffered -Send and receive requests and responses in Buffered mode in both directions

Streaming and Transport

The main aim of the Streaming transfer mode is to transfer large size data, but default message size is 64K. So you can increase the message size using maxReceivedMessageSize attribute in the binding element as shown below.
<system.serviceModel>
    <bindings >
      <netTcpBinding>
        <binding name="MyService.netTcpBinding"
         transferMode="Buffered" maxReceivedMessageSize="1024000">
        </binding>
      </netTcpBinding>
    </bindings>
  </system.serviceModel>

WCF Transfer mode

In our normal day today life, we need to transfer data from one location to other location. If data transfer is taking place through WCF service, message size will play major role in performance of the data transfer. Based on the size and other condition of the data transfer, WCF supports two modes for transferring messages

Buffer transfer

When the client and the service exchange messages, these messages are buffered on the receiving end and delivered only once the entire message has been received. This is true whether it is the client sending a message to the service or the service returning a message to the client. As a result, when the client calls the service, the service is invoked only after the client's message has been received in its entirety; likewise, the client is unblocked only once the returned message with the results of the invocation has been received in its entirety.

Stream transfer

When client and Service exchange message using Streaming transfer mode, receiver can start processing the message before it is completely delivered. Streamed transfers can improve the scalability of a service by eliminating the requirement for large memory buffers. If you want to transfer large message, streaming is the best method.

StreamRequest

In this mode of configuration, message send from client to service will be streamed

StreamRespone

In this mode of configuration, message send from service to client will be streamed.

Configuration

<system.serviceModel>
    <services >
      <service behaviorConfiguration="ServiceBehavior"  name="MyService">
        <endpoint address="" binding="netTcpBinding"
         bindingConfiguration="MyService.netTcpBinding" contract="IMyService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" 
        contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true "/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <bindings >
      <netTcpBinding>
        <binding name="MyService.netTcpBinding" 
        transferMode="Buffered" closeTimeout ="0:01:00" openTimeout="0:01:00"></binding>
      </netTcpBinding>
    </bindings>
  </system.serviceModel>

Differences between Buffered and Streamed Transfers

Buffered Streamed
Target can process the message once it is completely received. Target can start processing the data when it is partially received
Performance will be good when message size is small Performance will be good when message size is larger(more than 64K)
Native channel shape is IDuplexSessionChannel Native channels are IRequestChannel and IReplyChannel