Exposing BizTalk Service to Azure Service

Bus
Version 1.0
Feb 1, 2012

Document Name

ExposingBizTalkServiceToAzure.pdf

Public Share Location

Contributor 1

Heena Parmar

Contributor 2
Contributor 3
Last save date

Friday , February 1, 2012

Stability

Version 1.0

Required Reviewers

1. Overview
This document gives a technical overview of how to expose a BizTalk WCF service to Azure using Azure
Service Bus. One example is used throughout the sections to explain the implementation details. To
understand this document, reader should have basic knowledge of Azure and BizTalk.

2. Azure Service Bus Overview

This section gives a brief introduction to Azure Service Bus Relay capabilities. For in-depth knowledge of
Service Bus, refer to the additional resources in the last section of this document.
Azure Service Bus is a highly scalable service running in Microsoft data centers as part of the Windows
Azure platform. It provides secure messaging and relay capabilities that enable building distributed and
loosely-coupled applications in the cloud, as well hybrid application across both private and public
clouds.
The primary feature of the Service Bus is to relay messages from clients through the Windows Azure
cloud to your software running on-premises, by-passing any firewalls, NATs, or other network obstacles
that might be in the way. A central component of the Service Bus messaging fabric is a centralized relay
service that supports a variety of different transport protocols and Web services standards.
The Service Bus is complemented by Access Control, another constituent of the Windows Azure
platform. ACS (Access Control Services) makes sure that the issuer and the issuer token is valid to call
the on-premise service from client service in Azure.
The on-premises service connects to the relay service through an outbound port and creates a
bidirectional socket for communication tied to a particular service bus address. The client can then
communicate with the on-premises service by sending messages to the relay service targeting the
rendezvous address. The relay service will then relay messages to the on-premises service through the
bidirectional socket already in place. The client does not need a direct connection to the on-premises
service nor does it need to know where it resides. The on-premises service doesnt need any inbound
ports open on the firewall.
Here is an example of creating a Service Bus namespace in Azure which will be used in further sections
to explain exposing BizTalk Services to Azure.

As we open Azure Management portal https://windows.azure.com/ with a signed up account,

there is a Service Bus tab visible on the left side of the pane as highlighted below:

On clicking this tab, you can create a new service namespace. Here, you give a unique
namespace for your service bus.

Once you press Create, the portal will begin activating your new service namespace. After the
activation process is complete, you can begin using your new service namespace to host Service
Bus endpoints. The portal will indicate that the new service namespace is Active once its
ready to use.
If you click on the service namespace, you can view the service namespace details. This page
gives you specific information about your service namespace including things like the
management key, the Service Bus issuer name/key, the registry URL, the Access Control
endpoints, as well as other details.

The Default Key highlighted above has the issuer name and issuer Key which is used by service
bus to authenticate the client and service.

The base URI for all endpoints within service namespace is

http://<namespace>.servicebus.windows.net/ (as highlighted above). If you browse to this base
address, you receive an Atom feed representing your Service Bus registry. It will be empty in the
beginning there are no registered endpoints within the service namespace.

3. Expose BizTalk Receive Location to Azure Service Bus

To start with, BizTalk Server should have latest Windows Azure SDK installed to leverage Service
Bus features.

Now you need to create a service with an operation which can take input (e.g. PurchaseOrder
standard schema). Using BizTalk WCF Service Publishing wizard you can publish this schema as
WCF service. You can specify any service name and operation name. (You need this step just to
get a WSDL for your service to generate proxy classes for use by client. You dont need to set it
in IIS as it can be hosted using BizTalk host (windows service.)

Next, after deploying the BizTalk schema, you need to create a service bus receive location in
your BizTalk application. For this purpose , you can use WCF-Custom adapter

Now, set the Azure Cloud address. Specify the address in this format sb://<servicebus
namespace>/<your servicename> . In the example case , the address looks like the following:

In the Binding tab, you can see the Relay Bindings for different protocols. Here, this example
uses netTcpRelayBinding.

Now set the Security mode to Transport and relayClientAuthentication to RelayAccessToken.

In order to authenticate with Azure Cloud service endpoint, you need to define security theme.
For this example, add transportClientEndpointBehavior extension to EndpointBehavior and set
the credentialType to SharedSecret.

Set the Shared Secret Name and Key as shown below. (Note that the screenshot shows the
SharedSecretElement is filled under ClientCredentials which was used till SDK 1.4. SDK 1.5
onwards, SharedSecretElement is filled under TokenProvider which comes as sibling to
ClientCredentials.

Set the serviceRegisterySettings discoveryMode property to public.

As part of this example, you can create a send port which subscribes to PurchaseOrder message
and put it into the file share.
Now, as the receive location is enabled, you can try browsing
http://<namespace>.servicebus.windows.net/ . Your Service should now be visible here.

Note: Receive location with service bus settings can be created directly through BizTalk Server
WCF Service Publishing wizard in BizTalk Server 2010. This enhancement in tool is part of App
fabric Connect.

4. Client to send messages to BizTalk through Azure Service Bus

As described in section 3, the BizTalk receive location is exposed as service to Azure Service Bus.
Now, any client which authenticates itself with the Azure Service Bus can send the message to this
service. This client can be a Web role/Worker role/on-premise application etc.
In the example used, you can create a client console application to invoke this service.

Add the proxy class of the BizTalk service to your console application.
In the Main method, call the method by passing the required PurchaseOrder input message.
In the application configuration, choose a matching binding and behavior as that of the service.
This is shown below:

Once this application is run, client should be successfully connected to cloud, transmit a
message and the Azure Service Bus should redirect(relay) that message securely to the BizTalk
Server. As a result of the example used, a PurchaseOrder file should be created in the folder
path specified in the BizTalk Server send port.

5. References

A Developers Guide to Service Bus in Windows Azure AppFabric

http://go.microsoft.com/fwlink/?LinkID=150834