BizTalk Server 2013: Connect to the Azure Service Bus
Introduction
BizTalk Server 2013 will offer some new adapters: WCF-WebHttp, SFTP, SB-Messaging, WCF-BasicHttpRelay and the WCF-NetTcpRelay adapters. Some of these adapters will bring the cloud closer to on premise systems. Through the connectivity with Azure Service Bus you can create hybrid solutions. The Service Bus can be a bridge between Azure, services or other cloud applications. Azure Service bus offers entities like Relay, Queues, Notification Hubs, Topics and Subscriptions. The interaction with these entities is possible with the SB-Messaging, WCF-BasicHttpRelay and the WCF-NetTcpRelay adapters.
Business Scenario's
Azure Service Bus is a durable, highly available and multi-tenant infrastructure that can be leveraged in for instance a store-and-forward scenario. Thousands of messages can be sent from multiple clients to a Service Bus Queue or Topic. BizTalk Server instance(s) can with their own pace pick up the messages and process them. The queue or topic offers a means of load leveling or balancing if you like. An enterprise does not have to scale-up or out its infrastructure on premise when it can leverage Azure Service Bus. It will be a different story when messages need to be processed within a very short time frame in on premise systems.
The Window Azure Service Bus offers relay service (entity) that offers connectivity to WCF-endpoints that reside within a corporate enterprise network, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure. With relay adapters of BizTalk Server 2013 the boundaries can be pushed to cloud. This means these endpoints can facilitate an entry point into a process or expose data within LOB-system through the cloud.
SB-Messaging Adapter
The SB-Messaging adapter enables you to send and receive messages from Service Bus entities like Queues, Topics and Subscriptions. These entities offer brokered messaging capabilities similar to on premise MSMQ and the BizTalk pub/sub mechanism. Messages can be sent to Queues and/or Topics and subscriptions and picked up by BizTalk through a receive location configured with the SB-Messaging adapter or messages can be sent to these entities by BizTalk through a send port configured with the SB-Messaging Adapter.
SB-Messaging - Address
Since Azure is a multi-tenant you as a user of the Service Bus service need to create a namespace to manage your queues, topics and subscriptions (see Service Bus Fundamentals). The namespace plays an essential role, when you configure the SB-Messaging adapter (Address and Authentication). The URL of the QUEUE consists of
sb://<namespace>.servicebus.windows.net/<name of the queue>/
and for a subscription
sb://<namespace>.servicebus.windows.net/<name of the topic>/Subscriptions/<name of the subscription>/
SB-Messaging - Prefetch
The Prefetch Count is an interesting setting. You will find this setting on the same tab (General) of the SB-Messaging, where you specify the address of the Queue or Subscription. The default value is –1, yet you can change the setting to specify the number of messages that are received simultaneously from the Service Bus Queue or a topic. You can find more on prefetching through MSDN Best Practices for Performance Improvements Using Service Bus Brokered Messaging.
Note: Setting the prefetch count to high can result in throttling in BizTalk Server as more inflight messages will enter BizTalk than can be processed. You might get the following warning: BizTalk host BizTalkServerApplication throttled because InflightMessageCount exceeded the configured throttling limit.
See also Service Bus Messaging: Queues, SB-Messaging Adapter – Part II blog post.
SB-Messaging - Session
With the Use Session check box you can use a Service Bus session to receive messages from a queue or a subscription. You will find this checkbox on the general tab of the SB-Messaging adapter transport properties. A session can be used to group messages that belong together and can be useful when you for instance want to support FIFO (first in first out) pattern.
SB-Messaging - Authentication
The authentication tab on the SB-Messaging adapter is intended to specify a URI for the Service Bus Access Control Service STS endpoint. You have to provide the credentials for authorization of Service Bus. The format of the URI is:
https://<namespace>-sb.accessscontrol.windows.net/
SB-Messaging - Properties
The properties tab SB-Messaging adapter is intended to specify a namespace for the brokered messages and choose to promote the message properties. Through promoted properties you have to ability to route the message.
WCF-BasicHttpRelay Adapter/WCF-NetTcpRelay Adapter
The WCF-BasicHttpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the BasicHttpRelayBinding. This is a binding that BizTalk can use to configure endpoints which can communicate with ASMX-based Web services and other services that conform to the WS-I Basic Profile 1.1. The BasicHttpRelayBinding is derived from the standard BasicHttpBinding. However, the key difference between the two is that the BasicHttpRelayBinding can create publicly reachable and, if required, publicly discoverable HTTP listener endpoint listening on Azure Service Bus, while the BasicHttpBinding listens through the standard HTTP.sys listener on the local Windows computer.
The WCF-NetTcpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the NetTcpRelayBinding. When configuring for instance a request response receive port, you can enable a receive location using the NetTcpRelayBinding. The receive location with contains an address using the “sb” URI scheme. Through the receive location the endpoint (address) will be registered in Azure Service Bus.
WCF-BasicHttpRelay/NetTcpRelay - Address
Specifying the address of a relay endpoint is similar to SB-messaging. The URI will contain the namespace, standard part of the DNS name being servicebus.windows.net and name of the endpoint:
http(s)://<namespace>.servicebus.windows.net/<name of the relay endpoint>/ (BasicHttpRelay)
or
sb://<namespace>.servicebus.windows.net/<ofname the relay endpoint>/ (NetTcpRelay)
The specified URI provides the address of the location where the relay endpoint is deployed on the Service Bus.
The endpoint identity can specified in case client required to authenticate the identity (i.e. service), see also Service Identity and Authentication.
WCF-BasicHttpRelay/NetTcpRelay - Bindings
With the Binding tab you can configure the time-out and encoding-related properties. Depending on your requirements you can specify different values than the default. See the following resources for the specific details:
- How to Configure a WCF-BasicHttpRelay Receive Location
- How to Configure a WCF-BasicHttpRelay Send Port
- How to Configure a WCF-NetTcpRelay Receive Location
- How to Configure a WCF-NetTcpRelay Send Port
WCF-BasicHttpRelay - Security
The Security Tab offers you the ability to specify the security for the BasicHttpRelay endpoint. You can specify the Security mode to Transport or TransportWithMessageCredential and the scheme will be “https”. Setting it to none and the scheme will be “http”. By checking the “Enable service discovery” checkbox you can specify whether the behavior of the service is published in the Service Registry or not. By checking this checkbox the Display name text box and Discovery mode combo box will be enabled. In the text box you can specify the name with which the service is published to the Service Registry. The Discovery mode can be private or public. Public means publishing in the Service Registry, while private means this will not happen.
WCF-NetTcpRelay - Security
In the Security tab you can specify security capabilities of the WCF-NetTcpRelay. Here you can specify the security mode, transport security, client security, discovery mode and access control service. The transport mode can be for instance Transport. The security is then provided through using TLS over TCP or SPNego. In case you choose None than it will mean that messages will not be signed or encrypted. In case you want to prevent tampering with messages you can sign the message and/or encrypted in case you require date-level privacy; you then have to choose Sign or SignAndEncrypt and specify the message security/service certificate.
WCF-BasicHttpRelay/NetTcpRelay - Messages
The final tab called Messages enables you to specify the data selection for the SOAP Body element. This is a common tab, which you can also find when configuring other WCF-based adapters in BizTalk, see also the WCF Adapters UI Help.
Other Resources
- How to configure the SB-Messaging Adapter
- A tutorial that involves the use of SB-Messaging adapter in BizTalk Server 2013
- BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 1
- BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 2 Brokered Message Properties
- BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 3 Sending message to Service Bus Queue
- BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 4 Sending Messages to Service Bus Topics
- BizTalk 2010 R2 CTP: Azure Service Bus Integration–Part 5 Sending messages to Service Bus Queues using Sessions
- BizTalk Server 2013: New Adapters Series: WCF-BasicHttpRelay
- BizTalk Server 2013: New Adapters Series: WCF-NetTcpRelay
- BizTalk Server 2013: New Adapters Series: SB-Messaging
- BizTalk 2013: SB-Messaging Adapter
- New Cloud Based Adapters (video)
- How to integrate a BizTalk Server 2013 application with Window Azure Service Bus Brokered and Relayed Messaging
- Using the SB-Messaging Adapter & ESB Toolkit to send messages to Azure Service Bus
See Also
Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.