So what exactly is a 'one-way' operation in web service terms? Perhaps most-importantly, what isn't it? It isn't
a fire-and-forget operation like a UDP broadcast where you have no idea whether your message was successfully delivered, let alone processed by the recipient.
The first incarnation of .NET web services, commonly referred to as ASMX, supported one-way operations. All you had to do was decorate the WebMethod
with an additional SoapDocumentMethod
attribute and set the OneWay
property to true. And because the method is one-way, it can't return any data and has to be marked void
public void DoSomething()
// Simulate some work
We can do exactly the same thing in WCF.
// Simulate some work
So what is the difference between this and a method not marked OneWay? Let's have a look at the response when we invoke a normal, request-response
, service method:
ResponseCode: 200 (OK)
Date:Tue, 19 Aug 2008 07:56:52 GMT
<?xml version="1.0" encoding="utf-16"?>
<DoSomethingResponse xmlns="http://tempuri.org/" />
Cool - so that's what a void response looks lke in SOAP. And what about when we invoke the one-way
ResponseCode: 202 (Accepted)
Date:Tue, 19 Aug 2008 08:00:19 GMT
Server:ASP.NET Development Server/220.127.116.11
In this case we just receive a HTTP code 202 to say our message has been accepted. Thanks!
It's important to note that one-way calls aren't some magical little-known part of the HTTP protocol that IIS takes care of. In fact, they aren't 'one way' at all. The processing framework, in this case ASP.NET or WCF, is responsible for sending that 202 response code. Also, both requests look identical - there isn't any special way of making a one-way HTTP request.
There was of course one other big difference: the one-way service call returned about 10 seconds quicker!
This is because a one-way service call doesn't wait for the call to be processed, only to be delivered
- where delivery includes deserialization of the request. Once this has happened ASP.NET (for asmx) or WCF send the response and start processing the operation on a separate thread.
Thus one-way calls are useful for scenarios where you want to be sure that the message was delivered, but don't care (at least at this stage) whether the message was successfully processed or not.
One way operations are commonly used in asynchronous
enterprise integration patterns. In fact, when using MSMQ based bindings with WCF your operations have
to be marked as one-way operations. This is particularly powerful when used with a transactional MSMQ store which is durable. Therefore I know that when my message has been 'delivered' and is stored safely waiting to be received by the asynchronous recipient.
Next we'll talk about one-way operations and BizTalk R2.
20 Aug 2008
» Next Post:
Stop trying to hack me
« Previous Post:
theJoyOfCode in PC Pro Magazine
Comments are closed for this post.