Morning Coffee 10

Wow, I made it to ten of these morning coffee posts. That puts me only two orders of magnitude behind Mike and one order of magnitude behind Sam.

  • We got snow, again. My son apparently said the other day “OK God, that’s enough snow now”. When a 3 year old is tired of snow, you know you’ve gotten a lot.
  • Of course, people in snowier climates than here (the NorthEast, Northen Midwest, pretty much all of Canada, etc) will snicker that 5 inches of snow is “a lot”.
  • I’m moving my STS code into a new VPC for handoff to the dev team. I was running Virtual Server before, but for individual work like what I do, Virtual PC is much easier to use. Drag and Drop into the VPC alone is worth it to me to use Virtual PC instead of Virtual Server. I am using the beta of Virual PC 2007, though I couldn’t tell you what the differences are.
  • Steven King may love the new season of 24, but I can’t shake the feeling of jumped shark. However, I am impressed that Fox released the first 4 episodes of the new season today.
  • Two name changes later, the RTM version of SQL MobileAnywhere Compact Edition is now available. BTW, I found this blog post by Steve Lasker about using SQLce with ASP.NET. So it sounds doable, though not recommend. Of course, for those of us using shared hosting, SQLce is a non-starter until it becomes part of the standard .NET framework install.

Mastering WCF

Sam Gentile writes:

Harry finds Indigo daunting. Me, I find mastering 8 different stacks (COM+/ES, ASMX, WSE, Remoting, MSMQ, etc) to do the same thing and all the strange nuances a hell of a lot more daunting but that’s just me, although the number of timeout settings and config settings is astronomical.

While mastering many different stacks is daunting, the reality is you don’t have to master all of them to use one of them. Knowing Sam, he probably has mastered all the different stacks, but MVP’s like Sam are an edge case. Most developer don’t master any of the stacks, they get comfortable with the one or two stacks they use all the time.

From that perspective, WCF replaces the “legacy” stack a given developer understands with something much more complex, since WCF replaces legacy stacks other than the one said developer is familiar with. Options like message exchange patterns and network protocol were typically implicit to a given technology stack. For example, if you used ASMX, you could use any network protocol you want, as long as it’s HTTP. Using WCF, you get to / have to choose which network protocol you want to use. Multiply that decision making process by the “astronomical” number of choices WCF provides, and you’ve got to spend a long time making decisions that the “legacy” stacks handled for you automatically.

To me, it looks like WCF’s primary design goals were to support web service standards (aka WS-*) as well as to unify the disparate communications stacks. And I think WCF was fairly successful at these two goals. Previously, the capabilities you needed would drive your communication stack choice. Need web service interop? Use ASMX. Need low-level control over the message pipeline? Use .NET Remoting. Need to flow transactions? Use COM+. Need to flow transactions over web services with low-level control over the message pipeline? Until WCF came along, you were SOL.

However, if “ease of development” was a goal for WCF, it doesn’t look like it was high on the list. And frankly, that’s fine. As I’ve written before, I’d rather have a flexible if complicated low-level foundation to build higher-abstracted application infrastrucutre on top of.

Just don’t try and sell me that WCF is making my life easier, because it’s not. Not yet, anyway.