When working with WF I always find it useful having a BizTalk background. Issues that are reasonably well known in BizTalk are not immediatedly apparent in Workflow unless you know they are part and parcel of that style of programming.
One issue in BizTalk is where you are waiting for a number of messages to start off some processing and you don't know in which order they are going to arrive. In this situation you use a Parallel Shape and put activating receives in the branches initializing the same correlation set. The orchestration engine understands what you are trying to do and creates a convoy for the remaining messages when the first one arrives. This is known as a Concurrent Parallel Receive. You don't leave the parallel shape until the all the messages have arrived and the convoy ensures that the remaining messages are routed to the same orchestration instance.
There is, however, an inherent race condition in this architecture in that: if two messages arrive simultaneously, due to the asynchronous nature of BizTalk, both messages could be processed before the orchestration engine has a chance to set up the convoy infrastructure. We will end up with two instances of the orchestration both waiting for messages that will never arrive. All you can do is put timeouts in place to ensure your orchestrations can recover from that situation and flag the fact that the messages require resubmitting.
With Workflow Services we essentially have the same issue waiting for us. Lets set up the workflow ...
If we call this from a client as follows:
PingClient proxy = new PingClient();
proxy.Ping1();
proxy.Ping2();
then everything works ok - in fact it works irrespective of the order the operations are called in, that's the nature of this pattern. It works because by the time we make the second call, the first has completed and the context is now cached on the proxy.
But lets make the client a bit more complex:
static IDictionary<string, string> ctx = null;
static void Main(string[] args)
{
PingClient proxy = new PingClient();
IContextManager mgr = ((IChannel)proxy.InnerChannel).GetProperty<IContextManager>();
Thread t = new Thread(DoIt);
t.Start();
if (ctx != null)
{
mgr.SetContext(ctx);
}
proxy.Ping1();
ctx = mgr.GetContext();
Console.WriteLine("press enter to exit");
Console.ReadLine();
}
static void DoIt()
{
PingClient proxy = new PingClient();
IContextManager mgr = ((IChannel)proxy.InnerChannel).GetProperty<IContextManager>();
if (ctx != null)
{
mgr.SetContext(ctx);
}
proxy.Ping2();
ctx = mgr.GetContext();
}
Here we make the two calls on different proxies on different threads. A successful call stores the context in the static ctx field. Now a proxy will use the context if it has already been set, otherwise it assumes that it is the first call. So here the race condition has made its way all the way back to the client. There are things we could do about this in the client code (taking a lock out while we're making the call so we complete one and store the context before the other checks to see if the context is null), however, that really isn't the point. The messages may come from two separate client applications which both check a database for the context. Again we have an inherent race condition that we need to put architecture in place to detect and recover from. It would be nice to put the ParallelActivity in a ListenActivity with a timeout DelayActivity. However you can't do this because a ParallelActivity does not implement IEventActivity and so the ListenActivity validation will fail (the first activity in a branch must implement IEventActivity). We therefore have to put each receive in its own ListenActivity and time out the waits individually.
So is the situation pretty much the same for both WF and BizTalk? Well not really. The BizTalk window of failure is much smaller than the WF one as the race condition is isolated server side. Because WF ropes the client into message correlation the client has to receive the context and put it somewhere visible to other interested parties before the race condition is resolved.
Hopefully Oslo will bring data orientated correlation to the WF world