Lunchtime Coffee 153

• p&p have published new versions of both the Web Service and Web Client Software Factories. Beyond support for VS08, I'm not sure what's new but that's worth the price of download (admittedly close to zero) right there. I assume these need the most recent release of the Guidance Automation Toolkit as well.
• W3C has published a new working draft of the Service Modeling Language. I'm really interested to see where this technology goes.
• Yesterday, Microsoft announced the Silverlight Blueprint for Sharepoint, part of a larger Software + Services Blueprints initiative that I wasn't aware of. According to Michael Lehman (who's blog I've been been remiss to read of late), S+S Blueprints has a bunch of other interesting projects including Video.Show and Outlook+Services.
• Martian Maly demonstrates how you can use DLR trees to build a statically typed add function. Literally, my very first thought after Martin presented DLR Trees @ Lang.NET was "I wonder if you could use that for static languages too?" I guess the answer is yes.
• It's been six months, and Scott Hanselman still isn't evil. Perhaps he could start turn his ASP.NET wiki into an evil ASP.NET wiki? Actually, I'm only linking to his post because I liked the way he described blogging as "I'm writing a book that will never end".

Is Guidance Automation Too Complex?

Over the past couple of weeks, I've gotten a chance to spend time investigating the Guidance Automation Toolkit. For those who aren't familiar with GAT, it is the underlying enabling technology that powers p&p's Software Factories. Several of p&p's factories include data access guidance, but that works against an actual database rather than a VSTDB project. Given my newfound love for VSTDB + my interest in GAT, I thought I would whip up some simple automated guidance.

The key word in that last sentence is "thought". Turns out that authoring guidance in GAT is extremely unfriendly. GAT's unit of automation is called a recipe, which consists of arguments, wizards and actions. Arguments are GAT's equivalent of variables, wizards gather argument data from the user and actions execute changes to the solution based on the values of the arguments. There's more granularity to the GAT authoring model - for example, GAT arguments have optionally have value providers and converters (which should be called validators) - but you get the basic idea.

What makes GAT so hard is that all these recipe elements are wholly independent. This makes individual recipe elements easy to write and recipes fairly modular, but at the cost of making recipe very difficult to write. Your recipe has to define both the list of these elements that it uses as well as their interconnections. For example, arguments optionally contain value providers and converters. They are exposed to the user in wizards as either custom pages or arguments. They are fed into actions as input parameters. Action input parameters can also come from the output parameters of other actions. All these interconnections have to be hand coded in XML with fully specified type names like "Microsoft.Practices.RecipeFramework.VisualStudio.Library.Templates.TextTemplateAction, Microsoft.Practices.RecipeFramework.VisualStudio.Library". Ugh.

The good news for GAT is that help is on the way. Clarius' Software Factories Toolkit includes a graphical domain specific language for authoring recipes. With that tool, you can pick the various recipe elements from a list and connect them graphically instead of hand coding all of that in XML. But why do we have this problem in the first place? How much are we gaining by using this XML format in the first place? Frankly, I don't think very much. I think it would make more sense to define recipes in code than XML.

I was talking to Michael Lehman about Project Glidepath, which is built on GAT. However, Glidepath only uses GAT for integration with Visual Studio's menu system (which seems much more difficult than it needs to be, but that's a separate post). Instead of GAT's recipe system, Glidepath plugins simply expose an Execute() method. Within that method, the plugin can do whatever it wants. Michael showed me the code behind the Vista Bridge package, and it is MUCH simpler than the GAT equivalent. I could see having a little more structure than just Execute(), but GAT seems like overkill in comparison.

Sometimes complexity is necessary. But I can't help but think that GAT's complexity wasn't really necessary. Wouldn't it have been simpler and just as modular to define a recipe in code instead?

Morning Doughnuts 5

• Joel Dehlin, a former Microsoft employee and the CIO of the LDS church is conducting a series of tech talks. The next one is being planned for the bay area. If you are interested you can respond to his post here. The dates would be between April 22 - 26 with a tentative agenda as follows:
• Keynote
• Infrastructure breakout
• Development breakout
• Interaction Design breakout
• Community breakout
• Building to building video breakout
• Everything needs a 12 step program now. CNN has a 12 step program to cure your email addiction here. I started thinking about this after Harry's post saying he had hit zero email bounce prior to going on his secret mission.
• I read an interesting blog on XNA and how it fits into Microsoft's strategy in gaming. I am not sure I agree with all of the points, but I found the arguments to be compelling.
• My BYU Cougars are now up to 21 in the AP Poll. I can't think of a year when both the football and basketball teams have both had such successful seasons.
• Between today and tomorrow I will be finalizing my vision document for how I think monitoring should work in the Service-Oriented Infrastructure project I am on. As I was outlining my vision it really hit me how much there is to do.

Morning Doughnuts 2

• Joel Dehlin, the CIO of the LDS church has an interesting blog entry on buy versus build this morning. His main point is that buying is often cheaper, but only if you can move your business processes to match the processes in the off-the-shelf software.
• The search for Jim Gray by his friends and colleagues has been called off. Even with a massive high-tech effort no new clues have been turned up. For the sake of his family I do hope that the mystery is solved. I would imagine it is very hard to not know what happened to him.
• I am currently running a Build and Deployment Task Force. We are trying to ensure that our team follows best practices when building new applications. The project that Harry and I are working on seems to be a good test bed for the process.
• For those of you who read my blog you know I am passionate about how we implement Service-Oriented Architecture in the real world. I have been reading a book titled Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology. I find the description of real business objections, and how to solve them quite refreshing.
• It appears that the San Diego Chargers are going to hire Norv Turner to replace Marty Schottenheimer as their head coach. I don't see how fans of the Chargers can possibly see this as an improvement.

Hawkeye on Web Service Software Factory

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.

Real World GAT - NUnit Converter

Jim Newkirk has released an alpha version of a utility to convert NUnit tests to VSTS tests. What he doesn't mention in the post is that he's using GAT to integrate this conversion functionality into VS05. Basically this conversion is an "unbounded recipe" which means that any time you right click on an item in the solution explorer, the NUnit Converter uses Visual Studio's CodeModel functionality to analyze the contents of the file. If the file is a C# file and has any NUnit test fixtures in it, NUnit Converter adds a "Convert NUnit Test Code" item to the context menu.

From a cursory glance at the code (which Jim was kind enough to send me) it doesn't look like it took very much GAT code to integrate into VS. Of all the files in the solution, there are only three that relate to GAT - the Conversion Action (i.e. the code that initiates the NUnit -> VSTS conversion when you select the context menu item), the Conversion Recipe Reference (i.e. the code that determines if the conversion menu item should be added to the context menu) and the Selected Project Item Provider (i.e. the code that retrieves the selected file from the Solution Explorer). There's also the XML file that defines the recipes. Everything else as far as I can tell handles the conversion itself and has nothing to do with GAT.

It's cool to see a real-world usage of GAT and that using GAT is a pretty low-impact effort given the VS integration benefits it provides.