Tuesday, May 06, 2008 11:36:33 PM (GMT Daylight Time, UTC+01:00)
Jesus made me post this picture.
Sunday, May 04, 2008 7:34:48 AM (GMT Daylight Time, UTC+01:00)
Sun is not having a good quarter. This reminded me of a few things that have been bugging me lately. I remember going to a live presentation of Scott McNealy's when he was creating a Java terminal/workstation. I remember hearing him say something to the effect of "This is the Windows-killer, in a year no one will buy PCs with Windows - everyone including your secretaries will be using these workstations". Of course, none of his predictions came to pass, and so the company still limps on.
My philosophy has always been that actually building a better technology and making it a success has nothing to do with talking about how world-changing it will be. In fact, I have always thought the opposite. I think showing people what a technology is capable of is better than just talking about what it’s going to do in the market, or that's it’s the next "x-killer". Sure, you can say, "See how great the y feature of this product is", but predictions as to success and reach just sound dumb to me.
I've always really disliked Scott McNealy, not because he was loud, and not because he hated Microsoft, but because he always talked about how this new thing Sun was doing was going to be the Microsoft/Windows-killer. How about just making a great technology? And then after it becomes the "X killer", you can boast.
A number of things I've heard or seen lately remind me of Scott McNealy. I wish people would just do cool things or build cool things without talking about what the effect of that thing will be. Even if the person might be really cool and super-smart, or even if the technology might be the most important thing to computer science ever, how about just showing us what you've done or built. Accolades will naturally come given the right ideas or actions.
I've always thought that if you talk about how important something will be before it becomes important, is the kiss of death (assuming it does or would have become important). Maybe that's some universal force. Or maybe that's because anyone who feels the need to make those kinds of statements is actually showing us that they are desperate and insecure, otherwise they would just be showing us features and we'd grok how great the thing was.
While he was writing it, did Matz talk about how the language he was developing (Ruby , if you weren't aware) was going to be overwhelmingly popular? I'm guessing not (certainly there isn't any evidence of that).
Did the Beatles go around in 1962 talking about how their music would change the world? –No, they just made music they way they wanted to and it turned out to have a tremendous impact on music. It had that effect without them talking about how great they were.
My philosophy: Do something great, don't talk about it. Even if you think/hope/are convinced it will be great, just do it first. You can talk later about how you hoped it would be great, but talking about it first is lame. Having self-confidence is a positive, but talking about having self-confidence is lame.
"Never make forecasts, especially about the future. In no time, it will be a forgotten memory." - Samuel Goldwyn
Sorry for the non-technical post - but I just had to say this outloud somewhere. Nothing to see here - move along 
Saturday, May 03, 2008 1:07:07 AM (GMT Daylight Time, UTC+01:00)
If you are building Windows Workflow Foundation (WF) applications today (and you aren't building Sharepoint Workflows) you should be using WorkflowServiceHost for your hosting environment. Period, end of discussion (oh - well we can have more decision about it - but its a fait accomplis at this point).
Especially if you are using WF to implement a service, using .NET 3.5 is a total no brainer.
I was doing so the other day using a StateMachineWorkflow hosted in IIS and I was getting an exception. The exception (which I found after I attached the debugger to IIS) was the dreaded (and pretty common) exception "QueueNotFound for queue X".
Now - if I was writing the hosting layer myself I would handle the WorkflowRuntime.WorkflowIdled event and introspect on the WorkflowInstance using WorkflowInstance.GetWorkflowQueueData method to see what queues where available at different points during the workflow to help figure out what the problem was. The problem was that I expected the Queue to be there at that paritcular point of execution, and I wanted to verify that fact using the WorkflowInstance.GetWorkflowQueueData method like this:
void WorkflowRuntime_WorkflowIdled(object sender, System.Workflow.Runtime.WorkflowEventArgs e)
{
ReadOnlyCollection<WorkflowQueueInfo> queues;
queues = e.WorkflowInstance.GetWorkflowQueueData();
foreach (WorkflowQueueInfo qi in queues)
{
Debug.WriteLine("QueueName : " + qi.QueueName);
foreach (string actName in qi.SubscribedActivityNames)
{
Debug.WriteLine("Activity subscribed: " + actName);
}
}
}
This is code I end up writing in just about every Workflow application I build because it is just super useful to know what Queues a workflow is listening for at a particular time.
So here was my problem - since I was using WorkflowServiceHost implicitly through an svc file:
<%@ ServiceHost
Service="WorkflowArtifacts.CalcWorkflow"
Factory="System.ServiceModel.Activation.WorkflowServiceHostFactory" %>
using WorkflowServiceHostFactory, I had no place to get the WorkflowRuntime from the WorkflowServiceHost. If I was creating WorkflowServiceHost myself in code - I could use the following code to get the WorkflowRuntime:
//sh is the WorkflowServiceHost
WorkflowRuntimeBehavior wrb = sh.Description.Behaviors.Find<WorkflowRuntimeBehavior>();
wrb.WorkflowRuntime.WorkflowIdled += new EventHandler<System.Workflow.Runtime.WorkflowEventArgs>(WorkflowRuntime_WorkflowIdled);
Using the WorkflowRuntimeBehavior - I can get the WorkflowRuntime and then subscribe to the WorkflowIdled event - and thus be able to the get data I wanted for debugging my "QueueNotFound for queue X" exception. But alas - using the svc file I don't ever get access to the WorkflowServiceHost.
There is however a solution (at least one) - ServiceHostFactoryBase. One of the cool extensibility mechanisms with WCF you can take advantage of when hosting inside of IIS/WAS is creating your own ServiceHostFactory. By default with code-based services - WCF uses a ServiceHostFactory (which is a derived class from ServiceHostFactoryBase) to create the WCF ServiceHost (which derives from ServiceHostBase) for hosting a code-based service. For Workflow Services - they use a WorkflowServiceHostFactory (as you can see from my svc file) to create the WorkflowServiceHost.
Luckily (and I'm sure intention on the framework team's part) WorkflowServiceHostFactory isn't sealed. What this means is that I can create my own WorkflowServiceHostFactory class - change the Factory attribute in my svc file to point to my factory - and then insert the code I wanted to work with the WorkflowRuntime object.
Here's my WorkflowServiceHostFactory class:
public class MyWorkflowServiceHostFactory : WorkflowServiceHostFactory
{
public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
{
ServiceHostBase sh = base.CreateServiceHost(constructorString, baseAddresses);
//sh is the WorkflowServiceHost
WorkflowRuntimeBehavior wrb = sh.Description.Behaviors.Find<WorkflowRuntimeBehavior>();
wrb.WorkflowRuntime.WorkflowIdled += new EventHandler<System.Workflow.Runtime.WorkflowEventArgs>(WorkflowRuntime_WorkflowIdled);
return sh;
}
void WorkflowRuntime_WorkflowIdled(object sender, System.Workflow.Runtime.WorkflowEventArgs e)
{
ReadOnlyCollection<WorkflowQueueInfo> queues;
queues = e.WorkflowInstance.GetWorkflowQueueData();
foreach (WorkflowQueueInfo qi in queues)
{
Debug.WriteLine("QueueName : " + qi.QueueName);
foreach (string actName in qi.SubscribedActivityNames)
{
Debug.WriteLine("Activity subscribed: " + actName);
}
}
}
}
And my svc file:
<%@ ServiceHost
Service="WorkflowArtifacts.AccumWorkflow"
Factory="MyWorkflowServiceHostFactory" %>
And magically my service still works, and I am able to handle the WorkflowRuntime.WorkflowIdled event - or any other WorkflowRuntime event I want.
WCF | WF
Thursday, January 03, 2008 7:47:08 AM (GMT Standard Time, UTC+00:00)
So I was cleaning out my desk and found something that I would have blogged about had I had a blog when it happened :)
People tend to think of me as a BizTalk guy - but before that I was really an ASP and then ASP.NET guy. On one of the early ASP.NET mailing lists Scott Guthrie challenged us to write an application that hosted ASP.NET outside of IIS (this of course if now all documented - but it wasn't at the time). I was the first (or one of the first) people to do this (the only thing I remember is having to use PInvoke and LoadLibrary to load the aspnet_isapi.dll into the process for stuff to work) and he sent me a hat (which I still have somewhere) and a signed .NET Framework CD. Fun days.
Also funny that my next post will likely be able hosting ASP.NET outside of IIS.
ASP.NET