Top Banner
Exposing BizTalk Service to Azure Service Bus Version 1.0 Feb 1, 2012
12
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 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:

    https://windows.azure.com/

  • 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://.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:/// . 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://.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

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