RATE PROVISIONER FOR WEB SERVICES

Abstract

Embodiments of methods, apparatuses, devices and systems associated with web services are disclosed.

Description

FIELD

Embodiments of the invention relate to the field of web services, and more specifically to limiting Web services calls at one or more server locations.

BACKGROUND

In the field of web services it may be desirable to limit access to the web services based on contractual terms with one or more web-services subscribers. In addition, under some circumstances, it may be desirable to deliver web services from servers and/or data centers having one or more locations.

BRIEF DESCRIPTION OF DRAWINGS

Subject matter is particularly pointed out and distinctly claimed in the concluding portion of the specification. Claimed subject matter, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference of the following detailed description when read with the accompanying drawings in which:

FIG. 1 is a schematic diagram of an embodiment, such as one or more server locations;

FIG. 2 is a schematic diagram of an embodiment, such as a one or more server locations including call limiters;

FIG. 3 is a flowchart of a method in accordance with an embodiment; and

FIG. 4 is a schematic diagram of an embodiment, including a rate limit provisioner.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the claimed subject matter. However, it will be understood by those skilled in the art that the claimed subject matter may be practiced without these specific details. In other instances, methods, procedures, components and/or circuits that would be known by one of ordinary skill have not been described in detail so as not to obscure the claimed subject matter.

Reference throughout this specification to “one embodiment” or “an embodiment” may mean that a particular feature, structure, or characteristic described in connection with a particular embodiment may be included in at least one embodiment of claimed subject matter. Thus, appearances of the phrase “in one embodiment” and/or “an embodiment” in various places throughout this specification are not necessarily intended to refer to the same embodiment or to any one particular embodiment described. Furthermore, it is to be understood that particular features, structures, and/or characteristics described may be combined in various ways in one or more embodiments. In general, of course, these and other issues may vary with the particular context. Therefore, the particular context of the description and the usage of these terms may provide helpful guidance regarding inferences to be drawn for that particular context.

Likewise, the terms, “and,” “or,” and “and/or” as used herein may include a variety of meanings that will depend at least in part upon the context in which it is used. Typically, “and/or” if used to associate a list, such as A, B and/or C, is intended to mean A, B, or C as well as A, B and C. Though, it should be noted that this is merely an illustrative example and claimed subject matter is not limited to this example.

Unless specifically stated otherwise, throughout this specification, terms such as “processing,” “computing,” “calculating,” “selecting,” “forming,” “enabling,” “inhibiting,” “identifying,” “initiating,” “querying,” “obtaining,” “hosting,” “maintaining,” “representing,” “modifying,” “receiving,” “transmitting,” “storing,” “authenticating,” “authorizing,” “hosting,” “determining” and/or the like refer to actions and/or processes that may be performed by a system, such as a computer and/or other computing platform, capable of manipulating and/or transforming data which may be represented as electronic, magnetic and/or other physical quantities within the system's processors, memories, registers, and/or other information storage, transmission, reception and/or display devices. Accordingly, a computing platform refers to a system or a device that includes the ability to process and/or store data in the form of signals or electronic data. Thus, a computing platform, in this context, may comprise hardware, software, firmware and/or any combination thereof. Further, unless specifically stated otherwise, a process as described herein, with reference to flow diagrams or otherwise, may also be executed and/or controlled, in whole or in part, by a computing platform.

In the field of web services it may, under some circumstances, be desirable to use distributed data centers, or server locations, to process client requests for web services. For example, it may be desirable to have server locations in one or more geographic regions. Furthermore, clients and/or subscribers may agree to one or more contractual terms for web services. However, with distributed data centers it may be difficult to limit a subscriber to the agreed upon terms for the web services. For example, for a web service delivered by several possible server locations, it may be difficult to limit the subscriber appropriately because some service requests may be processed by different server locations.

FIG. 1 depicts a schematic diagram of a system 100 in accordance with an embodiment. With reference to FIG. 1, system 100 may comprise one or more server locations, such as server locations 102, 104, and/or 106. As used herein, the term “server location” may mean a logical and/or physical location of one or more servers organized into one or more groups. As used herein the term “server” refers to a computing platform or computer operable to provide a service to one or more other computing platforms or computers via a network. These services may include access to data and/or access to one or more software applications. For example, in this embodiment, the various server locations may comprise geographically distinct data centers, which may under some circumstances be referred to as co-located data centers, or colos. In this embodiment, a server location may comprise one or more servers operable to perform one or more data center functions, such as process and/or respond to one or more web services calls, such as one or more Application Program interface (API) calls, from one or more clients, such as client 107, for example. A “Web service” as used herein relates to a method of integrating applications using an Internet protocol (1P) infrastructure. In particular examples of a Web service, although claimed subject matter is not limited in these respects, standard protocols may be employed to transmit data objects among components over an Internet protocol such as, for example, HTTP, HTTPS, XML, REST, SOAP, WSDL and/or UDDI standards. Here, XML may be used to tag data objects, SOAP may be used to transfer data objects, WSDL may be used to describe available services and UDDI may be used to list available services. However, these are merely examples of protocols that may enable a Web service and claimed subject matter is not limited in these respects. In one particular embodiment, although claimed subject matter is not limited in these respects, a Web service may allow independently created and implemented applications from different network sources to communicate with one another. In another example, a Web service may comprise a “remote service” that is capable of communicating with one or more components of an application over a data link. Though, it should be noted that these are merely illustrative examples relating to web services and that claimed subject matter is not limited in this regard.

In this embodiment, client 107 may be associated with various subscribers or subscription based web services, for example. Examples of web services may include, but are in no way limited to, web searches, stock quotes, and/or other web based applications. For example, a web search web services provider may limit a subscriber to a determined number of API call per day. Likewise, a stock quotes web services may license their content via a web service and may limit a licensee to a determined number of calls per day. In an embodiment, client 107 may initiate one or more web services calls via a network 105, which, may be directed to one of server locations 102, 104, and/or 106. In this embodiment, the web service calls may be directed to a particular one of the server locations, based on a number of factors including, type of service request, geographic relationship between client 107 and the server locations, downtime for one of the server locations, and/or current resources available at the different server locations to name but a few examples. U.S. Pat. No. 7,231,445 shows one example technique for distributing web service requests. Though, it should be noted that these are merely illustrative examples relating to web services requests and that claimed subject matter is not limited in this regard.

In this embodiment, the server locations may also comprise a rate limiter, such as rate limiter 108 of server location 102, for example. As user herein, a rate limiter may mean a hardware, firmware, or software component operable to monitor web services calls at least in part to prevent subscribers from exceeding an agreed upon limit to their web services usage. For example, a subscriber may agree to limits on their use of one or more web services. These limits may include a limited amount of data transfer during one or more time periods, a limited number of API calls during one or more time periods, limits to access during certain parts of the day, a specific service level limit, such as a data transfer rate limit or and API call rate limit, and/or a prepaid limit to the amount of data and/or API calls, to name but a few examples. In this embodiment, each of server locations 102, 104, and/or 106 may include a rate limiter along a service request pipeline associated with that server location. For example, a rate limiter may be implemented as a server plug-in module for server 110 at server location 104. In this example, the server plug-in module at server 110 may be operable to receive web services calls directed to server location 104 and may be further operable to communicate with one or more plug-ins at various servers associated with server location 104. In addition, a rate limiter may be implemented as a separate server 112 at server location 106. In this example, server 112 may be operable to receive web services calls directed to server location 106. In further addition, a rate limiter may be implemented as a software program on a computing platform providing web services. In further addition, rate limiter 108 may be implemented as a combination of the previously discussed implementations. In addition, communication between the rate limiters and the server locations may be asynchronous and/or synchronous. It should, however, be noted that these are merely illustrative examples of a rate limiter and that claimed subject matter is not limited in this regards.

Regardless of the implementation details of rate limiter 108, rate limiter 108 may be operable to enforce a server location specific web services call limit on a per subscriber, client, or customer basis. For example, rate limiter 108 may, under some circumstances, be configured to receive or intercept one or more web services requests, such as API calls, directed to one of the server locations, such as server location 102. For example, rate limiter 108 may be placed in one or more positions along a web services call processing pipeline, such that rate limiter 108 may be operable to interact with a web services call prior to that call being processed by a server. In this embodiment, rate limiter 108 may extract a client or subscriber ID from the web services request. Rate limiter 108 may further keep track of the web services requests associated with particular subscribers, such as client 107, for example. For example, rate limiter 108 may include a web services call limit associated with client 107, such as a subscriber limit, and, if a web services call is received from client 107 then rate limiter 108 may decrement a counter corresponding to the subscriber limit. As used herein, the terms “call limit” and/or “subscriber limit” may mean a contractual or agreed upon limit for service requests within a specified time period, such as a limit on the number of service requests or API calls within a day, an hour, or a month, for example. In this embodiment, rate limiter 108 may keep a real time record of how many web services calls may remain for client 107. Alternatively, rate limiter 108 may keep a real time record of how many web services calls have been received from client 107 and check that number against a subscriber limit before allowing the web services call to be processed by server location 102, for example. It should be noted that these are merely illustrative examples relating to a call limiter and that claimed subject matter is not limited in this regard.

FIG. 2 is a schematic diagram depicting one or more interactions among server locations in accordance with an embodiment. With regard to FIG. 2, an embodiment 200 may comprise server locations 202 and 204 which may, under some circumstances, communicate via network 206. In this embodiment, server location 202 may comprise one or more servers, such as servers 208, 209, 210, and/or 211, for example. In an embodiment, server location 202 may further comprise a rate limiter 212. In this embodiment, rate limiter 212 may comprise a lease manager 214 and/or a counter 216, for example. Likewise, server location 204 may comprises one or more servers, such as servers 218, 219, 220, and/or 221, for example. In an embodiment, server location 204 may further comprise a rate limiter 222. In this embodiment, rate limiter 222 may comprise a lease manager 224 and/or a counter 226, for example

With regard to FIG. 2, if server location 202 receives a web services call from client 230, rate limiter 212 may, under some circumstances intercept the web services call. Rate limiter 212 may then determine an identity or subscriber associated with client 230 at least in part to determine whether client 230 has web services calls remaining at server location 202, for example. In this embodiment, rate limiter 212 may use counter 216 to determine whether any web services calls remain for client 230. If web services calls remain available for client 230, then rate limiter 212 may allow the web services call to be processed by one of servers 208-211, for example. If, however, there are no web services calls available for client 230 at server location 202, then rate limiter 212 may use lease manager 214 to attempt to lease additional web services calls from another server location, such as server location 204, for example. In this embodiment, rate limiter 212 may send a message to server location 204 to determine whether additional web services calls are available for client 230 at server location 204. Server location 204 may pass this message to rate limiter 222. In this embodiment, rate limiter 222 may then use lease manager 224 and/or counter 226 to determine if web services calls for client 230 are available. If web services calls for client 230 are available, then server location 204 may inform server location 202 that web services calls are available. In response, rate limiter 212 and/or lease manager 214 may request to lease additional web service calls from server location 204. If the request is accepted by server location 204, then lease manager 224 may subtract the leased web services calls from counter 226, while lease manager 214 may add the leased web services calls to counter 216, for example. After completing the lease transaction with server location 204, rate limiter 212 may allow the web services call from client 230 to be processed by one of servers 208-211, and decrement the updated subscriber limit. Likewise, under some circumstances, server location 204 may attempt to lease web services calls from server location 202 at least in part to process web service calls from a client, such as client 230, for example. Though, it should be noted that these are merely illustrative examples of a rate limiter and that claimed subject matter is not limited in these regards.

FIG. 3, comprises a flowchart of a method in accordance with an embodiment. With regard to box 300, a server location may receive a web services request, such as from a client as discussed above. With regard to box 302, the server location may determine whether the client has reached a subscriber limit associated with the web services request. If the server location determines that the subscriber limit has not been reached then at box 304, the server location may decrement the subscriber limit and at box 306 allow the web services request to be processed. If, however, the server location determines that the subscriber limit has been reached, then at box 308 the server location will not be able to process the web services request unless it is able to lease additional web service requests from another server location. Accordingly, at box 310, the server location may determine whether other server locations are available to lease requests from. If no other server locations are available, then at box 312 the server location denies the web services request. For example, the other server locations may have already been contacted and indicated that they did not have any calls available for lease, in which case the server location would deny the web services request. Though, again, it should be noted that these are merely illustrative examples of a method of processing a web service request and that claimed subject matter is not limited in this regard.

If, however, there are other server locations available, then at box 314, the server location will attempt to contact the next server location on a list of server locations. For example, the server location may include a list of all other server locations operable to process certain types of web services requests from particular clients. The server may then contact the next server location on the list whenever it has reached a subscriber limit for a particular client and attempt to lease additional web services calls for that client. For example, at box 316 the next server location will provide the first server location with information detailing the number of subscriber calls left for the client at that location. With regard to box 318, the server location will determine, based on the response received from the contacted other server location, whether additional usage is available for lease. If not, then server location will return to box 310 and attempt to contact a next server location on the list. If no additional server locations are available, then the server location will deny the request. If however, usage is available for lease, then the server location will proceed to box 320, and update the subscriber limit to include the leased usage and decrement the subscriber limit to reflect the current web services request. The server location will then proceed to box 322 and allow the web services request to be processed. Though, again, these are merely illustrative examples of leasing additional webs service requests and claimed subject matter is not limited in this regard.

FIG. 4 is a schematic diagram of a system 400 in accordance with an embodiment. With regard to FIG. 4, system 400 may comprise a server location 402, a server location 404, and/or a rate limit provisioner 406. Server location 402 may comprise servers 407, 408, 409, and/or 410, along with a rate limiter 412, for example. Like wise server location 404 may comprise servers 413, 414, 415, and/or 416, along with a rate limiter 418. In this embodiment, rate limit provisioner 406 may comprise a computing platform operable to communicate with server locations 402 and/or 404 and/or rate limiters 412 and/or 414. For example, rate limit provisioner 406 may be operable to communicate with the server locations to set an initial subscriber limit for each of the server locations. As just one example, the initial subscriber limit may comprise an equal portion of a subscriber's contractually agreed web service calls. In this example, that would mean each server location would initially be assigned one-half of a client's web service requests for a determined period of time. Alternatively, if more than two server locations were involved the initial subscriber limits could still be equally divided among the various server locations. In addition, rate limit provisioner 406 may set the initial subscriber limits based on one or more preferences determined by the subscriber. Though, it should be noted that these are merely illustrative examples of determining an initial subscriber limit and that claimed subject matter is not limited in this regard.

In addition, rate limit provisioner 406 may adapt a distribution of a particular client's web services calls based on one or more learned aspects of that particular client. In the above example, rate limit provisioner 406 may determine over time that a higher percentage of web service calls are processed by server location 402 than by server location 404. This difference could be due to any number of factors, including geographic proximity of the client to the two server locations, differences in capacity at the two server locations, differences in demands placed upon the two server locations by other clients or subscribers, to name but a few factors. In this embodiment, rate limit provisioner 406 may, when distributing subsequent initial call limits for a particular client, take into account such learned characteristics of the particular client when determining an initial distribution. In the above example, rate limit provisioner 406 may distribute the overall subscriber limit for a particular client so that each of server locations 402 and 404 have an initial limit that is proportional to the historic percentage of calls handled by each server location for that particular client. Though, again, it should be noted that these are merely illustrative examples of distributing an initial subscriber limit and that claimed subject matter is not limited in this regard.

In the preceding description, various aspects of claimed subject matter have been described. For purposes of explanation, specific numbers, systems and/or configurations were set forth to provide a thorough understanding of the claimed subject matter. However, it should be apparent to one skilled in the art having the benefit of this disclosure that claimed subject matter may be practiced without the specific details. In other instances, features that would be understood by one or ordinary skill were omitted and/or simplified so as not to obscure claimed subject matter. While certain features have been illustrated and/or described herein, many modifications, substitutions, changes and/or equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and/or changes as fall within the true spirit of claimed subject matter.

Claims

1-25. (canceled)

26. A method, comprising:

determining, by a rate provisioner comprising at least one processor, an allocation of a available web services calls for at least one subscriber between a first server location and at least a second server location, wherein the allocation indicates a first subscriber limit comprising a first threshold number of web services calls allocated to the first server location and a second subscriber limit comprising a second threshold number of web services calls allocated to the at least a second server location; and

transmitting one or more signals from the rate limit provisioner, via an electronic network, to the first server location to set the first subscriber limit and to the at least a second server location to set the second subscriber limit.

27. The method of claim 26, wherein the allocation is determined based at least in part on one or more preferences associated with the at least one subscriber.

28. The method of claim 26, further comprising modifying the allocation of the web services calls for the at least one subscriber between the first server location and the at least a second server location.

29. The method of claim 28, wherein the modifying the allocation is based at least in part on a geographic proximity of the at least one subscriber to the first server location and/or the at least a second server location.

30. The method of claim 28, wherein the modifying the allocation is based at least in part on a demand for the web services calls from additional subscribers at the first server location and/or the at least a second server location.

31. The method of claim 28, wherein the modifying the allocation is based at least in part on respective capacities of the first and/or the at least a second server locations.

32. The method of claim 28, wherein the modifying the allocation is based at least in part on an historic percentage of the web services calls processed by the first server location and/or the at least a second server location.

33. The method of claim 26, wherein a number of the available web services calls for the at least one subscriber is determined based at least in part on a contractual agreement with the at least one subscriber.

34. An apparatus, comprising:

at least one processor to: determine an allocation of available web services calls for at least one subscriber between a first server location and at least a second server location, wherein the allocation indicates a first subscriber limit comprising a first threshold number of web services calls allocated to the first server location and a second subscriber limit comprising a second threshold number of web services calls allocated to the at least a second server location; and initiate transmission of one or more signals to the first server location to set the first subscriber limit and to the at least a second server location to set the second subscriber limit.

35. The apparatus of claim 34, wherein the at least one processor is capable of determining the allocation based at least in part on one or more preferences associated with the at least one subscriber.

36. The apparatus of claim 34, wherein the at least one processor is capable of modifying the allocation of the web services calls for the at least one subscriber between the first server location and the at least a second server location.

37. The apparatus of claim 36, wherein the at least one processor is capable of modifying the allocation based at least in part on a geographic proximity of the at least one subscriber to the first server location and/or the at least a second server location.

38. The apparatus of claim 36, wherein the at least one processor is capable of modifying the allocation based at least in part on a demand for the web services from additional subscribers at the first server location and/or the second server location.

39. The apparatus of claim 36, wherein the at least one processor is capable of modifying the allocation based at least in part on respective capacities of the first and the at least a second server locations.

40. The apparatus of claim 36, wherein the at least one processor is capable of modifying the allocation based at least in part on an historic percentage of the web services calls handled by the first server location and/or the at least a second server location.

41. The apparatus of claim 36, wherein the at least one processor is capable of determining a number of the available web services calls for the at least one subscriber based at least in part on a contractual agreement with the at least one subscriber.

42. An article, comprising: one or more memories having instructions stored thereon which are executable by a processor to:

determine an allocation of available web services calls for at least one subscriber between a first server location and at least a second server location, wherein the allocation indicates a first subscriber limit comprising a first threshold number of web services calls allocated to the first server location and a second subscriber limit comprising a second threshold number of web services calls allocated to the at least a second server location; and

initiate transmission of one or more signals from the rate limit provisioner, via an electronic network, to the first server location to set the first subscriber limit and to the at least a second server location to set the second subscriber limit.

43. The article of claim 42, wherein the instructions are further executable to modify the allocation of the web services calls for the at least one subscriber between the first server location and the at least a second server location.

44. The article of claim 43, wherein the instructions are further executable to modify the allocation based at least in part on a geographic proximity of the at least one subscriber to the first server location and/or the at least a second server location.

45. The article of claim 42, wherein the instructions are further executable determine a number of the available web services calls for the at least one subscriber based at least in part on a contractual agreement with the at least one subscriber.