BizTalk AppFabric Connect For Services

Last week I spoke at the Twin Cities Connected Systems User Group Meeting.  The title of my presentation was Integration with Windows Azure – Connecting to the Cloud.  During my presentation I talked about ways to expand on-premise applications to the cloud as well as how to connect cloud applications back to on-premise resources.  As part of my presentation I talked about the functionality provided through the BizTalk AppFabric Connect for Services.  There were a number of people that hadn’t heard of it so this entry talks about what it is and how it can be used.

So, as you build your composite applications, or just look to extend your current application, you may want to take advantage of the benefits offered by extending your application to Windows Azure.  This will let you leverage your existing on-premise artifacts, and LOB systems, in order to expose them and extend their reach to external clients in a secure manner.

Microsoft released the BizTalk Server 2010 AppFabric Connect for Services as a new feature for BizTalk 2010 which provides functionality to expose your BizTalk artifacts (schemas and Orchestrations) as WCF Services exposed through the Windows Azure cloud.  This new functionality is exposed through changes to the BizTalk WCF Service Publishing Wizard.  When you run this wizard you will see a number of new screens in addition to the screens that you are already familiar with.

To expose BizTalk services to Windows Azure, specifically Windows Azure ServiceBus, you will need to have a few prerequisite components installed. 

First, of course, you must have BizTalk 2010 and the BizTalk development tools installed on the machine where the AppFabric Connect for Service feature will be used.

Next, you must have the Windows Azure AppFabric SDK (1.0 or later) installed.

Lastly, there are benefits of having Windows Server AppFabric installed.  While this is not a requirement, it makes configuration setting easier (such as Auto-Start).

After all the pre-requisites have been installed, you will need a Windows Azure account and you will need to create a namespace for the Service Bus in the Azure Portal. 

Once this is done then you can start the wizard and walk through each of the screens.  The wizard walks you through selecting the type of endpoint (service or metadata) – as it did previously.  The next screen will be a new screen which will fork between the functionality of the old wizard (exposing web services on-premise only) or to sprinkle in the new screens to allow you to expose the services to the cloud.  This screen presents a single checkbox asking if you want to add a Service Bus endpoint.  It also reminds you that you need to have a ServiceBus service namespace.  Select the checkbox (otherwise there is really no need to keep reading this post).  The next five screens are the same as the screen in the original wizard (select either schemas or Orchestrations, select the assembly, select the public ports, assign the target namespace (and remember to check allow anonymous access)).  One thing that I found very helpful is that the wizard will take all of the selected ports and merge them into a single WCF service.  The last two screens are specific to the configuration of the Service Bus. 

The first is the Endpoint Configuration.

There are a number of options that will effect the output of the wizard.  The first is the Relay Binding option and you have three choices – BasicHTTPRelayBinding, NetTcpRelayBinding, and the WS2007HttpRelayBinding.  The Service Namespace is the namespace that you created in the Azure portal.  I am sure that this goes without saying but what you enter here must match with the name you created in the Portal. 

The Enable Discover checkbox lets the services you are exposing be publicly discoverable through the ATOM feed page created by Azure for your Azure Service Bus account. 

Lastly, the Enable metadata exchange on cloud tells the wizard to create the metadata endpoint in the cloud so that external clients can generate a proxy for your service.

The next screen takes the authentication information that you can find on the portal site. 

You will need to enter the Issuer Name and Key.  When you created the namespace in the Azure ServiceBus the issuer name defaults to owner.  Enter both the Name and Key into the text boxes.  The first checkbox controls whether the consumer needs to authenticate using to the relay service to consume the endpoint.  The second checkbox controls the same but for the metadata endpoint.  Since you are charged per access to your endpoints you may want to set these to prevent unauthorized access.

Click Next and Finish to complete the wizard.  Once it is finished you will have a new Receive Port/Location and a site in IIS.  However, there are still a number of important steps that need to be done in order for your service to work.

If you created a service based on an Orchestration then you need to bind the port to the orchestration in the BizTalk Administrator.  You will also need to Enable the Receive Location and Enlist the Orchestration.

Next we move to IIS.  We need to have an Application Pool that is configured to use the .NET Framework 4.0 with the Pipeline set to Integrated.  Set the site to use the Application Pool by right clicking on the site that was created.  In the popup menu, select Manage Application and then click on Advanced Settings.  When the Advanced settings dialog box appears change the Application Pool to use the one you just created.

Lastly, we need to start our service.  If you are running IIS 7.5 (Windows 7 or Windows Server 2008 R2) then you can configure Auto-Start.  If you are running a different OS version then you will need to start the services using the on-premise endpoint with a local client.  Once the service is started it will make contact with Windows Azure and register the service.  One thing to note is that this is the first time in the entire process that your service has communicated with Azure.

If you have Windows Server AppFabric installed then configuring Auto-Start if very simple.  To do this, right click on your site and select Manage WCF and WF Services in the popup menu, then click the configure item in the fly out menu.  When the dialog box appears, select Auto-Start from the left hand side and then click the Enabled radio button.

You are now ready to test your endpoint.  Point your browser to .servicebus.windows.net">.servicebus.windows.net">https://<servicebusnamespace>.servicebus.windows.net.  You should see the ATOM feed page and your service should be listed.  You can click on the service and you should see a new page with your service and MEX endpoint.  You can now consume this endpoint the same is if it were on-premise.

Comments

• Anonymous
  March 20, 2012
  Helpful... thanks!

• Anonymous
  March 20, 2012
  Very Helpful :-)