Logjam Worsens

Last week, I wrote about the college football logjam. While we’ve seen one team fall out of the running, the overall race for the #2 slot has tightened significantly. Last week, Auburn and USC held a small yet significant advantage in the voting over West Virginia, Florida and Michigan. This week, that margin is gone. Auburn’s loss combined with SC’s wholly unimpressive win (spoken as an SC alumni) over the Huskies and Florida’s impressive win over #9 LSU creates essentially a four way tie for second place. Only 100 votes separate #2 from #5 in both the AP and USA Today polls.

There are also a few other undefeated teams in the top 25: #7 Louisville, #19 Missouri, #20 Boise State and #24 Rutgers. Baring significant upheaval in the polls, only Louisville really has a shot to join the group at the top. They play West Virginia in a few weeks, so the winner of that game will likely stay in the hunt for the BCS title game. And Ohio State still plays Michigan at the end of the season, so we’re still looking at a maximum of four unbeaten teams.

As bad as this scenario is, it’s even worse to consider what happens if all these unbeaten teams lose. Currently, Texas, Tennessee, Notre Dame, California, and Auburn are all essentially out of the hunt. As long as there are at least two unbeaten teams, really none of these teams can legitimately argue that they deserve a shot at the title. But you can bet that ranked one-loss teams will be highly-motivated to beat ranked no-loss teams in order to be able to make a case for inclusion in the title game. USC plays #18 Oregon State, #10 Cal and #9 Notre Dame. Florida plays at Auburn and Georgia. Michigan plays Iowa (not to mention #1 ranked Ohio State).

If I was a betting man, instead of an Trojan fan, I would bet the BCS title game would be between West Virginia and the winner of the Ohio State / Michigan game. Obviously, if SC plays Notre Dame the way they played against Washington, they’ll lose. But SC will be amped to the max for Notre Dame, so I would be more concerned about SC looking past Oregon State or Cal the way they obviously didn’t take Washington seriously. By the same reasoning, I figure Auburn has a better-than-decent chance of beating Florida next week. If SC and Florida lose, that leaves three unbeaten teams, two of which play each other. Hence my prediction.

Of course, I’m not a betting man, so I’m hoping to see the winner of Ohio State and Michigan play USC for the championship. Note I wrote “hoping” which is code for “that’s only going to happen if they play better than they did the past two weeks”.

Cool Toy From the Teacher

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.

Things I Didn’t Realize About WF

  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?

  1. 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.

Hawkeye on Standard WCF Bindings

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?