I mentioned in an earlier post how the Service Model Runtime normalizes different channel shapes based on the requirements of your OperationContract. One of the adaptations the Service Model Runtime provides is the ability to use one-way methods over
For example, let’s say you have method such as:
If you want to expose this method over
BasicHttpBinding, how does that work? HTTP is fundamentally request-reply based, and as such offers up only
To address this scenario, part of the model for request-reply is a paradigm whereby a channel can optionally support “null” responses. This is exposed through the programming model by calling
). As an additional convenience, if you call
.Close() without having sent a reply we will call
) on your behalf.
HTTP signals a “null” response on the wire by sending a “202 Accepted” with no entity body. Note that for interop purposes we are lax on the client and allow any 200-level response without an entity body to signal null response. TCP/Pipes send a .Net Framing ACK with no entity body. A message-level protocol for request reply can designate a particular schema/action for an “ACK Message” to signal a null response.
On the client you should check for a
null return value from
.SendRequest(). For example:
Messagereply = requestChannel.SendRequest(request);
Console.WriteLine("Called a one-way method."); }
Console.WriteLine("Called a two-way method."); }
ServiceModel, as well as our forthcoming
OneWayBindingElement leverage the “null” response in order to achieve mapping request-response message exchanges to one-way.