A few days ago I talked about how to enable tracing across service boundaries. The brief summary of that story is that tracing across boundaries works by associating an identifier with each activity and using the identifier to later reconstruct the original sequence. Today I'll talk a little bit about the implementation of the identifier. The interesting case to talk about is what takes place when we want to hand off control from an activity running on one machine to any of the following:

• A different activity running on the same machine
• The same activity running on a different machine
• A different activity running on a different machine

The mechanism for doing the transfer from activity A to activity B is a simple interlocked process.

1. The ambient activity starts out as activity A.
2. A TraceTransfer is generated with the identifier for activity B.
3. If the call is blocking, then a TraceEvent is sent to suspend activity A.
4. The ambient activity becomes activity B.
5. A TraceEvent is sent to start activity B.

The process happens in reverse if we want to transfer back from activity B to activity A.

1. The ambient activity starts out as activity B.
2. A TraceTransfer is generated with the identifier for activity A.
3. A TraceEvent is sent to stop activity B.
4. The ambient activity becomes activity A.
5. If the call was blocking, then a TraceEvent is sent to resume activity A.

Next time: Faking Poison Message Handling