Using Azure Hybrid Connections to Consume an On-Premises WCF Service from the Cloud
July 14, 2014 13 Comments
Microsoft introduced Hybrid Connections a few weeks ago, a [currently] free version of BizTalk Services that allows you to seamlessly connect Web Sites and Mobile Services hosted in Azure to LOB systems residing within your organisation’s network. Similar to Service Bus Relays, there is no need to open inbound firewall ports as a locally installed agent can establish the connection to Azure from within your network. To help support this feature, Microsoft also introduced a free tier of BizTalk Services specifically to accommodate Hybrid Connections.
The most obvious question asked by most is, “Will this replace Service Bus Relays?”. After all, they do seem very similar in concept. Michael Stephenson wrote an excellent blog post addressing this very question and identifying the key differences as well as the situations you would most likely choose one technology over the other.
What has sparked my post here is that the only examples I found highlighting this new feature were aimed at connecting to on-premises databases. While this is certainly impressive and useful (especially since your Azure Web Site can use the exact same connection string you would use for on-premises access!), it left me wondering how Hybrid Connections could be used to expose WCF Services within an internal network – without the need for configuring relay bindings. My interest in this capability has arisen from some recent experiences building hybrid solutions for our clients:
- Some proprietary web services are not always accessible to the necessary custom configuration, either because they weren’t implemented in .NET or because of other constraints; this meant having to create “wrapper” WCF services just to host the necessary relay bindings;
- I found the Relay Services to be unstable and unpredictable, and often logging mysterious errors. I also found a need to write custom code to implement auto start and recoverability on faults.
So, I decided to give Hybrid Connections a test to see how easy it is to achieve the same thing:
- I created a simple WCF service and published it to a machine within our company’s network, and proved that I could only access this service when logged into our VPN.
- I then created a simple ASP.NET website that calls the service and displays the results to the screen.
- I created an Azure Web Site and published the ASP.NET web site to this location.
- Using the excellent step-by-step directions found here, I logged into the new Preview Portal and enabled Hybrid Connections for this website, creating a new BizTalk Services instance in the process.
- Finally, I downloaded the “On-Premises Setup” component and installed it on the machine where my WCF service was hosted.
The result? I could access the service via my Azure Web Site whether I was logged into the VPN or not! 🙂 And the best part was there were no modifications required to the WCF service itself.
Technical Details
If you’re interested in the details of how I proved this, here they are.
The WCF service very simply has one operation on it:
namespace EchoService
{
public class EchoService : IEchoService
{
public string Echo(string value)
{return string.Format(“[{1}] You entered: {0}”, value, Environment.MachineName);
}
}
}
Notice that I echo the machine name – just to prove where the called service is being hosted.
The ASP.NET service uses a very simple web form that calls the WCF service and displays the result:
public partial class WebForm1 : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}protected void Button1_Click(object sender, EventArgs e)
{
EchoService.EchoServiceClient client = new EchoService.EchoServiceClient();
lblResult.Text = client.Echo(txtInput.Text);
}
}
When configuring the Hybrid Connection, I simply used the server name and port 80 (if I was hosting the service over SSL, I suppose I’d use port 443):
Finally, I ensured that the when setting the address in the client WCF binding within the Web Site configuration file, I used the same hostname specified in the Hybrid Connection configuration (note that you’ll need to set this prior to publishing the service to Azure):
Once this is published, you can browse the Web form, enter the data and see the result of calling the service (including the machine name of the server hosting the WCF service):
Unfortunately, you can only use Hybrid Connections from a Web Site or Mobile Service client hosted in Azure at the moment. Knowing that every BizTalk Services bridge has an HTTP receive endpoint, I looked for my Hybrid Connection bridge in the BizTalk Services Management Portal – but alas, discovered it was invisible:
This seems to have dashed any hopes of using this bridge to connect to an on-premises service from another external non-cloud client. If that’s your requirement, I’m afraid that Azure Service Bus Relay Services are still your best option.
Why Would I Use This?
Again, Michael Stephenson’s article goes a long way to explaining the various scenarios for using Hybrid Connections vs. Service Bus Relays, but when it comes to calling internal web services, these are my top drivers for using the former:
- No modification is required to the target service OR it’s configuration
- The service doesn’t have to be implemented in .NET (as long as you can use a .NET WebClient to consume it)
- No custom code is required; it can be configured entirely within the Azure Management Portal (preview version)
- It is (hopefully?) more stable & reliable that Service Bus Relays (would need some extensive testing to prove this)
About Dan Toomey
Mind Over Messaging 
Hi Dan,
I’ve been trying to follow you footsteps with that Hybrid Connection example above but keep failing. I’ve hosted the on-prem service, configured the Hybrid Connection successfully (according to the “connected” state in the portal).
I’ve written a tester site, tested it locally successfully but after publishing the tester site to Azure I get: The remote name could not be resolved: ‘MyOnPremName’.
Any idea? How did you create the proxy? ChannelFactory? Web reference?
Thanks,
Assaf
Hi Assaf,
It was a while ago, but I don’t remember an issue with this except that I needed to use the fully qualified hostname in both the HC definition and the proxy. Can you please email your code to dan@ and I’ll have a look?
Cheers,
Dan
Hi Dan,
I’m running into the same issue as Assaf: the remote name could not be resolved. Do you recall what his fix was, or do you have any ideas for troubleshooting?
Thanks,
Rob
Hi Rob,
I do not know exactly how Assaf solved his problem, except that perhaps he tried using the fully qualified domain name like I suggested(?) Have you tried that?
Cheers,
Dan
Hi Dan,
How can we achieve load balancing with azure hybrid connections when connecting to web services? It seems that hybrid connections has no awareness of dns and we are forced to use fully qualified domain name in our configuration. Is this possible to set up?
Thanks,
Christine
Hi Christine,
If you download & install the Hybrid Connection Manager agent on each web server and register the same Azure Hybrid Connection with it, then the messages will automatically load balance between the two on-premises servers. Follow the step “Install the on-premises Hybrid Connection Manager to complete the connection” on this page (browse to the Azure Portal from each server to do the local install): https://azure.microsoft.com/en-us/documentation/articles/web-sites-hybrid-connection-get-started/
If you want more detail, might I also suggest you check out this Pluralsight course: https://www.pluralsight.com/courses/azure-hybrid-connections-first-look
Hope this helps,
Dan
Hi Dan,
Are there any limitations for the Preview version, e.g. number of transactions, connections, etc ? i.e. other than it not being actually supported by Microsoft, are there any technical reasons why it could (or should) not be used in a production environment (for a non-critical application) ?
Thanks,
Neil
Hi Neil,
The first question is easy to answer. 🙂 At the time the preview was announced (over 1 1/2 years ago!), you were allowed up to five HCs for the free BizTalk Services (MABS) edition (which is all you need if you’re not using any other features of MABS); you get more HCs (10, 50, 100) for the Basic, Standard & Premium edition of MABS. Remember that a HC is defined by a server name and port #, so you can have as many client instances or applications using the same HC as you want, as long as they all target the same on-premises server/port. Similarly, you are limited to 5GB/month data transfer in free/developer editions of MABS (50GB|250GB|500GB for Basic|Standard|Premium editions), but the overrun cost is about $1/GB.
The second question is much more difficult. This has been in preview for a long, long time with no updates. Moreover, the latest Integration Roadmap released by Microsoft (http://aka.ms/integrationroadmap) suggests that MABS is on the way out. My personal opinion is that HC will go out with it and be replaced by App Service Connectors & Logic Apps. Some of the connectors already available (File Connector, SQL Connector) use a form of Hybrid Connections under the covers (although it is slightly different in that it relies on Service Bus rather than MABS). If this is a production solution, I would recommend you consider using Logic Apps & Connectors rather than the previewss version of Hybrid Connections; that is scheduled to go GA in the first half of this year. It’s not free like HC, but the solution is more likely to endure.
Hope this helps,
Dan
Hi Dan,
Yes, it helps a lot. Many thanks for your prompt and detailed reply.
Cheers,
Neil
Hi Dan,
Thanks for sharing this article – very helpful for a hybrid newbie. You mention that access to a hybrid connection can only be done from web app or mobile app. Just to be sure – does this mean that other clients residing in virtual machines (running on Azure) or other resources will not be able to use this hybrid connection?
Thanks in advance,
Niles
Hi Niles,
Unfortunately, I believe that is still the case. Hybrid Connections (as in the original BizTalk Services offering) hasn’t changed much – mostly because I expect it will be replaced by the on-premises gateway offering that is implemented via Service Bus. Whether that will be as flexible (or more flexible) than the current preview Hybrid Connections… well we both wait to see. 🙂
Dan
Recently, anther Hybrid Connections (HC) became a new component of Service Bus (ASB). This new ASB HC is distinct from ASB Relay _and_distinct_ from_ the HC integrated into Web and Mobile Apps.
The new ASB HC is much more similar to ASB Relay from a scenario perspective as it is an agentless method to connect any two parties that want to talk to each other (neither has to be on-prem). It is based on Web Sockets (no WCF) and offers binary communication.
The Web/Mobile App HC is more like the Power App/Power BI/Logic App/etc Data Gateway as it uses a service gateway coupled to an on-premises agent for the specific scenario of brokering calls from Azure assets to on-premises data sources.
At least that’s my understanding currently… still trying to suss out all the options myself.
That’s right, Kris. It’s called Azure Relay, and I’ve written another post about that recently on my employer’s blog: https://www.mexia.com.au/the-new-azure-hybrid-connections/