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.
  <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.

Comments

  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 2.2.7.0 Nuget package.

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

      Delete
    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.

      Delete

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP