The Azure Service Bus Relay (ASBR) service enables organizations to host internet-accessible services and APIs, which reside inside a corporate network, without having to open up a firewall connection or requiring intrusive changes to the corporate network infrastructure.
Figure 1. Azure Service Bus Relay
The reason on-premises backend APIs are accessible from outside of an internal network, is because API communication leg marked as (2) on the diagram above requires establishment of a Microsoft proprietary TCP/IP connection from the backend API to the ASBR, while communication leg marked as (1) remains classical RESTful endpoint. The special tunneling connection (2) requires special API coding, configuration and deployment. You cannot just take any existing RESTful API and with no changes to it, make it available through ASBR.
Pseudo "Integration"
The benefits of using Azure Service Bus Relay are well known and well covered by the Microsoft and Microsoft developer community, and I am not going to cover them here. One of the common questions that Microsoft developer community asks: is it possible to integrate API Management (APIM) services with Azure Service Bus Relay to get the benefits of applying APIM concepts to ASBR? And the obvious answer is yes . All you have to do, is to place APIM in-front of the Azure Service Bus as shown on the diagram below.
Figure 2. API Management and Azure Service Bus Relay
APIM infrastructure (by means of using its cloud API Gateway/API Proxy) forwards messages to internet-accessible Azure Service Bus Relay endpoint, which is nothing else but a classical http(s) RESTful API endpoint. That’s what makes it possible and easy - for APIM this endpoint is just another "classical" RESTful backend API’s endpoint, there is nothing special about it from the APIM perspective. As a result, any API Management vendor can easily claim “integration” with Azure Service Bus Relay service. Notice, how I placed “integration” in double-quotes. This is because in my mind, this scenario has nothing to do with the real integration - it’s just a use case of using APIM with Azure Service Bus Relay.
Real Integration
This article is about entirely different use case scenario, which provides its own unique and very practical benefits that go beyond the “pseudo” integration scenario described above.
What if we can move API Management on the Figure 2 above from being in-front of ASBR to be behind ASBR? What would it mean?
Now the proprietary ASBR tunneling connection (2) is between API Management (API Gateway/Proxy) and Azure Service Bus Relay. API client application and on-premises backend API remain unchanged and unaffected by the presence of ASBR and APIM between them, which means (1) and (3) are classical RESTful API connections with whatever “standard” security models they implement (including Windows Integrated Security for on-prem Active Directory for connection (3). If this is all possible, then APIM would have to know how to create, destroy and manage proprietary connections (2) with ASBR, which means that they both must have capability to “talk” to each other through a proprietary ASBR mechanism. This is what I call the “real” integration!
But what would be the benefits of such integration? They are actually very strong, and there are quite many of them:
Backend internal APIs can be deployed anywhere in the internal network as long as they are accessible by an internal on-premises API Gateway (which is not an issue because they are all deployed inside the same internal network).
Backend internal APIs can be implemented, configured, deployed and maintained with no knowledge of Azure Service Bus Relay existence. Transparent API Gateway in-front of the backend APIs will take responsibility to deal with ASBR.
You can control which backend APIs should be available through ASBR via APIM Administrative Console (APIM Portals).
You can dynamically create and destroy connections between API Gateway and ASBR using just an APIM Administrative Console (APIM Portal) User Interface or its Management API.
That means you can control when and how to pay for ASBR connections (which are cheaper than using Azure VNET for on-premises APIs with APIM).
You can drop ASBR connections when you don’t need them and bring them up again when you do. Nothing needs to be done with your backend internal APIs, they can keep running all the time.
You can control ASBR paid connection on a “per API” basis, each API connection is maintained individually. Some of them can be enabled, while others can be disabled.
You can change Azure Service Bus Relay configuration and its properties any time you want (for example, change Shared Access Keys). This does not affect backend internal APIs, you only have to change configuration of APIM Gateway (which is done using APIM Administrative Console).
You can expose any RESTful API via Azure Service Bus Relay, even APIs developed using non-Microsoft technologies.
If API Gateway supports SOAP services and it supports SOAP to REST translations, you can take any internal SOAP service (for example, on-premises BizTalk Server’s SOAP service) and expose it as REST API via internet-accessible Azure Service Bus Relay RESTfull API.
Implementation
To implement scenario described above, an APIM Gateway must:
Be deployed On-Premises (which excludes Azure API Management, which does not have on-premises API Gateway).
Must understand proprietary Azure Service Bus Relay protocol (which excludes all APIM vendors except Nevatech Sentinet API Management software, because all other vendors do not offer Microsoft-native APIM solutions capable of understanding Microsoft-specific protocols).
Sentinet API Management software from Nevatech can be configured to support “real” integration with Azure Service Bus Relay in few simple steps described below.
First you create a new (or use existing) Azure Relay service resource.
Create Azure Service Bus Relay resource.
Capture Primary (or Secondary) Key for your relay Shared Access Policy. For simplicity, use default RootManagedSharedAccessKey. Sentinet will also support other custom Shared Access Signature Policies.
Now you should go to Sentinet Administrative Console to configure its support for Azure Service Bus Relay created in step 1 above.
Configure Sentinet Node (which is a Sentinet API Gateway) with the knowledge of how to connect to your ASBR. Select (or create a new) Sentinet Node of Mixed Transports mode type.
Add Microsoft Azure Service Bus Base Address to the Sentinet Node, which will be the Base Address for all virtual services hosted (connected to) on your ASBR created at step 1 above. Type in your Azure Relay’s namespace (which is the name of your Relay created in step 1 above) and select Shared Access Secret option.
For Key Name enter RootManagedSharedAccessKey from step 2 above, and for Shared Access Key Value enter Primary Key captured from the same step 2 above.
Now you have enabled Sentinet Node with capability to create unlimited number of service relay connections to that particular ASB Relay resource. For example, Sentinet Node shown on the screenshot below has capability to connect to ASBR resource nevatechrelay with options to expose ASBR external endpoints over three protocols, http, https and sb (sb for SOAP services only) which are highlighted in red. You can also configure different Relays with the same Sentinet Node (for example, sb://nevatech2017.servicebus.windows.net below).
Design new virtual service that virtualizes your physical (backend) REST API. In my test I was using sample Order REST API shipped with the Sentinet, and I hosted it on my local machine which is behind the internet-facing firewall. You use the same drag-and-drop Sentinet User Interface as if you design any other REST API, except that when you configure virtual service endpoint, you select Azure Service Bus Node address from the drop-down and add unique postfix to it, for example orderAPI. In my case, the resulting endpoint address becomes https://nevatechrelay.servicebus.windows.net/orderAPI .
Interestingly, if you have existing Sentinet virtual service, you can also add new Azure Service Bus Relay endpoint(s) to it extending API’s reach to the internet, while keeping internal endpoints unchanged.
When you enable or disable ASBR endpoint(s) from the Administrative Console, the connection to Azure Service Bus Relay will be automatically created or dropped, which is a very effective way to control Azure Service Bus Relay costs and endpoints availability.
Moreover, you can see from the Azure API Portal how these connections come up in the list of the WCF Relay dynamic connections when they are created by Sentinet, and how they are gone from this list when Sentinet removes its Azure Service Bus endpoints.
Testing and Monitoring
You can test virtual service and how it calls backend service by sending sample REST message to Azure Service Bus Relay internet-accessible endpoint(s). In my case, I was using https://nevatechrelay.servicebus.windows.net/orderAPI endpoint for the virtual service designed in the Sentinet. I used Postman , but any API testing tool will do it too. Postman shows response received from my Order API, which is running behind the internet firewall.
Using Sentinet Monitoring and Recording capabilities, you can see real-time graphs and historical logs for these message exchanges, their key performance metrics and messages content for further business analytics, auditing, troubleshooting, etc. Sentinet provides detailed information about these message exchanges in the “end-to-end” scenario.
Conclusion
Nevatech Sentinet API Management provides unique capabilities to integrate with the Microsoft Azure Service Bus Relay service. Organizations that have On-Premises APIs and want to extend their reach over the internet can take advantage of these capabilities and create very practical benefits for their API solutions.
Acknowledgements
Thank you, Ahmed Taha at Link Development for inspiration for this article given by his excellent blog “Hybrid Integration with Sentinet”..