Skip Navigation LinksHome > View Post

One Way operations in services

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.

[WebMethod]
[SoapDocumentMethod(OneWay=true)]
public void DoSomething()
{
    // Simulate some work
    Thread.Sleep(10000);
}

We can do exactly the same thing in WCF.

[OperationContract(IsOneWay=true)]
void DoSomething()
{
    // Simulate some work
    Thread.Sleep(10000);
}

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)
Connection:Close
Content-Length:140
Cache-Control:private
Content-Type:text/xml; charset=utf-8
Date:Tue, 19 Aug 2008 07:56:52 GMT

<?xml version="1.0" encoding="utf-16"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <DoSomethingResponse xmlns="http://tempuri.org/" />
  </s:Body>
</s:Envelope>
Cool - so that's what a void response looks lke in SOAP. And what about when we invoke the one-way service method?
ResponseCode: 202 (Accepted)
Connection:Close
Content-Length:0
Cache-Control:private
Date:Tue, 19 Aug 2008 08:00:19 GMT
Server:ASP.NET Development Server/9.0.0.0
X-AspNet-Version:2.0.50727
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.

Tags: WCF

 
Josh Post By Josh Twist
5:12 AM
20 Aug 2008

» Next Post: Stop trying to hack me
« Previous Post: theJoyOfCode in PC Pro Magazine

Comments are closed for this post.

© 2005 - 2014 Josh Twist - All Rights Reserved.