Routing of Void-Messages

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

When extending WCF stack in almost all enterprise relevant use cases reliable messaging is very important. Unfortunately in many scenarios, you will have a problem that WS-* trust of vendor one is not same as WS-* of vendor 2. In such cases (that are almost all interop cases) you will have to take a care that no message is lost.
One may think that this is common requirement. This is true, but most common solutions do not support it just out of the box.
For example, imagine you want to implement WCF channel which reads messages from some queue. Let say MQ. You will read message in your implementation of IOutput, IReply or related channel. After the message is dispatched to service operation the resulting message (operation response) will be send by Service Model to you IRequestContext only if the operation is not marked as OneWay. That means you will not be able to implement message reliable channel by using of contracts which requires OneWay messaging.

Shortly following statements hold:

a) if the message is OneWay then independent on contract which your channel implements the message will never be routed back to your channel. That means you will not be able to implement reliable messaging, because your channel is not notified about possible error in service operation.

b) If the message is not OneWay then Service Model will route result message to the right place. This should be IRequestContext implementation.

c) Independent on channel type and operation style (OneWay or not) Service Model will always invoke extensions of type MessageInspector. This holds even in a case of an failure in service operation. Unfortinatelly this is not a case for routing to zour channels like IRequestContext .

d)If operation has return value (OneWay=false)then appropriate message will be be routed to IRequestContext concrete implementation.

e)If operation has not a return value (return ‘void’) and operation fails, then appropriate fault message will be be routed to MessageInspectors. The fault message will also be routed to IRequestContext concrete implementation if the operation is not set as OneWay.

e)If operation has not a return value (return ‘void’) and operation is completed successfully the service model will generate a void message if the operation is OneWay=false. This is very important statement, because many people think that VOID-returning operations do not generate messages. Void-Messages are not generated if the contract is OneWay=true.If OneWay=false, service model will for Void-response always generate one message (se below), but the channel implementation will decide whether to send the message or not.
Following message is internally routed in WCF stack when a void operation returns if the operation is marked as OneWay.

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
           
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <
s:Header>
    <
a:Action s:mustUnderstand="1">
             
http://tempuri.org/IOneWayReceiverTestInterface/InvokeResponse</a:Action>
    <
a:RelatesTo>ID:414d5120514d312020202020202020204d93fd4902da0120</a:RelatesTo>
 
</s:Header>
  <
s:Body />
</
s:Envelope>

This message is posted to BeginReply and Reply operations of RequestContext interface.


Posted May 29 2009, 07:33 PM by Damir Dobric
Filed under:

Comments

Damir Dobric Posts wrote “OneWay” Operation style mismatch
on 06-05-2009 12:55

When working with service you sometimes may get following error “ The server did not provide a meaningful

DamirDobric wrote “OneWay” Operation style mismatch
on 06-05-2009 13:27

When working with service you sometimes may get following error “ The server did not provide a meaningful

developers.de is a .Net Community Blog powered by daenet GmbH.