Integration with Microsoft Azure Service Bus
Microsoft Azure Service Bus is a set of cloud service capabilities provided by the Microsoft Azure cloud platform (https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview). This chapter describes some typical use cases, Sentinet configuration procedures and the benefits Sentinet provides for the Microsoft Azure Service Bus and covers the following Microsoft Azure Service Bus capabilities:
Azure Service Bus Relay service.
Azure Service Bus Queues, Topics and Subscriptions (asynchronous messaging).
Azure Active Directory.
Azure Service Bus Relay service
The Service Bus Relay service enables organizations to build and deploy hybrid applications running in both a Microsoft Azure datacenter and their own on-premises enterprise environment. The Service Bus relay facilitates this by enabling secure exposure of Windows Communication Foundation (WCF) services residing within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to the corporate network infrastructure.
Configuring WCF services with native Service Bus Relay protocols is challenging and requires fundamental changes to the services’ configurations and deployments:
Only WCF-based services can be natively integrated with Service Bus Relay service. Non-WCF services must use a Microsoft-provided or third party SDK (for example Java SDK) or special code for service applications (https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-hybrid-connections-dotnet-get-started) which creates tight coupling and code-dependency between service implementation and its capability to communicate with the Service Bus.
WCF services have to be reconfigured with WCF relay bindings (https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-wcf-dotnet-get-started) that implement Microsoft-specific, non-interoperable communication protocols (a client application may use interoperable protocols to consume Service Bus Relay services, but services themselves will always use Microsoft private communication protocols to connect to Service Bus Relay).
WCF services must be configured with the Service Bus management credentials associated with a Microsoft Azure account and Service Bus namespace. These credentials are used to connect on-premises services to the Service Bus Relay infrastructure, and they must be configured with each and every deployed service (which means credentials must be managed and preferably secured across multiple services).
Service applications are typically deployed as self-hosted WCF services. IIS server-based deployments are possible, but they are not trivial and require additional configurations of the IIS server itself.
Sentinet eliminates all the challenges above, and vastly simplifies a service's enablement with the Service Bus Relay service. As "transparent" intermediaries, Sentinet Nodes can mediate between Relay Service and physical Business Services.
Using Sentinet as an integration instrument for business services provides the following benefits:
Any service (including non-WCF and non-Microsoft services) can be on-boarded to the Service Bus infrastructure in a matter of minutes without business service reconfigurations. Moreover, Sentinet Nodes can create multiple dynamic endpoints used internally (on-premises) and externally (Azure Service Bus) at the same time (see example on the diagram above).
Business services do not require configuration with Microsoft-specific bindings and can remain deployed with their own Microsoft Azure-independent bindings and communication protocols.
Management credentials will be securely stored within the Sentinet Repository and centrally managed by Sentinet administrators. At runtime, Sentinet will deliver these credentials to the Sentinet Node(s), which will use these credentials to connect virtual services to the Service Bus Relay service.
Business services can remain deployed as IIS-hosted applications (Sentinet Nodes and their virtual services are always hosted in IIS server).
Additionally, Sentinet adds all the management capabilities discussed in this guide, such as managed security, access control, monitoring, SLAs management, alerting, versioning and more.
Sentinet Nodes dynamically connect virtual services to the Relay Service. By their nature, all these connections are outbound network connections. These connections are used by the Service Bus Relay Service to tunnel request messages inside the corporate network through the firewalls. Even though Sentinet virtual services are always hosted in an IIS server, they will not be using any of its listening capabilities. The IIS server in this case is just a hosting process providing virtual services with reliability and process isolation (through IIS-standard capabilities such as Application Pools isolation and lifecycle management). At the same time, Sentinet Nodes are automatically configured with "always on" configurations, so that virtual services are guaranteed to always stay connected to the Service Bus Relay Service as long as the IIS server itself is up and running.
Sentinet Node Base Addresses for Microsoft Azure Service Bus
The Node Base Address chapter in this guide describes how Sentinet Nodes inherit their base addresses from the IIS server configuration resulting in Sentinet virtual services deriving their addresses from the Sentinet Node base addresses. This however, is not true for virtual services connected to the Service Bus Relay service, because these virtual service addresses are derived from Microsoft Azure Service Bus. That means that Microsoft Azure Service Bus addresses are configured straight from the Sentinet Administration Console rather than from the Node Configuration Wizard.
Click the [+Add] button to add Microsoft Azure Service Bus base address.
Figure. +Add address button for the Node Microsoft Azure Service Bus Base Addresses. In the Add Microsoft Azure Service Bus Address wizard:
a. Select address transport scheme that will be used by consumers of the virtual services hosted by Sentinet Node, but available through Microsoft Azure Service Bus external addresses (sb, http or https).
b. Provide [namespace] that matches the Microsoft Azure Service Bus namespace associated with the Microsoft Azure account.
c. Select Service Bus Credentials Type. Specific credential type and credential itself must be obtained from the Microsoft Azure portal.
Figure. The Add Microsoft Azure Service Bus Address wizard box. Once a Microsoft Azure Service Bus address is added, it will show up in the Node Base Addresses list.
Figure. Service Bus address with Shared Secret credentials added to the Node Base Addresses.
Sentinet administrators can add more Service Bus base addresses. They can be associated with different transport schemes, Service Bus namespaces and Service Bus credentials. Service Bus addresses and their credentials can be changed at any time by clicking the [...] modify button located next to each Service Bus address entry.
Note
Service Bus credentials are stored securely in the Repository. Assigning these credentials is a one-time user-initiated action on the Node Summary screen. From that point onwards, users can create any number of virtual services connected to Microsoft Azure Service Bus without entering associated credentials (that can be shared across multiple virtual services).
Virtual services hosted on the Microsoft Azure Service Bus
To enable a virtual service with a Microsoft Azure Service Bus connection, follow the exact same procedure as described in the Designing Virtual Service chapter in this guide. The only difference is in how a virtual inbound endpoint is selected. When a user drops Sentinet Node on a virtual service Inbound Endpoints surface, he can select a Microsoft Azure Service Bus address from the dropdown list of available virtual service base addresses that now include Microsoft Azure Service Bus addresses configured with the Node.
Note
A virtual service can be provided with more than one inbound endpoint. Some of the endpoints can be designed to provide a virtual service with the internal addresses, while others can be used for external accessibility via Microsoft Azure Service Bus addresses.
Once a Microsoft Azure Service Bus address is assigned to a virtual endpoint, the latter must be configured with the policy associated with this endpoint. WCF binding for Microsoft Azure Service Bus should be used to configure inbound policy: https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-wcf-dotnet-get-started. As described in the Endpoint Policy and Policies chapters, select a WCF Relay binding compatible with the virtual endpoint transport (Sentinet will warn against configuring incompatible transport and policy).
Sentinet Nodes can be deployed in a hybrid scenario that fully decouples client and service applications from the Microsoft Azure Service Bus Relay Service. The diagram below shows two Sentinet Nodes, one on-premises and another in the cloud that completely encapsulates Service Bus Relay Service. Both external consumer applications and internal on-premises services can use "standard" protocols and security, while exchanging messages over non-interoperable Service Bus protocols.
Microsoft Azure Service Bus Queues, Topics, and Subscriptions
Microsoft Azure Service Bus provides brokered (or asynchronous) messaging capabilities. Senders and receivers do not have to be online at the same time. The messaging infrastructure reliably stores messages until the receiving party is ready to receive them. The core components of the brokered messaging infrastructure are Queues, Topics, and Subscriptions.
Sentinet can provide any service or client application with the capability to integrate with Microsoft Azure brokered messaging service. Neither service nor the client applications must be enabled with the knowledge, code, or configurations that are specific to the Microsoft Azure Service Bus messaging.
Cloud-based or on-premises Sentinet Nodes can be configured with the Service Bus (sb://) endpoints as described in the previous chapter. A special Microsoft WCF binding, NetMessagingBinding (https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.netmessagingbinding) can be registered in the Repository and used with the virtual service endpoints to send messages to, or receive from the Microsoft Azure Service Bus Queue, Topic, or Subscription. The diagram below shows one possible (hybrid) scenario where both client and service applications are decoupled from the knowledge, code, or configurations specific to Microsoft Azure Service Bus. At the same time, it demonstrates a complete end-to-end scenario enabled with asynchronous messages delivery and load-leveling provided by the underlying Microsoft Azure Service Bus infrastructure.
Note
Service Bus Queue, Topic and Subscription addresses of the Sentinet virtual services are managed the same way as described in the Sentinet Node Base Addresses for Microsoft Azure Service Bus chapter. Note, you must specify address of the existing queue, topic and subscription as part of the actual virtual service endpoint derived from the Node Base Address. For example:
Node Base Address: sb://mynamespace.servicebus.windows.net/myapplication
Virtual Service endpoints:
sb://mynamespace.servicebus.windows.net/myapplication/myqueue1
sb://mynamespace.servicebus.windows.net/myapplication/myqueue2