Note

These docs are a work in progress. While conceptually correct, the diagrams/code samples on this page might not be 100% in line with the current implementation in Copper.

Ambient operation context

Context and problem

Every transport protocol has a notion to provide information across the wire which is not part of the message itself, but is important to send along to the other end. Whether this is user information in a HTTP header, or language code, user-agent, etc. All relevant information which the receiving party may use to better serve the request that has been made, without overloading each payload definition with these properties.

Usually these out-of-band parameters have to be set for each request, and also for each transport specific.

Solution

Maybe the most fundamental building block is the ambient operation context. It allows for context to pass from one service to the next, even travelling along across event. This enables some of Copper's best features, such as Diagnostics and Workflow capabilities.

Due to the way that Copper handles transports, the mechanism for passing context information is generic across all transports and does not require code change when going from queued calls to request/response.

---

Context flow works in any Copper scenario:

• Between client and service
• Between services
• Across events
  • Timeline separated
• Pass-through support

The operation context also supports pass-through. So if Service A does not know a specific type, which Client and Service B do know, it can pass through Service A.

Features using Ambient operation context

• Diagnostics correlation
• Workflow correlation
• Push style APIs