November 6, 2008
@ 12:34 AM

n594054186_1603464_4419 n594054186_1603471_6712 n594054186_1603470_6391

Now that I’m blogging again I thought it’d be time for a little update.

Categories:

[Update 2010-08-25: Wade Wegner now shows a solution on his blog]

We’ve been getting some questions along the lines of “I am hosting a service as xyz.svc in IIS and have changed the config to use on of the Service Bus bindings, but the service never gets called?”

That’s right. It doesn’t. The reason for that is that we don’t yet have WAS/IIS integration for any of the Service Bus bindings in the November 2008 CTP. Enabling the WCF WAS activation scenario that puts the NetTcpRelayBinding and friends on par with their WCF siblings is on our work backlog for the next major milestone.

It’s worth considering for a moment what that integration requires. Fundamentally, all of the Relay bindings replace the local TCP or HTTP listener with a listener that sits up in the cloud and services then connect up to that listener to create an inbound route for received messages. That’s similar to how local services interact with WCF’s shared TCP listener or HTTP.SYS, but there are quite a few important differences. First, all Relay listeners need to acquire and present an Access Control token when they start listening on the Service Bus. In contrast, the local listener facilities are ACL’d using the local or domain account system and use the Windows process identity to decide on whether a process may or may not listen on a particular port and/or namespace. Second, since the actual listener is off-machine, we need to spin up the connection as the IIS/WAS host spins up and need to make sure that the connection is kept alive and aggressively reconnects when dropped for any reason. That’s something you don’t really have to worry much about when the listener sits right there on the same machine as your own service and the connection is a named pipe. Third, the local listeners listen on a particular host address and port; the Relay listeners listen on a leaf of a namespace tree and that namespace may be shared amongst many listeners living on a multitude of different machines in different locations.  Fourth,   ... well you get the picture.

Bottom line: Not having support for WAS activation and xyz.svc service endpoints is by no means an oversight. It’s on the list.

Categories: .NET Services | Azure

The MSDN Developer Center for .NET Services is the first stop to go to for technical information on the Service Bus, the Access Control Service and the Workflow Service.

There quite a bit of documentation for “my” feature area, the .NET Service Bus, including description of all the bindings and most of the object model surface area. Since we had quite a bit of object model churn up until a few weeks before PDC as we’ve exploded the former, singular RelayBinding into two handful of WCF-aligned bindings, the reference documentation isn’t yet in the familiar MSDN reference format and also doesn’t yet work with Visual Studio’s “F1”. We’re obviously going to address that in the next major milestone now that the dust is settling a bit and the programming model is already quite a bit closer to what we want it to be for our “V1” release.

Categories: .NET Services | Azure

In the sea of PDC 2008 announcements you may have missed the following two signficant developments:

For the past 2 months our team has worked very closely with our partners at Schakra on the Java SDK parts and with ThoughtWorks on the Ruby parts. These are the first baby steps and these two SDKs cover only a small subset of the capabilities of the .NET SDK so far. That's merely a function of when we started with these projects and how far we've gotten with the required protocol support; we want and we will take this a lot further over the next development milestones. In the end, the .NET Services fabric ought not to care much what language the senders and listeners are written in and what platform they run on. We're building a universal services platform. We're taking Java and Ruby very seriously and have a few more platforms on the list for which we want to add explicit support.

Categories: PDC 08 | Azure | .NET Services

If you want to try out Windows Azure, or .NET Services, or SQL Services, you need an access code. How do you get one? By signing up here.

"Yes, I did that, but I didn't get a code, yet!"

We're onboarding new accounts slowly but steadily so that we do a controlled scale ramp-up. PDC attendees (having signed up with the same LiveID that they used to register for PDC) will be getting their access codes first, everyone else will be getting their access codes after that. We're a bit conservative with the onboarding waves and closely monitor the overall utilization once we allow a new wave in. So if you attended PDC and don't have a code it may still take a few days for us to give you one depending on when you signed up. If you didn't attend PDC we're going to try giving you codes as excess capacity permits.

Categories: PDC 08

November 1, 2008
@ 05:12 PM

Our team's PDC talks are online on Channel 9:

 

 

Categories: PDC 08