Leave a Reply

One comment

  1. Although I don’t work for Microsoft anymore, I believe I can still provide some insight about this, since I was the original developer for State Machine Workflows (but not the designer of the relationship between IEventActivityListenter and EventDrivenActivity).

    The confusion that you describe comes from the fact that IEventActivityListeners have this dual personality, one when used inside EventDriven activities and another when used as part of a regular flow.

    When used as part of the regular flow, the Delay or any other Receive-style activity simply blocks waiting for the expected message to come blocking in the Executing state.

    EventDriven activities, on the other hand, were used to describe a “wait for the first of these messages”, which is the very nature of the State activity or the a group of EventDriven activities in a sequential workflow.

    Without getting into too much detail (I don’t even think I’m allowed to, anyway), given the nature of the workflow scheduler, there were issues regarding guaranteeing that only one event would be processed in the case where two messages were received very close to each other.

    So the solution adopted was to have this internal protocol that the wait is actually performed by a parent activity that “knows” about all IEventActivityListeners currently waiting.

    Trust me, I’m just like any developer that hates this sort of special case, and although I had some ideas on how to clean this up, I joined the team after most of these designs were already implemented and it was deemed too risky to do pervasive changes at that point in the project even though a lot of people recognized the need for a better design.

    The lack of documentation, at least in part, comes from the fact that the team want to reserve some breathing space to do these changes in the future without having to break lots and lots of customer code.

    This is one of the coolest things and also the biggest curse of working on API’s that are used everywhere, you get a lot of exposure, but if you make something public that is not quite right, you have to live with it for as long people now what GAC stands for.

    Luckily, the people (like you) that find out how these things really work under the hood are the ones best equipped to survive (and forgive, hopefully) redesigns that breaks customer code.

    – Marcelo

    Marcelo Uemura Reply