As stated in the first section of this article (.chm file – see note below)
One-way calls do not equate to asynchronous calls. When one-way calls
reach the service, they may not be dispatched all at once and may be
queued up on the service side to be dispatched one at a time… If the
number of queued messages has exceeded the queue’s capacity, then the
client will block, even when issuing a one-way call.
If a one-way call is invoked, when does it return control to the caller? The introduction of the same article states that one-way calls are used for fire-and-forget operations, thereby simulating a kind of asynchronous call.
If a sessionful WCF service has a Login() one-way method which starts the session, when does this method return control to the caller? Does it return before the method is actually executed on the service? If so, how can I be sure that the method was performed on service?
If I wanted the service to return to the client the possible errors that occur during the login procedure, would be an asynchronous call the only way to achieve a fire-and-forget behaviour?
Note: The quote above is taken from an article called WCF Essentials – What You Need To Know About One-Way Calls, Callbacks, And Events by Juval Lowy, and can be found in the October 2006 issue of MSDN magazine. The link above is to a help file (.chm) format on MSDN. If you can’t get the linked CHM file to work (I couldn’t) you can open it with 7zip.
For OneWay calls: The caller will continue to execute as soon as the service call is dispatched or queued. Basically as soon as the service successfully receives the call.
If the client does not get an exception, the service call was (or will be) performed. When the service call actual runs or whether it succeeded or threw an exception is unknown to the client.
This does not make sense. Fire-and-forget by definition means forget the result. It does not return any values or errors to the client. However an asynchronous call is not fire-and-forget and would return errors.