WCF customheader or messagebody for context?

Question

I'm witting a WCF service for a customer to send part information to our application. We have multiple customers that will have one or many locations, and part information is scoped to each location for the customer. When the customer calls our service they will need to specify the location.

Options that we have considered are:

1) Placing a location id(s) in a custom header. All part information would apply to all locations listed.

2) Adding a "context" node to the message body. All part information would apply to all locations listed.

3) Adding a location node in the message body over that would contain the part information. Each location would have it's own list of parts.

I'm looking for best practice/standards help in determining how this should be handled. We will have to create other services that will have the customer/location scope as well, and would like to handle this in a consistent manor.

Answer 1

Do you need to use a message contract? I use Data contracts unless I need to stream something back, so everything just ends up in the body. But, even for a message contract I would put that information in the body, I tend to reserve the header for authentication information.

Answer 2

We plan to send a response with processing summary information and details about any part that could not be processed.

The message contract has a collection of parts, and the parts are defined in a data contract. There is also a flag in the message contract to control processing of the parts collection. This may or may not be the right place for this flag.

Answer 3

I would say if it's only one or two operations that need it, make it part of the data contract - sort of like making it a parameter to a method call. If every operation requires it, put it in the header, since it's just as much context as username, roles, tenant, or other authentication information - sort of like something you'd put in a request context (e.g., HttpContext).