Azure Service Bus Relay – Part – 2 – Under The Hood and Implementation

It’s very important to understand as to how the things take shape under the hood in the Service Bus Relay as this would give a better way of creating solution architecture while using Service Bus Relays.

Service Bus relay provides two-way synchronous communication between applications. For the relay to be created and for communication to happen the WCF service that sits inside your on premise data center should be configured with relay bindings. Service bus makes use of relay bindings to create a bi-directional communication channel. The on premise application opens up an outbound TCP connection with the provided Service Bus namespace. Since the on premise applications/services are located within the organizations data centers, it is safe to assume that they are behind the firewall and makes use of NAT (Network Address Translation). One clear doubt would be how would the new services know where are the services residing and how to overcome the firewall or NAT issues. This is taken care of by the Service Bus and as discussed earlier, since an outbound TCP connection is being established by the applications hosted inside the datacentre, the firewall does not block the incoming data since it doesn’t have to open any new ports. This approach helps overcome the firewall / NAT issues and since the application has a consistent endpoint in the cloud, the external applications that’d like to take advantage of the applications/services being hosted on premise can directly talk to the service bus relay in the cloud, which would then tunnel the request to the on premise applications. All the communication happens through the Service Bus Relay thereby providing a way to overcome the communication challenges.

The most important thing to remember however is Service Bus Relay’s cannot be created from the portal. You can only create the Service Bus namespace. The Relay channel has to be created by the service that is going to accept the requests via the relay by making use of the Service Bus API’s. The relay is created automatically only when this application creates the TCP connection with the service bus and the relay is deleted once the channel is dropped/closed. Internally, however Service Bus maintains a registry that allows applications to check for a specific relay by its name.

The following are the quick steps to create and make use of the Service Bus Relay


Step 1: Create a Service Bus namespace

For this, you’ll need an Active Azure account. Details for the same can be obtained from However, assuming that you have an active subscription/account, you can go ahead and follow the below steps

Login to, under the “ALL ITEMS” section, select “SERVICE BUS”.  In the bottom action bar, click “CREATE”. This opens up a pop-up to create a namespace. Provide a valid Namespace Name, Azure checks if the namespace is available. Under the type, ensure that MESSAGING is selected. You can choose the kind of MESSAGING TIER needed as per your requirement(if you are not sure of which one to choose, then ensure you read about it from the Azure portal before going ahead and choosing the one that fits your requirement, by default STANDARD is selected). Next choose a REGION that is close to you/your clients and provides you with the best performance possible, ensure that if you have some COMPUTE resources deployed, then the service bus is also created in the same or the closest region as that’ll lead to better performance. Go ahead and create the namespace.

To work with the Service Bus relay, we’ll need the Shared Access Signature (SAS). Once, the namespace has been created, click on the namespace. In the Shared access key generator under the CONFIGURE, you’ll notice that a POLICY NAME, PRIMARY KEY and SECONDARY KEY have been generated by the portal itself.


The service bus relay can only be created via the API’s and not through the portal.


Step 2: Creating the Service

Create a WCF project -> Add/Install the Service Bus nuget package to both the Server and Client Projects(The nuget package adds all the references needed to the solution).


Ensure that you create the Service first and then the Client. Your Operation Contract interface makes use of an interface that makes it easy to manage the proxy lifetime. For example if your class name is “GetData” and the interface is “IGetData” then ensure that the Proxy channel lets say “IGetDataChannel” implements both the “IGetData” and “IClientChannel” (The IClientChannnel interfaces provides the operations that are supported by all channels returned by a call to ChannelFactory<TChannel> –


Your solution would look something similar to this




Step 3: Configuring the Service

You can either Configure the service programmatically or through the App.config file. Ensure that in either of these cases you provide the necessary service bus namespace, SAS key that you’ve generated/created from the Azure portal. You can also self-host the service through console by making use of the “ServiceHost” class provided in the “System.ServiceModel” assembly. Another aspect to remember is that the since we’re making use of the Service Bus which makes of relay communication and TCP services, when we add the service bus nuget package, at least one end point with Relay binding has to be configured so that the communication takes place. Whether you choose to create local endpoint or not is up to you based on your requirements.


Step 4: Creating and Configuring the Client

The service that we have created in the above steps needs to be consumed by the client. Since we’re using the IClientChannel which create a channel factory object our client must also make use of the ChannelFactory object for service consumption. One important point to note is that Service Bus makes use of token-based security model using the SharedAccessSignature(SAS). Remember that the Azure portal provides the SAS key while creating the Service Bus namespace(Step 1 for reference). It’s better to leverage the “TokenProvider” class which provides built-in methods to create a token. “CreateSharedAccessSignatureTokenProvider” method from the “TokenProvider” can be used. You’ll either need to refer or copy the “IGetData” contract as created in the service into the client project.  You can configure the client either programmatically or through the App.config file in the client project.


To configure programmatically

Next, you’ll have to modify the main method of the client and it should look similar to the following





To configure using App.config


Add the following endpoint and definitions directly beneath your system.serviceModel to the App.config file


Note that the path name is the one that appears in the service bus relay section of the Azure portal.




Other points

  • You can notice the service bus relay making use of port 443 (SSL port) for tunnelling the data between Service Bus relay and on premise service. It might fall back on to port 80 which is the http port in case of 443 being used. Tools like Fiddler can be used to monitor the same. To use the Service Bus relay, ensure that your firewall allows outgoing TCP communication on TCP ports 9350 to 9354.


Flow of Request – > Response Mechanism while using Service Bus Relay