dotnet web services: Our customers have different names SLA’s / Service Level Agreements but use
the same webservice. How do I handle that some users can be allowed to wait
when the load is high while others can’t? One possible scenario could be to
redirect VIPs to a more powerful webfarm than the one the common user uses.
But is it a good solution and, in case it is, can I implement it using some
of the standard features in .net (or perhaps .net v2)?

Regards,

Hi Peter,

Welcome to MSDN newsgroup.
From your description, your webservice will be exposed to multi users each
of which has their own privacy or priority on using the service. Since
they'll request the same webservice address( url), you're wondering any
good means to make the different dispatch/process policy transparent to the
end user, yes?

Based on my experience, as for such scenario, we may need to implement a
facade for the webservice, let the end users all send request to that
facade and let the facade to call the actual service accordring to the
clientuser's information.

And as far as I knew, in the current ASP.NET webservice framework, we can
use SOAPExtension to intercept the webservice call (soapMessage) before
them reach the actual service, we can intercept the SOAPMessage's content
or anyother clientside info in the soapExtension's certain process stage
and do the redirection work there.

#Altering the SOAP Message Using SOAP Extensions
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconalteringsoapmessag
eusingsoapextensions.asp?frame=true

But frankly speaking, SOAPExtension is more appropriate for some lightweigh
interception such as logging , or encription... As for service
redirection or load balance, I'd recommend implement a separate module to
accept all the comming calls and send new request to the actual service.


In addition, the new WS-Routering specification seems particularly
addressing the problem in your scenario. It focus on a standard means to
provide message rountering/dispatching. Currently .net framework 1.x dosn't
buidlin support it, but we've provided the WebService Enhancement which has
implemented the latest specification of the webservice new protocols and
services such as WS-Security, WS-Policy, also WS-Rounting, WS-addressing,
we can find the introduction at the MSDN's webservice dev center:

#Secure, Reliable, Transacted Web Services: Architecture and Composition
http://msdn.microsoft.com/webservices/understanding/advancedwebservices/defa
ult.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp

Also, the following document on the WSE (ws routing) may also be helpful:

#Routing SOAP Messages with WSE
http://msdn.microsoft.com/library/en-us/wse/html/3c921437-9ec0-4b62-8344-c04
f70cd3724.asp?frame=true

Thanks & Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no

As you say, you could use different boxes. That is kinda a brute force
approach, but would definately settle any questions on SLA as they get what
they pay for. If they need better perf, then it is easy to price faster
box(es) for customer X. The other way to go is using a priority queue. You
could "contain" a Thread pool inside a class that implements a priority
queue. It is easy to instrument the queue class for perf info at a single
point. When a request comes in, you queue it in the priority queue. Your
web service thread then blocks on a reset event. The thread pool (or
dedicated thread(s)) service the priority queue dequeueing the highest
priority in order. The last step in the thread pool method is to reset the
event object. This unblocks the web service thread to return the result.
--William

[quoted text, click to view]