Service Bus Queues from Windows Azure - Integration with WCF

Today I will continue by blog posts about Service Bus Queue with a discussion about how we can integrate WCF in Service Bus Queue. As you well know, on a standard WCF service all the communication between client and server is made directly. The client and the server need to have the requested port open. Also the client needs to know the address of the server and so on.
What happens if the server is down for 3 seconds? The messages that are sending in that period of time will be lost. All the operations that are made between client and server in a WCF service as synchronous from the perspective of the message transfer (the client and server need to be available). The load balancing of the servers that hosts the WCF services can be a nightmare.
For all this problems Service Bus comes to help us. I will talk about WCF from the perspective of Service Bus Queues, but also other services from Service Bus support WCF (Topics for example).
Service Bus Queues enable us to have an asynchronous messaging delivery between the client and the service. Let’s see how we can use it.
The first steps is to defined the Service Bus Queue on Windows Azure portal and create our service contract. Only one-way connections are possible. This limitation comes from Service Bus Queue, which is not design to support two-ways connection – in the end is a queue.

[ ServiceContract ]
public interface ICarService
{
    [ OperationContract ( IsOneWay = true ) ]
    void Open(Car car);
    void Close(Car car)
}

[ DataContract ]
public class Car
{
    [ DataMember ]
    public int Id { get; set; }
   
    [ DataMember ]
    public string Number { get; set; }   
}

As you can see, we added the IsOneWay property to the OperationContract. Don’t forget to do this. Our simple service will be able to open and close a car remotely. After that we can define our WCF service as a normal service and host it on IIS or anywhere else. From the service implementation and hosting nothing changes.

public class CarService : ICarService
{
    public void Open(Car car)
    {
        ...
    }
   
    public void Close(Car car)
    {
        ...
    }
}

The service is defined normally. Because of this we can very easily change any WCF service to integrate with Service Bus. The only thing that we need to change is the configuration file. For the custom binding that we need we will need to use netMessagingBinding that is defined in the following assembly: Microsoft.ServiceBus. For this purpose we will need to configure this binding and specify this binding to the endpoint.

  <system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus"/>
      </behaviorExtensions>
      <bindingElementExtensions>
        <add name="netMessagingTransport" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus"/>
      </bindingElementExtensions>
      <bindingExtensions>
        <add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus"/>
      </bindingExtensions>    
    </extensions>
    <behaviors>
      <endpointBehaviors>
        <behavior name="myBehavior">
          <transportClientEndpointBehavior>
            <tokenProvider>
              <sharedSecret issuerName="[accountOwner]" issuerSecret="[secretKey]" />
            </tokenProvider>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <bindings>
      <netMessagingBinding>
        <binding name="queueBinding" closeTimeout="00:10:00" openTimeout="00:10:00"
               receiveTimeout="00:10:00" sendTimeout="00:10:00" sessionIdleTimeout="00:01:00"
               prefetchCount="-1">
          <transportSettings batchFlushInterval="00:00:05" />
        </binding>
      </netMessagingBinding>
    </bindings>
    <services>
      <service name="Demo.CarService">
        <endpoint name="CarService" 
                  address="sb://myNamespace.servicebus.windows.net/carServiceQueue"
                  binding="netMessagingBinding"
                  bindingConfiguration=" queueBinding "
                  contract="Demo.ICarService"
                  behaviorConfiguration="myBehavior" />
      </service>
    </services>
  </system.serviceModel>

Dont forget to specify the behavior configuration that are used to access the queue - in behaviorConfiguration. The same thing we need to do on the client also. Is not complicated at the end is only a configuration in a XML file – thank you Microsoft for this.
Now let’s see what happens under the hood. When a client will call our service, a message (BrokeredMessage) is automatically created and added to the Service Bus Queue. The server is configured to check any new messages that are on the given queue are will interpret them as WCF requests. In this simple way we can have not only asynchronous calls to the server but also a small repository to store the requests in the case the service is overloaded or down.
On the server side there is a hint. If you host your service on IIS then you will have a small problem. You need some way to keep the service running, because IIS don’t run a service as a console do – we need to “listen” the queue. On IIS 7.5+ this problem can be solved if we set the pool on always-running. In this way the Open method of the host service is called immediately after the pool is initialized. Another solution is to use AppFabric and set auto-start to true. Another primitive solution is to create a “worker” that calls our .svc (service) at a specific time interval.
What are the advantages to use Service Bus Queues with WCF? Reliable servers, Scalability, Flexibility, Security from networks perspective (we don’t need to open any port from our private network and we can host the service on-premise without any problem), Load distribution.
In conclusion this feature can be very easy integrated in any application that is already on the market with minimal costs, but the gain is enormous. It is simple and powerful and can guarantee all the requests will reach the server.