Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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:</p> <ol> <li><p>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 <strong>all the calls</strong> 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.</p></li> <li><p>Partition the "limited functionality" <strong>at the service level</strong> 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. <em>In general</em>, that is... </p></li> <li><p>The proper place to intercept &amp; check is not in a message inspector IMHO, but in the <strong>OperationInvoker</strong>. 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 "<a href="http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6" rel="nofollow noreferrer">Extending WCF via Behaviors</a>" (<a href="http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/magazine/cc163302.aspx#S6</a>). </p></li> </ol> <p>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</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload