.NET Services March 2009 CTP - “Milestone 5”

Our deployment team reports that they’re done with the last touches on our new release, that the servers are happily humming with the new bits, and that the new SDK is posted.

The .NET Services Developer Center has been updated as well. You can get the SDK bits from here [1].  We also have a runtime-only redistributable package that sits here [2].

What changed? Quite a bit. I’ll be updating you about the concrete changes in the .NET Service Bus beyond what we’ve got in the docs here on my blog over the next few days and also go into detail on some of the design considerations for the newly added functionality and the service APIs, specifically also on the significantly expanded REST capabilities.

People who’ve been following .NET Services or even BizTalk Services for a while will immediately notice that we’ve introduced a number of breaking changes in this release and that your existing applications will require some changes. The most important change we’ve made across the services and .NET Service Bus in particular is that we’re now giving every project a clean “root” URI:

• Before the March CTP, the “root” of your namespace resided at: http://servicebus.windows.net/services/project-name/
• With the March CTP, we’ve moved the project-name into the DNS name and drop the ‘services’ segment: http://project-name.servicebus.windows.net/

With that, we’re giving you complete control over your Service Bus namespace and we’re making every effort to leave you in the driver’s seat on the namespace design and to avoid hijacking URIs for “magic” functionality. What that means – and I will elaborate on that topic be showing you some code in the next few days – is that you can now do things like putting virtual robots.txt or Silverlight ClientAccessPolicy.xml or Flash crossdomain.xml endpoints at the root, enabling cross-domain scripting against relayed HTTP services.

The good news is that we’ve made no visible changes to the WCF bindings for the .NET Service Bus that we talked about at PDC. We’ve improved some of them in significant ways under the hood, but we didn’t touch the API surface in any way you ought to notice in your apps. A very important set of bug fixes that went in in that area is that we’re now respecting all size quotas and timeouts you set on the bindings. We didn’t really do a good job there in previous releases. When you ask for a 10 second “open” timeout for a binding that’ll actually be effective now. Before you were stuck with a minute no matter what you set the values to.

The “flagship” WCF binding of the .NET Service Bus, the NetTcpRelayBinding got the most attention. The binding knows how to do a particularly awesome networking stunt when you set the ConnectionMode=TcpConnectionMode.Hybrid. It will attempt (and mostly succeed) snapping a direct socket between two parties even through both parties may be hidden behind opposing firewalls and NATs. As we’ve been analyzing some bugs in this latest milestone we’ve found that the established connections were only working well for one-way communication, but not for full-duplex or even request-reply conversations. We’ve fixed that. What we’ve also added is a status indicator by which you can tell whether the connection is in “relayed” mode or whether it has been upgraded to “direct” mode. The new mechanism is shown in the Direct Connect sample, but I’ll quote that here for you as I go through the features in more detail.

A commonly seen customer issue is that quite a few people don’t have any leverage to get the outbound TCP ports that we require for outbound communication opened on an upstream firewall (remember: no inbound open firewall ports required; you can stay stealthy). We’ve started to address this across all our bindings so that the .NET Service Bus client and listener endpoints are a bit more aggressive in trying to get out to the .NET Service Bus. That particular feature is in the bits, is enabled by default and we expect (hope) that people who are trying to connect from within tightly managed network environments with outbound port restrictions will see things “just work”. We’re eager to find out whether people who’ve been reporting DNS resolution errors for servicebus.windows.net or nothing but obscure 1-minute timeout failures are finding that things have improved for them – albeit connections may not be as snappy as without such port restrictions in place. 

Absolutely new in this release are a set of composable communication primitives that I’ve talked about and demoed at MIX: Queues and Routers. There’s a whole lot of philosophy behind the way those primitives are designed, what those primitives indicate about where we’re going with the .NET Service Bus, how they integrate into the namespace, and there’s a lot to say on how you can interact with them and compose them and therefore I’ll talk about the namespace as well as Queues and Routers in detail and in a few separate posts starting later today.

[1] http://www.microsoft.com/downloads/details.aspx?FamilyID=8d1d1d5e-1332-4186-b33f-26d053759e49&displaylang=en
[2] http://www.microsoft.com/downloads/details.aspx?FamilyID=4eff38b3-fca0-4940-a014-461631152e5d&displaylang=en