Skip to main content

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.
<add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus"/>
<add name="netMessagingTransport" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus"/>
<add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus"/>
<behavior name="myBehavior">
<sharedSecret issuerName="[accountOwner]" issuerSecret="[secretKey]" />
<binding name="queueBinding" closeTimeout="00:10:00" openTimeout="00:10:00"
receiveTimeout="00:10:00" sendTimeout="00:10:00" sessionIdleTimeout="00:01:00"
<transportSettings batchFlushInterval="00:00:05" />
<service name="Demo.CarService">
<endpoint name="CarService"
bindingConfiguration=" queueBinding "
behaviorConfiguration="myBehavior" />

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.


  1. Thanks for the post. This is probably the most important design pattern for getting high scale Azure solutions working & yet it seems to be the only article published on how to do it.
    Unfortunately This seems really straightforward until you try to do it.
    VS2013 is throwing an error on each of the extensions. "The element 'bindings' has invalid child element 'netMessgingBinding'. List of possible elemenets expected: 'basicHttpBinding, basicHttpsBinding, ... , udpBinding'.

    Is there a step we need to do so that these Extensions function as expected?
    Do you have any sample code of this working.

    I have installed the Windows Azure Service Bus Nuget package.

    1. I will look over this issue this weekend. I will come back to you.

    2. Turns out this is a known issue with VS Intellisense. It lacks the .WSD file that shows the valid syntaxes for the Service Bus extensions, as described in Microsoft.ServiceBus.xml.
      This results in the little blue squiggle warnings. The code compiles OK. You just have to ignore the warnings untill Microsoft or someone else creates the intellisense file.


Post a Comment

Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.