tags:

views:

45

answers:

1

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 accessible 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.

A: 

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.

marc_s
Sorry, I didnt make that clear. I was talking about the calls that a service will further make to other services. I need to pass the informatin along. How would you do this without peeking into the headers in the service method(aka messy code)
Cosmin Onea
Using OperationContextScope is messy as well.
Cosmin Onea
I don't think there is any other way than reading out the headers comnig from the first call, and sticking them back into the header of the second, outgoing call.
marc_s
Yeah that is the idea. how would you do that and keep the code in the service method as clean as possible?
Cosmin Onea
Well didn't mention that but the router service is my entry point into the internal service realm. However the router does not solve the problem as you still need to add headers from the client.
Cosmin Onea