OK, the world is moving to web services. I know that. You know that. So what more is there to discuss? PLENTY!! For instance, how long should it take for a web service to complete?
Well, that's kind of a tricky question. It basically comes down to "what is the web service doing?" Some things should come back quickly. Darn quick, in fact. For instance, if you ask a web service, "What is the name of the person associated with this identifier?" you should be getting a response back in milliseconds. If you are asking a web service "What course marks did this student get in high school?" you should be getting a response back in milliseconds. If you are asking a web service "What are the names of all of the people associated with this school district?" you should be getting a response back in milliseconds.
What? Getting the names of hundreds, potentially thousands of people, in just milliseconds? Are you nuts?
Read carefully what I wrote "... getting a response back in milliseconds." A perfectly valid response is: "Thank you for your request. It is being processed and the results will be made available at a later date." Web services should not be long running processes. If they are long running or have the potential to be long running, then you need to implement some sort of callback mechanism to indicate when processing has finished. This callback mechanism may be an email, a call to another web service with the results, depositing the results in a queue to be picked up later or even a combination of these methods. Indeed, there are literally dozens of ways to get the response back to the caller. What is important to understand is that you do not create a web service that has the potential to run for a long period of time. Ever. I'm serious about this one.
Other than the fact that you are probably going to hit the HTTP timeout, COM+ timeout, or cause an excessive number of locks to be held in the database, why other reasons could their be? Well, imagine from a Denial of Service perspective. If one call to this web service can generate so much synchronous work, what would 10, 100, or even a 1000 simultaneous calls to this web service due to the underlying server? Crash it? Cause it to perform so slowly that everyone gets timed out? Bring down the back end database? "But, Don, this is going to be an internal web service only. What's the problem?" Depending upon which survey you read, anywhere from 10% to 50% of all attacks on web sites are from insiders. Imagine a disgruntled employee and what damage he could do to the system with just a little bit of knowledge.
While this topic is ostensibly about web services, we should not create any service (COM+, Web, WCF enabled) that takes a long time to execute. If you are in the least bit confused about whether something should be synchronous or asynchronous in nature, the odds are it should be asynchronous. Err on the side of caution.
No comments:
Post a Comment