This week I gave a presentation to the Sydney BizTalk User Group on (Biz)Talking to the Cloud. I showed how we can quickly and easily configure a BizTalk Receive Port to consume services hosted in the cloud. In the demo, we configured BizTalk to participate in a multicast events scenario.

I have been playing further with BizTalk and Cloud services and in this post I will demonstrate how to expose BizTalk Orchestrations to the Cloud. To make it easy for you to build this on your own environment, I have used the now famous (or infamous) EchoService as the basis of this demo. This allows you to use the existing Microsoft .NET Services SDK sample to call the BizTalk Orchestration through the cloud.

Before You Begin

1. Sign-up to Microsoft .NET Services and create your Solution.
2. Download the Microsoft .NET Services SDK and install on your BizTalk Server 2006 R2 development environment.
   Note: Nothing more is needed as far as BTS is concerned. I am pleased Microsoft is making good on ensuring developers can use existing skills and technologies to get started with cloud services. Furthermore, we can be fairly comfortable that playing around with this stuff is not going to break or render our existing dev environment useless. Credit where credit is due.

BizTalk Development

In this step we will create a simple orchestration that receives a generic message, pulls the "echo" text out, creates the response message, and sends it back out the two-way port. I have used System.Xml.XmlDocument types avoiding the need to create schemas and simplifying the demo.

1. In Visual Studio 2005, create a new Empty BizTalk project.
2. Go ahead and set your Assembly Key File and BizTalk Application project settings. (I called my BizTalk App BizTalk Services as we will see later on)
3. Add a new Orchestration to the project.
4. Create the following messages:
   

Name	Type
msgRequest	System.Xml.XmlDocument
msgResponse	System.Xml.XmlDocument



5. Create the following variables:
   

Name	Type
strText	string
strResponse	string
xmlDoc	System.Xml.XmlDocument



6. Add the following shapes to the design surface
   
   
   
7. In the Message Assignment shape enter the following code to construct the response message:
   

// Retrieve the text sent in the request
strText = xpath(msgRequest, "string(//*[local-name()='text'])");

// Construct the response
strResponse = System.String.Format("<EchoResponse xmlns=\"http://samples.microsoft.com/ServiceModel/Relay/\">
                                      <EchoResult>{0}</EchoResult></EchoResponse>", "BizTalk: " + strText);

// Create the response document
xmlDoc.LoadXml(strResponse);

// Assign the response message variable
msgResponse = xmlDoc;

8. Now add a Two-Way port setting the port Binding to Specify Later and the Type Modifier to Public.
   Note: As we will be binding to a physical receive port, operation names are not important here.
9. Wire up the port operations and don't forget to set the Activate property of the Receive shape
10. Build and deploy your project.
    

BizTalk Application Configuration

In this step we will configure a WCF-Custom receive port to expose our newly created orchestration to the cloud.

1. In BizTalk Server Administration Console, navigate to the BizTalk Application you just deployed to (mine was called BizTalk Services).
2. Create a new Request-Response receive port.
3. Add a new receive location and set the Transport type to WCF-Custom.
   
   
   
4. Configure the WCF-Custom adapter.
5. Set the EndPoint Address to:
   
           sb://servicebus.windows.net/services/[your solution name]/EchoService/
   
6. Set the Binding Type to NetTcpRelayBinding
   Note: This is one of the new bindings added when you installed the Microsoft .NET Services SDK
   
   
   
7. On the Behaviors tab, add a new behavior extension called transportClientEndpointBehavior to the EndPointBehavior node.
8. Set the credentialType to UserNamePassword and enter your solution credentials on the UserNamePassword element of the ClientCredentials node.
   Note: If you are using Windows CardSpace instead, set the transportClientEndpointBehavior to use it here instead.
   
   
   
9. Click Apply and verify no errors occurred with your WCF-Custom adapter configuration.
10. Click OK to close the Adapter configuration dialog.
11. Set the Receive Handler to your BizTalk Server Application host.
12. Leave the Receive and Send piplines as PassThru (as we are not requiring xml parsing of the messages we are sending and receiving).
13. Click OK to save the new receive location.
14. Do likewise for the receive port.
15. Now, configure your orchestration bindings and start the BizTalk application.

Verify the Service is Exposed to the Cloud

In this step we will browse to your Microsoft .NET Services service registry feed and verify your service is exposed to the cloud.

1. Launch Internet Explorer and browse to the following URL:
   
        http://servicebus.windows.net/services/[your solution name]/
   
2. You should now see your service endpoint listed in the Atom feed.

Test Your Solution

1. In Windows Explorer, navigate to the samples folder under the install folder for Microsoft .NET Services SDK
   Note: If you installed to the default folder it should be C:\Program Files\Microsoft .NET Services (Nov 2008 CTP) SDK\Samples
2. Locate the ServiceBus\GettingStarted\Echo sample and open your flavour of choice (C#/VB)
3. Build the Solution using VS 2008
4. Run the Client.exe
5. Enter your Solution name and password.
6. Enter some text to send to your service.
7. Verify the service response includes BizTalk: <your echo text>
   
   

What did we just do?

Using only the new WCF features that were installed in the Microsoft .NET Services SDK we were able to configure a request-response receive port in BizTalk that exposed our orchestration to the cloud. This is very cool .

At the very least, we could do away with the orchestration binding and just configure the receive port to drop messages into the BizTalk MsgBox. We then use content based routing to route the messages off to our existing orchestrations.

Think of the times you wanted to expose your BizTalk services to customers and clients outside your organisation, but had to jump all those hurdles the IT infrastructure team seams to magically come up with.

This is just the beginning...