Conversations with Workflow Services
A conversation is a logical grouping of ReceiveActivity and SendActivity activities. Both parties in the conversation are client and server at the same time. There will always be a pair of SendActivity and ReceiveActivity activities that implement a conversation. The party that initiates the conversation will have a SendActivity activity followed by a ReceiveActivity activity and, on the other side, there will be a ReceiveActivity activity followed by a SendActivity activity.
Conversations are also a way of correlating messages to the correct ReceiveActivity activity. For example, consider a document approval workflow in which five approvals are happening simultaneously. For each approval, there may be a ReceiveActivity activity that will receive the approval/rejection message. If the workflow receives an approval message, then it has to determine which ReceiveActivity activity should get the message. This disambiguation or correlation is done based on the conversation ID.
To expand on that example, consider that a single workflow instance is being used to talk to two shipping companies: Contoso and Fabrikam. All the receive activities that receive a message (and send a reply back) to Contoso might have the conversation ID "Contoso," and all the activities that receive a message from Fabrikam might have the conversation ID "Fabrikam."
Every conversation must have an owning activity. The owning activity of a conversation is a common parent activity of all the ReceiveActivity activities within the conversation. The OwnerActivityName property references this owning activity and after the owning activity finishes execution, the conversation goes out of scope.
|The ReceiveActivity activity inside a StateActivity activity in a state machine workflow should have context in a scope bigger than the enclosing StateActivity activity to participate in a conversation. This is because the StateActivity activity is spawned in a different context each time it becomes active.|