I'll give it a try, though I am not sure I can make it simpler.
Let's say I have four nodes (computers) A, B, C and D.
A client is running on node A, a server on node D. Finally, B and C are intermediary nodes; B passes messages on to C and C on to D.
If the client sends out a header block targeted at node C with the mustUnderstand attribute set to 0, then the client cannot know whether node C chooses to process the message or not.
If the client sends out a header block targeted at node B with the mustUnderstand attribute set to 1 and the client does not receive a fault, then the client can be sure that node B has processed the header block.
The mustUnderstand attribute can be used to force a node to process a header block. This is good if, for instance, the header block contain information that must reach the node.
On the other hand, there may be information that is not essential to the intermediary node. Then mustUnderstand can be set to 0, which allows the node to ignore the header block.
Yes that's right. If mustunderstand attribute is 1, any targeted node must process that header if not able to process that header it will generate faultCode "mustUnderstand" and send it to the client.
This is useful in case of implementing security and other meta services to the webservice. we can same receiver act as ultimate receiver and also other role like "Authetication Processor". we can put header info like userId and password for processing by this Authentication Processor, so when it is successfuly processed it will deliver to the real webservice otherwise generate a fault and send it to the client.
Most of the times developers combine authentication in webservice itself but best practice is to have seperate code block and targeted by header.
I hope this gives some more information on header.