As I wrote this morning, I’m in training this week. The instructor (who I wrote earlier is “pretty good”) is Jon Flanders. I didn’t recognize his name, but I did recognize his Atlas based WF Designer that he released a month and a half ago or so. It’s a cool piece of work so it’s doubly cool (for me anyway) that he’s teaching this class.

1. You can customize how you load workflows. My favorite part of Customizing the Microsoft® .NET Framework Common Language Runtime is custom loading assemblies from a structured storage file. In WF, you can load workflows by type or from XAML. Of course, these the XAML – or even the types – can be loaded from anywhere, or even generated on the fly. If you need more control, you can swap out the default workflow loader service with one of your own creation.

2. You can swap out the default workflow scheduler. How about a scheduler based on the Concurrency and Coordination Runtime (CCR)?

Side note – How about a official home page for CCR? And while I’m asking, how about a download for CCR separate from MS Robotics Studio?

3. You can add any object to the workflow runtime as a service. You’re not limited the services the WF runtime knows about. Of course, WF won’t use your service, but you can build activities that use it. This is likely to be huge for getting data in and out of the workflow instance.

I’m in WF/WCF training this week, so any daytime blogging will be on breaks and at lunch. So far, the instructor is pretty good, though we’ve only covered “intro to WCF” so far. Given the amount of content he’s laid out, I wonder how were going to get through it all.

The instructor said something interesting as he was going over the bindings that come “out of the box” with WCF. He commented that these bindings were the ones the WCF developers thought would be used most often. Of course, he doesn’t speak for the WCF team, but it does make some kind of sense. You can extend WCF to support any potential binding, but it makes sense the WCF team would want to enable the common cases without having to write much code.

So take a look at the list of nine standard bindings. Given that WCF is about unifying the windows stack for distributed computing, most of the bindings are at least conceptually similar or in some cases leverage previous distributed paradigms and technologies. You have two HTTP based bindings (with and without WS-* extensions) which are analogous to ASMX and WSE. There’s a TCP binding which is comparable to .NET remoting. And there are two MSMQ bindings (with and without SOAP support) for those needing to interop with existing MSMQ systems or who need durable messaging.

That leaves four “new” standard bindings. These are interesting as they don’t herald back to previous technologies and paradigms of distributed computing (at least on the Windows platform) but still the WCF team thought enough of the scenarios they enable to include them in the box with WCF. For example, I the wsFederationHttpBinding is designed to take advantage of the significant investment they’ve made in federated identity. Several years ago, Don Box talked about shrinking the service metaphor rather than stretching the object metaphor across the network. NetNamedPipesBinding is an obvious implementation of that vision. And wsDualHttpBinding is a way to take advantage of the WCF’s duplex channel shape while still using HTTP as your transport.

Finally, there’s netPeerTCPBinding. From where I sit, this is a radical addition to an otherwise standard set of bindings. Now don’t get me wrong, I’m glad it’s there. But I’m guessing developers who look at it are more likely to think along the lines of “Wow, what can I do with this?” rather than “Yes, I expected that to be there.” Certainly, that was my thought process.

Anyone got any cool uses for netPeerTCPBinding?

The 06-07 NHL season finally starts tonight. This offseason feels longer than most, probably because I’ve been more involved with hockey this past offseason. But the opening night rosters are set and the Sabres and Hurricanes face off in just over five hours. Here are a few quick thoughts:

• NHL.com has gotten a make over. I don’t know who their designer is, but somewhat should clue them into “less is more”.
• There’s a new beta service called NHL Connect. Looks like forums and blogs and profiles right on NHL.com. Looks cool, but currently it’s invite only. I would hope it would open up soon. Nice to see Caps fans representing – the Washington Capitals Official Group is tied with the Kings for most number of members (so far).
• Via Off Wing Opinion I found this article by Dave Fay about the NHL’s point system. His recommendation: “winning a game in regulation should be worth three points, winning in overtime should be worth two, winning in a shootout should be worth one. Losing at any time should be what the reward has always been for losing — zero.” I could live with that. I’m also cool with two points for a win and none for a loss, regardless if it goes to overtime or shootout. I’d even be OK (but not elated) with three for a win in regulation, two for a win in overtime or shootout and one for a loss in overtime or shootout. But the idea that you had out more total points for an overtime game than a non overtime game is just stupid.

Udi emailed me over the weekend to let me know that he had issues leaving a comment on one of my posts. If you’ve had any issues commenting here on DevHawk, please drop me a line and let me know.

Thanks!