In a (not so recent) post, I walked through the steps to get your BizTalk Server 2006 R2+ Orchestrations exposed to the Cloud. See Exposing BizTalk Orchestrations to the Cloud. With the release of the Microsoft .NET Services SDK (March 2009 CTP) this week, you will find your existing .NET Services endpoints no longer valid.

Here's how to resolve the issue.

At the moment your existing .NET Services endpoints are in the form:

sb://servicebus.windows.net/services/[solution name]/[service name]/

This has now been changed to:

sb://[solution name].servicebus.windows.net/[service name]/

Note: you can still register your service hierarchy as before (e.g. sb://.../[service group]/[service name]) but for simplicity I have just used [service name] in the URI's above.

So, even if you followed Microsoft's advise and coded your service endpoints URI's this way:

Uri address = new Uri(String.Format("sb://{0}/services/{1}/{2}", ServiceBusEnvironment.DefaultRelayHostName, solutionName, serviceName));

that didn't get you out of trouble when the URI change was released. We are now encouraged to use the following when generating endpoint addresses in code:

Uri address = ServiceBusEnvironment.CreateServiceUri("sb", solutionName, serviceName);

This will give us an address in the new structure and protect us from any future changes (but we heard that somewhere before didn't we). Also, be aware that (as of time of posting) the published services feed is not listing your services correctly (but they are still accessible). Your new published services feed will also be:

http://[solution name].servicebus.windows.net/

In the coming days, the team at Breeze will be walking through the new goodies the March CTP brings so look out for future posts (of particular interest is the queuing and routing features we have now!).

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:
   

Add the following shapes to the design surface

            // 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;

Wire up the port operations and don't forget to set the Activate property of the Receive shape

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...