Jon Flanders posted a comment on my post yesterday about the changes in the new release of my MsmqActivities sample regarding the new subscription persistence functionality. I was going to respond on another comment, but I think this might be important enough to warrant its own post. Here's Jon comment:
I am still concerned about your approach (essentially another persistence service to take care of). Especially in light of:
a) How will this work in a mulit-host instance environment
b) How will it stay consistent with the state of the workflow itself (what if your service gets out of sync with the current state of the workflow).
Which is why I would prefer some system that used the metadata of the activity instance itself - I would lean toward SqlPersistenceService.GetAllWorkflows - which would allow you to get the activity metadata without having to load it into memory. OTOH - this is only on the OOB persistence service.
Let me just start by mentioning that I actually share Jon's concern about this approach [1]. It is another persistence service to take care of and that brings up a number of issues and potentiall problems with it.
Regarding point (a) Jon brings above, the answer is: it won't work well, for very obvious reasons. The primary one is actually related to how MSMQ itself works, and that's a significant limitation right there. If you have multiple hosts trying to listen to the same queue, then things won't really work very well. And, because of this, using this in a "load-balancing" scenario with multiple servers hosting the same workflows really wouldn't work at all as expected.
Regarding point (b), yes, that's actually my biggest fear. Hopefully, it is not something that would happen too often (at least that's what I think from my tests, I could be wrong) but it is definitely a possibility.
I'm going to be frank about this and say that right from the start I didn't want to have to implement something like this; it just feels wrong. I looked for other options but I just didn't see anything obvious that would work and at least workaround the underlying issue.
My MsmqActivities have been a wonderful tool for me to understand a lot of concepts of WF. It's obvious that in many ways they are "toys", but precisely because of the requirements they impose they make, IMHO, a good sample to understand a lot of the implications of writing a full-fledged custom event activity that doesn't use the built-in services (i.e. HandleExternalEvent).
Jon proposes a good idea, and that's trying to avoid having to do the external persistance of subscriptions in the first place and instead trying to rely on getting the necessary information to recreate the subscriptions from the workflow instances stored by the workflow persistence service. I'll explore this option further, but I do have my reservations if that information will be enough to get all information needed to recreate the subscriptions (including recognizing in which scenarios an activity is found that would have the subscription active or not). Thinking a little bit further, it brings a good question to the table: Will the instance state stored by the workflow persistence service be enough to satisfy all kinds of activities depending on external services?
A few days ago Jon made an excellent observation: That these kind of issues are solved in a very elegant manner by the BizTalk Message Box design, and I fully agree with this. The Pub/Sub engine in BizTalk, together with the comprehensive concept of Application and Isolated Hosts gives a lot of power to BizTalk and makes a really strong and powerful foundation for solving this kinds of problems. This is because it provides a clear way to decouple the workflows (i.e. the orchestrations in the current incarnation) from the external services feeding data and events to them (receive ports and locations), while at the same time providing a unified storage mechanism to keep track of the state of all of them.
This is why I'm so looking forward to when WF and BizTalk get integrated; as it will should make possible to have the best of both worlds together.
[1] I was going to mention some of this on my original post, but I totally forgot, sorry!
Technorati: Windows Workflow Foundation, WF, MSMQ, BizTalk
