Understanding MustUnderstand

The MustUnderstand attribute is frequently misunderstood because people assume that it must be much more complex and powerful than it really is. I explained the mechanics of using MustUnderstand last year but today’s article is about some of the misconceptions for how the attribute is used.

Annotating a message header with MustUnderstand creates a contract from the client to the service that the operation must fail if that part of the message is not able to be processed. This is not the same as validation because the service can understand what the header means even if the value of the header is wrong. For example, if a header is supposed to contain a certificate, then a service that knows about that header understands the message even if the client passes a certificate that is expired or malformed.

Another key point of the description is that MustUnderstand is a contract from a client to a service. Decorating message contracts with MustUnderstand doesn’t do anything on the service and doesn’t show up in the metadata. You don’t push understanding from the service to the client. The client chooses to decorate the message with a MustUnderstand attribute because the client knows in the message it is sending that a particular message header semantically affects other headers or content in the message. Some of the corollaries of that idea are that message headers with nil or null content can nevertheless have a MustUnderstand requirement and that the MustUnderstand mechanism only is useful if the message header actually gets written into the message. You can’t require a service to support a specific capability with MustUnderstand unless that capability is actually being exercised.

Next time: Concurrent Channel Performance

Comments (1)

  1. When a message header supports multiple representations, which version is used when the message header

Skip to main content