(Late) Morning Coffee 36

  • It snowed again yesterday. Last year we had one snowstorm, the year before that none. We’ve now had I think five this year plus the massive windstorm that knocked out power for days.
  • Technorati told me that “social news aggregator” Megite is linking to me. For some reason, this post of mine on Powershell is considered related to “Is PR Too Stupid for Conversational Marketing?” from Amanda Chapel. Seems like Megite has some bugs to work out.
  • Paul Andrew announces BPEL support for WF but David Chappel writes “no one should interpret the announcement as an embrace of BPEL-based development by Microsoft”. Personally, I think BPEL is just the latest attempt at “write once, run anywhere” and will meet with the same limited success of previous attempts. The last thing I think MSFT should do is embrace BPEL based development.
  • BPEL actually has two flavors, Executable and Abstract. Abstract BPEL is potentially fairly useful. You could use to exchange of the publicly viewable parts of a process with a partner in order to make two processes work together. That’s fairly exciting. I would welcome Abstract BPEL support for WF and/or BTS. But as far as I can tell, most of the BPEL focus has been around Executable BPEL, which as I wrote above is attempting to be a platform independent language for implementing business process. That’s fairly unexciting since we’ve been down this road before many times (UNIX, CORBA, J2EE) and it has never worked out.
  • Soma announces the launch of the Beginner Developer Learning Center. It includes Kid’s Corner with the cutely named C# for Sharp Kids and VB for Very Bright Kids e-books. Very cool, I can’t wait to share this with my kids in a few years. Only complaint: where’s the XNA love?

Morning Coffee 34

  • Old news, but Reflector 5.0 is out. W00t! Not sure when Scott Hansleman became chief Reflector cheerleader, but he’s got the rundown on the new features.
  • Politics 2.0 Watch: OpenCongress. Sort of like Wikipedia for government. If we can disseminate information on bills and resolutions via the Internet, couldn’t we collect votes on them as well?
  • I got my hardcopy of Powershell in Action while I was on vacation. Highly recommended.
  • Sam Gentle is starting to dig into WF, and he posts about the difficulty getting data in and out of workflows. He’s using the ExternalDataService infrastructure which I don’t like very much. I recommend getting friendly with the WorkflowQueuingService which is the low-level communication infrastructure that ExternalDataService builds on top of. The WQS docs are severely lacking, but it’s fairly straight forward to figure out.
  • Speaking of WF, Tomas Restpro reviews Programming WF. Sounds fairly introductory. Personally, Essential WF is one of the best tech books I’ve read in a long time, so I’ll be skipping this book.
  • My teammate Dale is continuing his daily posts on his blog.
  • Joe McKendrick wonders if EDA is the new SOA. Frankly, both terms are so poorly defined that it’s hard to determine exactly what each term means, much less how they’re related. If you’re an IT industry analyst, you probably can make a ton of cash describing the differences between them. Maybe it’s me, but I don’t see that much value in SOA without EDA. In fact, I’d go so far as to say service orientation without events isn’t much a new architecture paradigm at all. It’s just the Same Old Architecture with better support for interop.

Morning Coffee 27

  • Is there a good solution to colorize source code that looks good in RSS feeds? I’ve tried Insert Code and Paste from VS for WL Writer and both look fine in HTML but awful in RSS.
  • My friend David Geller launched his latest venture Eyejot recently. Eyejot is a Flash-based video messaging system, so you can send and receive video clips without having to install anything but a webcam. According to the Eyejot blog, they’re getting some good press. See an interview with David about Eyejot up on YouTube.
  • Here’s an interesting article on using WF with Amazon’s Mechanical Turk service. Invoking MTurk isn’t that interesting – it’s just a web service and WF has a built-in InvokeWebService activity. But since MTurk has no way to asynchronously call out to the WF, you have no choice but to regularly poll MTurk to see if the task is complete. Yuck. (via Larkware)
  • Yahoo! Pipes looks interesting. At least the screen shots of it on various websites and blogs look cool. Too bad the site is absolutely hammered this morning. (via Dare Obasanjo)
  • Like GAT? Like DSL? Then use them together!
  • If I can more than raise my Gamerscore by 1,500 points by April 12th (i.e. more than double it), I can get a free $5 game. But why wait to start the contest until next Monday? Doesn’t that discourage people from playing until then?

Morning Coffee 20

  • Jim Gray has been missing at sea since Sunday. My thoughts are with him. (via Werner Vogels)
  • We launched Windows Vista and Office 2007 yesterday. There were parties on campus, but my office is a little off the beaten path, so we didn’t get a party.
  • WF Activity Validation is very cool, but make sure you put your activities into a separate project from your workflows. It took me a few minutes yesterday to figure this out, but the validators are invoked not only for the activities in workflows, but for the actual activity implementation itself. My validation logic is checking to ensure properties are specified and that given activities are or are not inside a transaction scope. Obviously, the activity implementation is invalid according to these rules. Also, you need to remove the Workflow.Targets import from your activity project file, as that is what invokes the activity validation.
  • A quick follow-up to yesterday’s compiling workflows post: WF appears to be fairly short on out of the box functionality, but more than makes up for it with an expansive extensibility model. It makes the learning curve longer, but it’s well worth it the trip.
  • I’m demoing the result of the proof of concept work we’ve done over the last few months today. It’s been a while since I’ve presented to any kind of audience so we’ll see how it goes.

Compiling Workflows

Scott Allen pointed out that if you need to declare top level properties in a XAML only workflow, you can subclass the root activity class, add the properties you want, then specify the custom subclass in the XAML workflow. That doesn’t really solve my problem. I’m trying to limit to activity vocabulary that the workflow author has access to. If they can specify their own custom type as the root activity of their workflow, they can also add whatever execution logic they want, which is what I’m trying to avoid.

There is an example in the Advanced Authoring chapter of Essential WF where they describe building a root activity class that generate top level properties as part of the workflow compilation process. The root activity (in the example, it’s called “SequenceWithVars”) where you can specify the top level parameters in the XAML. Here’s an example from the book:

<SequenceWithVars x:Class="Workflow1" xmlns="..." xmlns:x="...">

The SequenceWithVars type includes a custom ActivityCodeGenerator that loops thru the VariableDecls collection and adds a top-level property (via CodeDOM) for each VariableDecl instance. You end up with a workflow class that looks like this:

public partial class Workflow1 : SequenceWithVars
{
  public static DependencyProperty OrderProcConversationProp =
    DependencyProperty.Register("OrderProcConversation",
      typeof(Guid), typeof(Workflow1));

  public Guid OrderProcConversation
  {
    get
    {
      return (Guid)base.GetValue(Workflow1.OrderProcConversationProp);
    }
    set
    {
      base.SetValue(Workflow1.OrderProcConversationProp, value);
    }
  }

  //Remaining WF type declaration goes here
}

In order to use the XAML workflow with the SequenceWithVars activity, you do need to compile the XAML first using the WorkflowCompiler class. WorkflowCompiler.Compile() returns a compiled type which can then be passed to CreateWorkflow. But adding the separate compile step is a small price to pay, in my opinion. This approach lets me limit the workflows to XAML only while still allowing for top level properties which are needed in many data binding scenarios.