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?

There’s a new version of WL Writer, so I spent a little time updating my Gamer Card Writer Plugin. The big addition in this version is support for the different card styles from MyGamerCard.net. Also, I added a preview, so you can see what the card will look like before you insert it into your post.

Rather than post it here, I submitted it to the Windows Live Gallery, since they’ve added an area for Writer Plugins. You can download it from there.

Seven months and one job ago, I wrote this about AJAX toolkits:

The network effect that Dion doesn’t consider is the component ecosystem phenomenon that Microsoft has a ton of experience with. Old school VB, COM/ActiveX and .NET have all had large ecosystems of components and controls evolve that extend the functionality of the baseline development platform. There’s no reason to believe that won’t happen with Atlas. I think it’s wrong to describe Atlas as a monolith or self-contained or enclosing. It’s an extensible baseline platform – i.e. the baseline functionality is set down once at the development platform and the ecosystem can extend it from there. Sure, overlapping extensions happen (how many rich text editor components are there for ASP.NET?) but at least they all have basic compatibility.

I bring this up now because I saw on Shawn Burke’s blog that they’ve shipped the September release of the Atlas Control Toolkit. There are now 25 different controls (they had 10 in their first release). But there’s something more significant than the addition of 15 controls overall:

Slider is just a super-useful little control.  There are so many times when you want to let users use this type of UI.  Another great thing about Slider is that it’s a 3rd party contribution, from Garbin, who did a great job on it. (emphasis added)
[Atlas Control Toolkit September Release]

I just wanted to brag that I called this 7 months ago.