tags:

views:

22

answers:

1

This question is about “informational messages” and having them flow from a “back end” to a “front end” in a consistent manner. The quick question is “how do you do it”?

Background:

Web application using WCF to call back end services.

In the back end service a “message” may occur. Now, the reason for this “message” may be a number of reasons, but for this discussion let’s assume that a piece of data was looked at and it was determined that the caller should be given back some information regarding it.

This “informational” message may occur during a save and also may occur during retrieval of information. Again, the message is not what is important here, but the fact that there is some informational messages to give back under a number of different scenarios.

From a team perspective we all want to return these “messages” in a standard way all of the time. Now, in the past this “standard way” has been done different ways by different people.

Here are some possibilities:

1) Every operation has a “ref” parameter at the end that contains these messages

2) Every method returns these messages… however, this only kind of works for “Save” methods as one would think that “Retrieve” methods should return actual data and not messages

3) Some approach using the call context so as to not "pollute" all message signatures with something; however, with WCF in the picture this complicates things. That is, going back to the messages go on a header?

Question: Back to my question then… how are others returning “messages” such as what was described above back through tiers of an application, over WCF and back to the caller?

A: 

I think you basically have two proper ways of doing this:

  1. add a InfoMessage : string field to all your DataContracts, which can hold an informational message (or not) back from the server

  2. If you don't want to put that into the DataContracts, then create a header which you populate on the server before the message goes back to the client, and on the client, you can inspect that header and retrieve it if present

In order to automagically add headers to WCF messages, typically the mechanism of MessageInspectors is used - little chunks of code that can be configured or added by means of an attribute on your operation contract, that will add the header on the one end, and inspect the incoming message for that header (and extract it, if present) on the other end.

There are a number of pretty good blog post out there showing you how to create a message inspector:

Those mostly go from client to server, e.g. the client sends along a header with some "meta-information" for the service - but it works just fine the other way around, too.

Check out the two relevant interfaces to implement:

marc_s