Speed up web services using the SoapDocumentMethod attribute

Oct 30, 2006

I’ve done a lot of web services during the last couple of years and I simply love Service Oriented Architecture using SOAP. The power of using services as a means to create large connected systems are enormous but sometimes it can be a performance bottleneck.

The SOAP protocol in ASP.NET is defined as a response/request operation even if the method returns a void type. That means that the requesting client waits until it gets a response from the web service and that can take a relative long time. For simple logging applications or other simple SOAP calls where you aren’t interested in waiting for the response, you can achieve performance gains by using the SoapDocumentMethod attribute on the web service methods.

What it does is that it instantly returns HTTP status code 200 OK to the requesting client, so it doesn’t have to wait for the entire request to finish processing and it’s built directly into the ASP.NET engine. Here is how to do it:

[WebMethod, SoapDocumentMethod(OneWay = true)]

public void LogError(string errorMessage)

{

  DoSlowOperation(errorMessage);

}

It’s not exactly rocket science but it can remove a potential bottleneck.

* Only $4.95/month ASP.NET & Windows 2008 + IIS 7 Hosting! FREE SQL Included

Comments (4) -

Mats
Mats
10/31/2006 3:56:34 AM #

I always like your ideas, thanks.

 NinjaCross
NinjaCross
10/31/2006 7:57:28 AM #

Theoretically  this could be a good way to improve performances in n-tier soap-driven applications, but I don't think it's a good idea to apply this kind of strategy due to its potential weakness in errors handling.
I mean, since the request is performed on a tier different from the invoker (the interaction is not executed in the same process or at least on the same machine) you cannot directly manage server-side exceptions and anomalous execution conditions.
In this way, an invoked method that immediately returns void (doesn't return nothng)  with HTTP 200 will never give you any information/feedback of the execution condition.
I dont' think this is a bad approach, but I'm pretty sure that this could lead away from common error-handling best-practises.

I.E. your client is periodically invoking a method on a server that performs a "safe" stored procedure on a DB (like indexes refresh) and normally no error conditions are expected and no information are required by the invoker. So this situation would be perfectly driven with your proposal, but how do you manage a (even remote) DB-connection problem ? Your caller will continue to call the method and never knows that the server cannot perform the operation for a connection problem, and this would lead to a errors-log flood.

Probably this isn't the best example, so plz try to understand the behind-concept that I'm trying to expose: the missing of control on the execution flow.

Mads Kristensen
Mads Kristensen
10/31/2006 8:16:35 AM #

NinjaCross, you are right about the error handling and control, but for certain applications you just don't care. For non-mission critical function calls where speed is the essence, this approach is perfectly acceptable.  As I wrote, it is good for applications "where you aren’t interested in waiting for the response". That also means that it is not the right approach for SOAP calls where you ARE interested in the response.

Angelos Petropoulos
Angelos Petropoulos
11/3/2006 6:46:26 PM #

I think you are making a small but important mistake here, you are mixing up the following two scenarios

1. I perform a web service call and the web method I am calling returns void PLUS it can/will not fail, so I am not interested in its response
2. I perform a web service call and I do not care if it succeeds or not

The "OneWay" attribute should only be used in scenario #2 and not #1, as most of the time even if you are not interested in the response of a web method you do assume that the web service call was successful.

It is not best practice, but an exception can actually be thrown from web methods and reach the client; the .NET framework takes care of the serialization and deserialization of the exception. If your code depends on this type of behavior and you simply add the "OneWay" attribute, your code will assume that the call was successful and after calling the web method the rest of the code will be executed before the web method has had a chance to notify you of failure.

Some more information about this property can be found here msdn.microsoft.com/.../...buteclassonewaytopic.asp

Maybe you were already fully aware of this, but it does not come across very clearly in your post so I thought this may benefit others.

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.