Demos from SOA conference (including RetryActivity)

If you attended my talk at the SOA conference on building composite activities, then you'll find the demos here.  I really liked doing this talk and it gave me a reason to work on a composite activity that I wanted to write for a while: the RetryActivity.  I started wanting to build this activity because when I teach people about WF and we talk about security on incoming data, there is always a question about how to handle failed authorization.  When the user fails authz on the built-in activities today, an exception is raised which I can catch and handle in the workflow.  The problem is that once I have done that catch, I close out the composite activity that caught the exception and I'm no longer listening for data.  Well, if Bob tries to submit data and fails because he isn't supposed to, I don't want to stop listening for data, I want to keep listening and let Alice (who is authorized) submit data and interact with my workflow.   The retry activity lets me do that by re-executing the child activities for a certain number of tries as long as an exception gets raised. 

The way I implemented this was to spawn a new execution context for each iteration much like the while activity.  In my case, what I use to determine if I'll iterate again is a combination of whether the child activity failed to succeeded, along with a retry count/max pair that lets me know if I should quit trying.  Naturally, if there are no failures, I just close and finish.  This allows me to use a single purpose activity for retry behavior instead of continually having use the while activity and check whether an exception was raised or not.  It also makes it easier to manage the errors raised by the child activities and nulling out the CurrentException property so I can decide when errors should propagate beyond my activity. 

Now, what I'd really like, related to security, is to move the authorization out of the workflow, so that authorization failures don't have to be modeled in my workflow unless I want them to be.  That way my workflow doesn't even get invoked if you don't have rights.  Something where I can declare the security in the workflow, and then generally be able to apply security to the queues that are used to communicate with the workflow.   The "Silver" or WCF activities in .NET 3.5 do a little of this by reading the validation from the workflow definition and invoking it before sending the data to my workflow. 

I'll be working on some other features of this activity to allow things like retry only on certain exception types, and the ability to put an interval between retries.  If there are other features you'd like to see, let me know and I'll put them on my plan.