views:

125

answers:

2

Hi guys,

I've got a WCF service (basicHttpBinding, basic authentication, IIS 6.0) on which I want to restrict the number of calls per hour - on user basis. For example, max 1000 calls per user, per hour (a la Google Maps, etc).

I also want to implement some sort of subscription mechanism, so that users can upgrade their call-limit across various 'price plans'.

I know that I could achieve this with a custom Inspector, backed by a DB containing some sort of 'subscription' table and a counter, but I'd like to avoid reinventing the wheel.

Does anyone have experience doing this? Are there 3rd party projects/libraries that support this out of the box?

Thanks. Eric

A: 

The simplest is to add code to your service, the first thing it does is to check if it has hit the limit, it then updates the counter.

If you look at it from an architecture point of view, it is your business logic and that should normally be implemented in the business layer.

Shiraz Bhaiji
+2  A: 

I don't know if there are any off-the-shelf packages to do this (anyone listening? could be an opportunity!), but here are my quick thoughts on the issue:

  1. Your requirement is "within the last hour" -- let's say "time period" instead of hour, since that can be changed easily. You'll have to keep track of all the calls by that user within the time period, as well as have some kind of mechanism to roll off or archive this data. If you're storing in a database, this can be a significant performance issue, depending on your database, the # of users, the number of calls made per time period, etc. It's pretty easy to design a generic interface that will let you splice in caching if you need it -- but you will also need to track the total time spent retrieving API/service limit info.

  2. Partition the "limited functionality" at the service level if possible -- not the individual operation or method. If you can make the limits apply to use of an entire service and to just specific or individual methods, everything will be easier: the code, the tracking, the user's understanding, etc. In general, that is...

  3. The proper place to intercept & check is not in a message inspector IMHO, but in the OperationInvoker. Install a custom operation invoker via a service-wide behavior, and you will lock down the entire service. In addition, you will have access to post-message-processing info, like the authenticated user name etc. See Skonnard's article on MSDN "Extending WCF via Behaviors" (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6).

Hope this is helpful. If you decide to do it yourself, make sure to handle concurrency (multiple threads calling into your service at the same time)! If you have more questions, it would probably be helpful for folks to know the basic parameters of your situation, like volume of users, calls, scalability concerns (e.g. web farm or single server?). -- Keith

Keith Bluestone
Thanks for your feedback Keith, you've got some good points. Yes, the OperationInvoker seems like the right choice. It seems like I am stuck with a DIY solution :)
Eric Eijkelenboom