Build castles in the Cloud with the new drop of the BizTalk Services SDK

Article
06/14/2007

Yesterday night I was going through the unresolved parts of the inbox, a fairly boring task, when Dennis rescued me: he chimed in via Messenger reminding me that a new version of the BizTalk Services SDK is out. It wasn't hard to switch my attention to something far more exciting, and I promptly installed it. If you had the old version of the SDK on your machine, I suggest uninstalling it before installing the new one. For the ones that were bold enough to play with the new binding at low level: the changes in the machine.config show how the assembly hierarchy and the object model changed:

<!-- <system.serviceModel>

</relayBinding>

</bindings>

<endpoint address="" binding="relayBinding" bindingConfiguration="metadataExchangeRelayBinding"

contract="IMetadataExchange" name="net.relay" />

</policyImporters>

</wsdlImporters>

</metadata>

</client>

</behaviorExtensions>

</bindingElementExtensions>

</bindingExtensions>

</extensions>

</system.serviceModel>-->

<system.serviceModel>

</relayBinding>

</bindings>

<endpoint address="" binding="relayBinding" bindingConfiguration="metadataExchangeRelayBinding"

contract="IMetadataExchange" name="sb" />

</policyImporters>

</wsdlImporters>

</metadata>

</client>

</behaviorExtensions>

</bindingElementExtensions>

</bindingExtensions>

</extensions>

</system.serviceModel>

That defines the heart of the SDK, the relay binding. As you can see, the main difference is in the assembly name(space): from the old Microsoft.ServiceModel.Relay to the new System.ServiceBus.

I am sure that Dennis himself and Justin will cover things in much better detail. Here let me just tell you that the new drop supports username and password as authentication method: while you know my position about shared secrets in general, here we gain the huge advantage of being able to connect to the ISB (Internet Service Bus) in unattended mode. In the former version of the SDK, every time you wanted to register an endpoint on the ISB you were prompted by the Identity Selector: while this is perfectly reasonable (actually, suggested) when the application is inherently interactive, you can see how this could have been a problem for a service. Being a service unattended, there would be nobody to deal with the CardSpace prompt in the event of a drop&reconnect scenario. With passwords you now can, always making sure you follow the proper practices for storing them, guarantee that at restart your service will be able to re-register with the ISB without explicit human maintenance.

An example usage of the new password feature is shown below: the screenshot is taken by a test run for the Multicast sample, and depicts a pretty solipsistic chat session (both instances are registered with the ISB with my user).

Let me tell you, the multicast sample is pretty amazing! The session above is very non-representative, the real awe is when you see clients running on the most different machines, happily talking to each other irrespective of the walls between them. In fact, I think we should organize a MultiCast sample online party in which we agree on a time and a chatroom name and we all jump in. How do you like it? If you're up to it leave a comment or use the blog contact form :-)

I should not forget to mention that the new SDK introduces a super easy way of exposing services for consumption from a browser, in glamorous webby fashion, and that we are now compatible with Orcas (the framework 3.5).

So go ahead, build castles in the cloud! In this era, the phrase has an entirely new meaning :-)

Build castles in the Cloud with the new drop of the BizTalk Services SDK

Additional resources