File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes implementing throttling in web services/J2EE Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "implementing throttling in web services/J2EE" Watch "implementing throttling in web services/J2EE" New topic
Author

implementing throttling in web services/J2EE

Anila Mathew
Ranch Hand

Joined: Jun 16, 2004
Posts: 69

We have to implement throttling functionality in our application. Need your suggestion.

Clients will send the request on a web service and we have to restrict the number of request that we will serve for a client like 200 requests per second.

If he becomes a premium customer we will increase it to 400 requests per second.

In another sense number of request that we handle for the client should be configurabe.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Segregate your web services classes from the actual service application and insert a throttling stage between them (presumably overdrawn requests will result in SOAP faults).

Alternately you could throttle the requests right in a JAX-RPC/SOAP Message handler in the request handler chain.

Writing a Handler in JAX-WS
How to create a simple JAX-RPC handler
[ September 25, 2007: Message edited by: Peer Reynders ]
Anila Mathew
Ranch Hand

Joined: Jun 16, 2004
Posts: 69

Thanks Peer
Raees Uzhunnan
Ranch Hand

Joined: Aug 15, 2002
Posts: 126
don't you think you need to restrict this in HTTP layer /

Raees


Sun Certified Enterprise Architect
Java Technology Blog
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: implementing throttling in web services/J2EE