As I wrote the other day, I’ve been investigating the Web Service Software Factory. The WSSF includes four guidance packages: Data Access, ASMX, WCF and WCF Security. The Data Access isn’t service specific (I’m guessing it’s also included in p&p’s other factories) so I didn’t focus on it much. I also didn’t investigate the ASMX package at all.

For the WCF and WCF Security packages, I walked through the tutorial in the documentation. The tutorial contains the usual WCF suspects such as creating a data contract, creating a service contract and implementing a service contract. While you can do these things manually, the WSSF provides wizards for most if not all these operations. This seems like overkill for some of these operations. For example, filling out the grid of data contract members was more cumbersome (for me) then just typing the values in the code file.

Also on the subject of somewhat more complex than necessary, WSSF provides wizards for building type translators. This is pretty standard stuff: given an instance of a given type, the translator returns an instance of a different type. Again, I find it faster to write the code for this directly than to individually select the matching fields in the wizard UI. Somewhere on the complexity scale between CRUD stored procedures and service data contracts is the tipping point where it’s faster and easier to just write the code than it is to manipulate the wizard UI which generates the code.

On the plus side, the WSSF includes snippets which are very convenient to use. For example, WSSF includes the WCFDataMember snippet (short name: wcfDM). It’s a lot like the standard prop snippet, but with the automatic addition of the DataMember attribute.

I had much more success with the main WCF package than I did with the WCF Security package. I wasn’t interested in the anonymous or direct authentication mechanisms, which left only two security recipes that I cared about: kerberos and x.509 certificates. Unfortunately, I couldn’t make either of these tutorials work. For kerberos, the baseline configuration works (i.e. standard wsHttpBinding with no additional configuration), but after running the “Secure a Service Using Kerberos” recipe, I get an exception that “The token provider cannot get tokens for target”. It wasn’t in me to debug the sample to figure out what that meant. For x.509 certificates, I can’t even complete the wizard – I click OK in the certificate selection dialog, but the wizard doesn’t get updated and won’t let me continue.

I really dig the new Guidance Navigator window, especially the history window, but I do have one problem with it. Is there a way to mark a recipe so it doesn’t show up in the history view? The WSSF includes some recipes like “View Service in Browser” and “Run Client” that don’t change the project state and quickly clutter up the history view. It would be great if they didn’t show up there in the first place.

I’m guessing the WSSF is designed primarily new WCF developers, so I’m not exactly in the target demographic. Many of my issues above stem from my deeper than average experience with it (though nowhere near the depth of experience some members of the community have already). But it’s a good start and I’m sure it will get better with successive releases.

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.

Took part of the morning off this morning to let the sun shine down on the icy roads. No major incidents getting to work, though the office parking lot is like an ice rink.

• As mentioned yesterday, I finally got my STS implementation working with WCS. Turns out that using WCS with the wsFederatedHttp binding requires you to specify which claims you want to send to the service. In comparison, using WCS with wsHttpBinding automatically requests the PPID claim. It would be nice if this was documented somewhere. I only figured it out by finding this demo from Michele.
• Last week, I said that we need a better tool than SvcConfigEditor. This tool is only marginally better than hand-editing the config files with intellisense. A “real” tool would keep you from building invalid config files. While I appreciate the need for this level of flexibility at the transport layer, we really need a better web service hosting story than IIS + ASP.NET + web.config. WCF makes me long for the days of the MTS/COM+ GUI interface. I never wasted hours troubleshooting config issues with MTS/COM+.
• Apparently, Xbox 360 outsold Wii and PS3 combined in December. That’s probably more of a statement about PS3 and Wii shortages, but there’s no arguing with numbers like 10.4 million Xbox 360 consoles, 5 millions Xbox Live users, and nearly 3 million copies of Gears of War. Congrats to the Xbox team!
• David may be hiding from his blog of late, but he did venture out long enough to point me to SOA Facts. My favorite: Dante has a special level in hell for consultants whose resumes do not say SOA.

The news got the amount of snow right, but the day wrong. Instead of hitting yesterday morning, the storm hit yesterday at rush hour. My boss declaired today “1st Annual Architect work from home day” even though we’ve already had several weather induced work from home days this winter.

• Growing up in Northern VA, when we got snow it was fairly consistent. If there was about four inches at my house, everyone had about four inches. Here, it seems like there’s much more variance. My teammate Buzz who lives only 15 minutes from me (when it’s not snowing) said he had 10″ of snow while I have about half that.
• Speaking of Northern VA, the last few winters have been easy on us but hard on my parents who still live in McLean. This year seems to be the opposite. The forcast for McLean today is only 45, but it’s supposed to get up to 65 by the weekend.
• As it turns out, my parents are in the Bahamas right now anyway, so while I make a snowman with my kids today, they’re probably on the beach!
• I almost didn’t make it home yesterday as I was trying to get my STS working with CardSpace. I have WCS workng in a direct client to service scenario, but not federated with an STS. I probably would have stayed there all night saying “just one more config tweak, and I’m sure it will work” if I had gotten snowed in.
• Speaking of WCS, check out Kevin’s screencast on extending ASP.NET’s built in SQL membership provider to support WCS. And Garrett published a WCS security token processor for .NET 1.1 and 2.0 a couple of months ago. So you can use WCS on your website, even if you don’t have .NET 3.0 on your server. Pretty cool.
• My old teammate John doesn’t like the JBOWS acronym. I agree with John that defining a “proper” SOA is waste of time best left to SOAholes. But web services != SOA. Making a distinction between having an architecture where the business and IT levels that rely on independent capabilities and services versus using web services as the protocol between tiers of a distributed application and hoping that you’ll be able to integrate in the future makes sense to me.

Recurring 8am Friday meetings are not my style.

• I’ve been tracking WCF for a long time. Yet, it’s still a dauntingly large topic. Yesterday I spoke to a friend who works in Windows Live who is just beginning to learn about WCF and it’s literally overwhelming him. His reaction reminded me of my early reactions to COM. It feels like no matter how much you learn about WCF, the “pile” of stuff still to learn doesn’t shrink. In contrast, while my initial exposure to the .NET Framework was overwhelming, eventually I got to the point where I felt like I had a good handle on what was in there.
• With all the configuration settings in WCF, the number of valid combinations is astronomical. While WCF’s configuration based approach is arguably more flexible than a code based approach, it’s also more complex and harder to debug in my experience. Config debugging seems to be an endless cycle of tweaking the config file and running the app to see what the effect is. We need better tools than SvcConfigEditor.
• Responding to yesterday’s Morning Coffee, Jon Flanders confirmed via email that the built-in SQL WF persistence service “doesn’t recover from faults to the last good persistence point” and that “when a fault happens, the instance closes and…is removed from the persistence database.” Is this the right behavior? I’m thinking it depends on the workflow. More on this later.
• I’m trying to get my teammates to start using the Beyond Bullet Points approach to the various presentations we build as a team. Interestingly enough, it’s been easier to get my team to adopt an agile development methodology than to adopt the Beyond Bullet Point presentation methodology. I would have expected the opposite.
• The Caps trounced the Canadiens last night, ending a five game losing streak. I’m not that worried about the losing streak – the Caps have had several players out with the flu. But beating Montreal, who came into the game twelve games above .500, so badly is a good sign. And how about Nycholat? Two goals and four assists in seven games since he was called up from Hershey. Even more impressive, he’s +2 even though the Caps were 2-5 and outscored 24-18 in those seven games while averaging nearly 21 minutes of ice time per game. Here’s hoping Nycholat stays hot.