wcf - transfer context into the headers

I am using wcf 4 and trying to transparently transfer context information between client and server.

I was looking at behaviors and was able to pass things around. My problem is how to flow the context received in the incoming headers to the other services that might be called by a service.

In the service behavior I intercept the the message and read the headers but don't know where to put that data to be acces开发者_开发技巧sible to the next service call that the current service might make.

What I am looking for is something like:

public void DoWork()
{
     var someId = MyContext.SomeId;
     //do something with it here and call another service
     using(var proxy = GetProxy<IAnotherService>())
          proxy.CallSomeOtherMethodThatShouldGetAccessTo_ MyContextualObject();

}

If I store the headers in thread local storage I might have problems due to thread agility(not sure this happens outside ASP.NET, aka custom service hosts). How would you implement the MyContext in the code above.

I chose the MyContext instead of accessing the headers directly because the initiator of the service call might not be a service in which case the MyContext is backed by HttpContext for example for storage.

In the service behavior I intercept the the message and read the headers but don't know where to put that data to be accessible to the next service call.

Typically, you don't have any state between calls. Each call is totally autonomous, each call gets a brand new instance of your service class created from scratch. That's the recommended best practice.

If you need to pass that piece of information (language, settings, whatever) to a second, third, fourth call, do so by passing it in their headers, too. Do not start to put state into the WCF server side! WCF services should always be totally autonomous and not retain any state, if at ever possible.

UPDATE: ok, after your comments: what might be of interest to you is the new RoutingService base class that will be shipped with WCF 4. It allows scenarios like you describe - getting a message from the outside and forwarding it to another service somewhere in the background. Google for "WCF4 RoutingService" - you should find a number of articles. I couldn't find antyhing in specific about headers, but I guess those would be transparently transported along.

There's also a two-part article series Building a WCF Router Part 1 (and part 2 here) in MSDN Magazine that accomplishes more or less the same in WCF 3.5 - again, not sure about headers, but maybe that could give you an idea.