This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Originally posted by RAEES UZHUNNAN: don't you think you need to restrict this in HTTP layer
That can "work". However:
The username better be part of the URI (highly unlikely for a SOAP web service) or supplied in an HTTP header (and even if it is in the HTTP header then you better have the username in the SOAP envelope too - otherwise the SOAP message would be incomplete). If you have to go rooting around in the POST data to find the username you might as well have the handler chain do the work.
If you throttle in the HTTP layer then you will be issuing HTTP errors, not SOAP faults. Therefore on the client side you have the additional burden of sorting out throttling errors (which aren't part of the WSDL) on top of the more general HTTP errors. As SOAP faults the possibility of throttling errors is evident from the WSDL (the service contract). Furthermore HTTP errors only make sense between the HTTP server and client. The reason for using SOAP is its extensibility. SOAP was designed to travel over a message path that not only involved the initial sender and ultimate receiver but may also involve any number of intermediary SOAP nodes. HTTP errors can only propagate between two adjacent SOAP Nodes - no further; to go back all the way to the initial sender you have to issue a SOAP fault. Now you could constrain yourself to only supporting message paths that only involve two SOAP nodes - the initial sender (the service requestor) and ultimate receiver (the service provider). However, once you start constraining yourself in this fashion then you really need to re-evaluate whether you should be using SOAP in the first place.
Architecturally you could have the client connect to the throttling node that will only forward the request to the service provider if the usage is within limits.