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!

>