To set up the subscription for events from a custom service, CallExternalEventActivity registers with the CorrelationService, and calls the specified method on the custom service to create the event subscription.

When an event is raised by the custom service, it is handled by the HandleExternalEventActivity. When this activity is unsubscribed, it cleans up its own subscription with the CorrelationService, but it provides no means for the subscription with the custom service to be cleaned up, as there are no overridable unsubscribe method.

This means that subscriptions cannot be manually removed from custom services!

I appreciate that for once only guaranteed events, such as the CorrelatedLocalService sample this isn't a problem as the subscription cleans itself up when done, but for other things such as a file watcher service or message queue listener service, where the events are neither once only nor guaranteed, the subscriptions cannot necessarily clean themselves up (for example, the specified file system event may never be raised).

Now either I'm missing something (entirely possible) or this is a serious design flaw in the HandleExternalEventActivity activity. It looks as though it could be easily solved by declaring the private UnsubscribeForActivity as "protected virtual" but at the moment it is a major issue.

Any comments appreciated.

(note that at the moment, I have wrapped the HandleExternalEventActivity inside a SequenceActivity, implemented the IEventHandler and IActivityEventListener<QueueEventArgs> interfaces which pass through to the handler activities implementations, and added my custom unsubscribe code to the Unsubscribe and Execute methods. This also required me to write a custom CorrelationTokenType converter as the provided one is internal, so it hardly seems an ideal solution although it does appear to work fine)

The CorrelatedLocalService SDK sample derives from these activities, which implies that they are intended to be derived from in this type of case.

The particular activity I am writing here is a file system watcher, which needs to be in two parts as the first activity needs to start the watcher, then the code needs to occur which may cause the file drop, and then the second activity receives the event if it occurs. The SDK sample where the same activity sets up the file watcher as listens for its events is subject to a race condition where the file drop may occur before the watcher is set up.

To go down the manual workflow queue route, I would essentially going to have to write my own correlation service to buffer the events between when the first activity sets the FileSystemWatcher up and the second subscribes to these events, and try and reproduce all the handler logic in HandleExternalEventActivity. This is not a trivial task.

My workaround, which was easier than this but still nontrivial is to host the HandleExternalEventActivity in my own listener and insert calls to my custom unsubscription logic where needed, which was the in Unsubscribe, Execute and Cancel methods, before passing through to the hosted activity. In fact, exactly where the private unsubscription method is called in HandleExternalEventActivity itself.

It seems to me flawed that there is no way to hook into when the underlying activity is being unsubscribed, given that the two activities give you explicit means to subscribe and handle events, and that from my testing all that is needed is one private method to be made protected virtual.

Jon,

I agree with you. The HEE activity concept is based on the event driven wrapper around the remoting IMethodCallMessage messaging with tightly coupled design pattern to the business layer. Raising an ExternalDataExchange event in the business layer will create an IMethodCallMessage message and enqueue it to the private application specific workflow queue (created based on the interface type, method, ...).

Using the WorkflowQueues directly enables consuming a workflow based on the interface contract. That's why I have built this.

Thanks for the input guys, I'll have a look at the articles and samples you've suggested.

Maybe it's the lack of documentation but I guess I just didn't feel that you should have to write a custom framework for subscriptions given that there is built in stuff which seems targeted at doing this. It seems rather weak that more generally useful framework code isn't actually part of WF in the first place, only limited activities. Oh well - I guess it is essentially a V1 product... :-)