Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

implementing throttling in web services/J2EE

 
Anila Mathew
Ranch Hand
Posts: 69
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 69
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Peer
 
Raees Uzhunnan
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
don't you think you need to restrict this in HTTP layer /

Raees
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic