2.1 Transport
The .NET Tracing Protocol enables correlated activity tracing between client and server endpoints, even across different application domains for a single unit of processing, such as request or reply. For example, the .NET Tracing Protocol enables correlation of traces generated at the client end for the send operation and at the server end for the receive operation for a request message exchange. Additionally, for a request-reply message exchange pattern, the .NET Tracing Protocol enables correlation of traces generated for both the request and the reply.
In order for a client and a server to generate correlated activity tracing using the .NET Tracing Protocol, both the client and the server MUST use a SOAP-supported transport protocol for message exchange. There are no restrictions on the use of any specific SOAP transport protocol.
To participate in the generation of correlated activity traces using the .NET Tracing Protocol, both the client and the server MUST insert the special SOAP header block <ActivityId/> (namespace "http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"), which is also called the SOAP ActivityId Header Block, into the SOAP header when sending a message. This SOAP ActivityId Header Block MUST follow all the rules of the SOAP header specified in [SOAP1.2-1/2007] Section 3 SOAP Extensibility Model and [SOAP1.2-1/2007] Section 5.2 SOAP Header. The sender MUST associate the GUID string specified as the ActivityId with the activity traces generated at its end. When a message is received by a recipient, and the SOAP header includes the SOAP ActivityId Header Block, the recipient MUST process the SOAP ActivityId Header Block. The received ActivityId MUST be associated with the activity traces generated by the recipient. If the request-response message exchange pattern (as specified by SOAP) is used, then the server MUST echo the ActivityId received in the request in the SOAP ActivityId Header Block, included in the reply message header. The CorrelationId attribute MUST be different than the one received in the request. If the request does not include the SOAP ActivityId Header Block, then the server MUST behave as if it is an initiator and MUST insert the SOAP ActivityId Header Block in the message header for the reply. Figure 1 describes the message exchange sequence for a request-response message exchange pattern between a client and a server.
The SOAP ActivityId Header Block is an optional SOAP header that MAY<1> be included. The message recipient MAY ignore the SOAP ActivityId Header Block if it is included in the received request. In case of a request-response pattern, the message sender MUST NOT declare a failure condition if the SOAP ActivityId Header Block is not included in the response, even if the request is included in the header.
This specification does not specify how to process any custom third-party extensions or attributes to this protocol when they are processed by a client or a server.