Source: https://patents.google.com/patent/US9483313B2/en
Timestamp: 2018-11-16 23:31:19
Document Index: 465525188

Matched Legal Cases: ['Application No. 201110330856', 'Application No. 201110330856', 'Application No. 201110330856', 'Application No. 2011318494', 'Application No. 2011318494', 'Application No. 2011318494', 'Application No. 2013', 'Application No. 2011318494', 'Application No. 201110330856', 'Application No. 201110330856']

US9483313B2 - Availability management for reference data services - Google Patents
Availability management for reference data services Download PDF
US9483313B2
US9483313B2 US12907979 US90797910A US9483313B2 US 9483313 B2 US9483313 B2 US 9483313B2 US 12907979 US12907979 US 12907979 US 90797910 A US90797910 A US 90797910A US 9483313 B2 US9483313 B2 US 9483313B2
US12907979
US20120096093A1 (en )
Rene Jacco Bouw
Various aspects for scaling an availability of information are disclosed. In one aspect, a response performance associated with responding to data consumption requests is monitored. A characterization of the response performance is ascertained, and a scaling of resources is facilitated based on the characterization. In another aspect, a data consumption status indicative of data consumed is ascertained. Here, a scalability interface is provided, which displays aspects of the status, and receives an input from a content provider. An allocation of resources is then modified in response to the input. In yet another aspect, a response performance associated with responding to data consumption requests is monitored. An application programming interface (API) call is generated based on a characterization of the response performance, and transmitted to a content provider. An API response is then received from the content provider indicating whether a scaling of resources for hosting the data was performed.
The subject disclosure relates to scaling resources to facilitate the availability of data in connection with providing information as a service.
Web services are typically built with a certain audience size in mind, wherein the data centers/infrastructure that host and make the data services available are built and resourced with these goals in mind. However, as Web services become more popular, increased consumption can bring such services down as a result of too many requests to read. Namely, there are sometimes insufficient resources to adequately respond to the increase in requests. Similarly, a content provider may over-allocate resources in circumstances where data consumption decreases, which results in the content provider unnecessarily paying for unused resources. As a result, today, dealing with significant increases or decreases in demand for web services for data is a fragmented problem with no common solution.
In accordance with one or more embodiments and corresponding disclosure, various non-limiting aspects are described in connection with providing information as a service from any platform. In one such aspect, a method that facilitates a scalable availability of information is provided. The method can include receiving a plurality of requests directed towards a consumption of data associated with a content provider. The embodiment further can include monitoring a response performance associated with responding to the plurality of requests, as well as determining a characterization of the response performance. A scaling of resources allocated for the data is then facilitated based on the characterization.
In another aspect, a method for facilitating a scalable availability of information is provided. A communication between a content provider and a server is established, and a data consumption status is ascertained. Here, the data consumption status is indicative of content provider data consumed via the server. The method can further include providing the content provider with a scalability interface. For this embodiment, the scalability interface displays at least one aspect of the data consumption status to the content provider, and also receives an input from the content provider. An allocation of data availability resources associated with the content provider is then modified in response to the input.
In yet another aspect, an additional method is provided which facilitates a scalable availability of information. This embodiment includes monitoring a response performance associated with responding to data consumption requests. Here, the data consumption requests are requests for data hosted by a content provider. The method further includes generating an application programming interface (API) call based on a characterization of the response performance, and transmitting the API call to the content provider. An API response is then received from the content provider, which indicates whether a scaling of resources for hosting the data was performed, and such that a processing of the data consumption requests is modified according to the scaling of resources.
FIG. 1 illustrates an exemplary system that facilitates a scaling of resources according to an embodiment;
FIG. 2 is a block diagram illustrating an exemplary resource management unit that facilitates scaling resources according to an embodiment;
FIG. 3 is a flow diagram illustrating an exemplary non-limiting embodiment for scaling resources according to an embodiment;
FIG. 4 illustrates an exemplary interface that facilitates scaling resources according to an embodiment;
FIG. 5 is a block diagram illustrating an exemplary scalability interface that facilitates scaling resources according to an embodiment;
FIG. 6 is a flow diagram illustrating an exemplary non-limiting embodiment for providing an interface to facilitate scaling resources according to an embodiment;
FIG. 7 illustrates an exemplary system that facilitates an external scaling of resources according to an embodiment;
FIG. 8 is a block diagram illustrating an exemplary application programming interface (API) unit that facilitates scaling resources according to an embodiment;
FIG. 9 is a flow diagram illustrating an exemplary non-limiting embodiment for scaling resources according to an embodiment;
As discussed in the background, Web services are typically built with a certain audience size in mind, wherein the data centers/infrastructure that host and make the data services available are built and resourced with these goals in mind. However, as Web services become more popular, increased consumption can bring such services down as a result of too many requests to read, wherein there are insufficient resources to handle the responses, or other unpredictable variations can occur. If a global information marketplace is desired, it would be desirable for the architecture of such marketplace to overcome these limitations by providing a way for content providers to scale their data centers up or down, as appropriate, whether the data is hosted internal or external to the management system.
The various embodiments disclosed herein are directed to scale out systems and methods, as well as to interfaces used to communicate with content providers to facilitate such scaling of resources, and to the communications attendant to such systems, methods and interfaces.
Resource Scaling System
FIG. 1 illustrates an exemplary system that facilitates scaling of resources associated with information provided as a service from any platform. As illustrated, system 100 may include resource management unit 120, consumers 130, and content providers 140, which are communicatively coupled via network 110. Resource management unit 120 is configured to manage data consumption requests from consumers 130 for data associated with content providers 140. Moreover, resource management unit 120 can monitor the volume and/or status of data consumption requests corresponding to particular content providers, wherein resources allocated to such data can then be scaled appropriately. For instance, if the content provider's data is hosted by resource management unit 120, an internal scaling operation can be performed, wherein scalable databases 122 are removed and/or replicated appropriately. However, if the consumed data is hosted by content providers 140, and/or a third party, resource management unit 120 can notify content providers 140 of dips and/or spikes in response times so that content providers 140 can remove and/or replicate databases, e.g., create additional instances of databases, accordingly.
Referring next to FIG. 2, a block diagram of an exemplary resource management unit that facilitates a scalable availability of information according to an embodiment is provided. As shown, resource management unit 200 can include processor component 210, memory component 220, communication component 230, monitoring component 240, evaluation component 250, scaling component 260, generation component 270, and billing component 280.
In one aspect, processor component 210 is configured to execute computer-readable instructions related to performing any of a plurality of functions. Processor component 210 can be a single processor or a plurality of processors dedicated to analyzing information to be communicated from resource management unit 200 and/or generating information that can be utilized by memory component 220, communication component 230, monitoring component 240, evaluation component 250, scaling component 260, generation component 270, and/or billing component 280. Additionally or alternatively, processor component 210 can be configured to control one or more components of resource management unit 200.
In another aspect, memory component 220 is coupled to processor component 210 and configured to store computer-readable instructions executed by processor component 210. Memory component 220 can also be configured to store any of a plurality of other types of data including generated by any of communication component 230, monitoring component 240, evaluation component 250, scaling component 260, generation component 270, and/or billing component 280. Memory component 220 can be configured in a number of different configurations, including as random access memory, battery-backed memory, hard disk, magnetic tape, etc. Various features can also be implemented upon memory component 220, such as compression and automatic back up, e.g., use of a Redundant Array of Independent Drives configuration.
In yet another aspect, resource management unit 200 includes communication component 230, which is coupled to processor component 210 and configured to interface resource management unit 200 with external entities. For instance, communication component 230 can be configured to receive data consumption requests for data associated with a particular content provider.
As illustrated, resource management unit 200 can further include monitoring component 240 and evaluation component 250. Within such embodiment, monitoring component 240 is configured to monitor a response performance associated with responding to the data consumption requests, whereas evaluation component 250 is configured to ascertain a characterization of the response performance.
Resource management unit 200 can also include scaling component 260, which is configured to facilitate a scaling of resources allocated for the data based on the characterization. To this end, it is noted that scaling component 260 can be configured to facilitate such scaling in any of a plurality of ways. For instance, it is contemplated that scaling component 260 can be configured to facilitate a scaling of resources performed external to resource management unit 200. Indeed, since it is contemplated that content providers themselves can host their data, scaling component 260 can be configured to generate response performance status messages, which are communicated to the content provider via communication component 230. In a particular embodiment, generation component 270 can be included and configured to generate an application programming interface (API) call to the content provider, wherein the API call includes a request associated with the at least one aspect of the response performance, e.g., a warning message, a mandatory scaling message, etc. An API response to the request can then be received from the content provider, wherein the response identifies a scaled set of locations associated with the data, e.g., locations of additional databases allocated by the content provider.
Scaling component 260, however, can also be configured to facilitate a scaling of resources performed within resource management unit 200. Within such embodiment, resource management unit 200 hosts the content provider's data within a set of replicated databases, such that scaling component 260 is configured to scale resources by removing and/or adding a replica database. Content providers can also be provided with a scalability interface to facilitate receiving instructions from the content provider associated with the scaling of resources allocated to the content provider.
In a further aspect, resource management unit 200 includes billing component 280. Within such embodiment, billing component 280 can be configured to monetize the scaling of resources allocated to the content provider. Moreover, it is contemplated that costs associated with scaling resources, either up or down, can be automatically quantified. Accordingly, actual and/or hypothetical costs associated with the scaling of resources can be made readily available via billing component 280.
FIG. 3 is a flow diagram illustrating an exemplary non-limiting embodiment for scaling resources according to an embodiment. At 300, requests directed towards a consumption of data associated with a content provider are received. A response performance associated with responding to the requests is then monitored at 310, followed by a characterization of the response performance at 320. A scaling of resources allocated for the data is then facilitated based on the characterization at 330.
FIG. 4 illustrates an exemplary interface that facilitates a scaling of resources according to an embodiment. As illustrated, interface 400 can include display 410, control panel 420, and scaling adjustment 430. For this particular embodiment, it is contemplated that interface 400 is provided to content providers so that they can seamlessly scale resources, as desired. To this end, display 410 can be configured to display any of various aspects associated with processing data consumption requests, either currently, in the future, or in the past. For example, a graphical representation of a number of data requests received over time can be displayed, as shown. Control panel 420 can then be used to toggle between different parameters including, for example, different business metrics (e.g., costs over time, rather than number of data requests) and/or different display types (e.g., different graph types).
As illustrated, interface 400 can also include scaling adjustment 430. Here, since content providers can prefer to scale resources in terms of business metrics, e.g., costs, number of requests, etc., scaling adjustment 430 can be included, wherein content providers simply slide multiplier knob 434 across scaling adjustment 430, as desired. For example, a baseline indicator 432 can be provided, wherein sliding multiplier knob 434 to the right increases a business metric multiplier, e.g., scales resources up, whereas sliding multiplier knob 434 to the left decreases a business metric multiplier, e.g., scales resources down.
Referring next to FIG. 5, a block diagram illustrates an exemplary scalability interface that facilitates scaling resources in accordance with various aspects. As illustrated, scalability interface 500 can include processor component 510, memory component 520, status component 530, display component 540, input component 550, modification component 560, and conversion component 570.
Similar to processor component 210 in resource management unit 200, processor component 510 is configured to execute computer-readable instructions related to performing any of a plurality of functions. Processor component 510 can be a single processor or a plurality of processors dedicated to analyzing information to be communicated from scalability interface 500 and/or generating information that can be utilized by memory component 520, status component 530, display component 540, input component 550, modification component 560, and/or conversion component 570. Additionally or alternatively, processor component 510 can be configured to control one or more components of scalability interface 500.
In another aspect, memory component 520 is coupled to processor component 510 and configured to store computer-readable instructions executed by processor component 510. Memory component 520 can also be configured to store any of a plurality of other types of data including data generated by any of status component 530, display component 540, input component 550, modification component 560, and/or conversion component 570. Here, it is noted that memory component 520 is analogous to memory component 220 in resource management unit 200. Accordingly, it can be appreciated that any of the aforementioned features/configurations of memory component 220 are also applicable to memory component 520.
As illustrated, scalability interface 500 can also include status component 530 and display component 540. Within such embodiment, status component 530 is configured to ascertain a data consumption status indicative of content provider data consumed, whereas display component 540 is configured to display any of various aspects of the data consumption status to the content provider. Here, it is contemplated that such aspects of the data consumption status can be displayed in any of a plurality of ways. For instance, display component 540 can be configured to provide a graphical representation of the data consumption status, e.g., a bar graph tracking a number of data requests over time.
Scalability interface 500 can further include input component 550 and modification component 560. Within such embodiment, input component 550 is configured to receive an input from a content provider, whereas modification component 560 is configured to modify an allocation of data availability resources associated with the content provider in response to the input. To facilitate such modifications, scalability interface 500 can also include conversion component 570, which is configured to perform a conversion between scalability metrics and business metrics. Moreover, a particular business metric is convertible into a corresponding scalability metric, whereas a particular scalability metric is convertible into a corresponding business metric. In an aspect, scalability metrics can be associated with any of a plurality of metrics directly related to a processing of the content provider's data consumption, e.g., a capacity to process a number of queries per unit of time, whereas business metrics can be associated with any of a plurality of business-related metrics, e.g., a demand associated with the content provider data, a cost of hosting a scaled amount of the content provider data, etc. Indeed, since content providers can prefer to enter business metrics rather than scalability metrics, various tools for toggling between such metrics can be provided. For instance, in an aspect, input component 550 can be configured to receive the content provider's input as a multiplier of a desired business metric, wherein conversion component 570 is configured to convert the desired business metric into a corresponding scalability metric based on the multiplier. To this end, input component 550 can be implemented as a multiplier knob, wherein the multiplier is ascertained from the content provider via the multiplier knob.
FIG. 6 is a flow diagram illustrating an exemplary non-limiting embodiment for providing a user interface to scale resources according to an embodiment. At 600, a communication between a content provider and a server is established. Next, at 610, a data consumption status is ascertained, which is indicative of content provider data consumed via the server. A scalability interface is then provided to the content provider at 620, which displays aspects of the data consumption status, and also receives an input from the content provider. An allocation of data availability resources associated with the content provider is then modified in response to the input at 630.
FIG. 7 illustrates an exemplary system that facilitates an external scaling of resources according to an embodiment. For this particular embodiment, resource management unit 710 is configured to manage data consumption requests for data hosted by content providers 720 and/or a third party within scalable databases 722. Moreover, resource management unit 710 can be configured to notify content providers 720 of response performance associated with a consumption of the content provider's data so that content providers 720 can remove and/or replicate scalable databases 722 accordingly. In an aspect, resource management unit 710 can transmit API calls to content providers 720, wherein API responses to those API calls are subsequently provided to resource management unit 720. For example, API call indicating that a particular performance threshold has been exceeded can be provided to content providers 720, wherein an API response can then be provided to resource management unit 710 indicating if/how a scaling of scalable databases 722 has been performed, e.g., providing a location of new replicated databases.
Referring next to FIG. 8, a block diagram illustrates an exemplary application programming interface (API) unit that facilitates scaling resources in accordance with various aspects. As illustrated, API unit 800 can include processor component 810, memory component 820, monitoring component 830, generation component 840, communication component 850, and triggering component 860.
Similar to processor components 210 and 510 in resource management unit 200 and scalability interface 500, respectively, processor component 810 is configured to execute computer-readable instructions related to performing any of a plurality of functions. Processor component 810 can be a single processor or a plurality of processors dedicated to analyzing information to be communicated from API unit 800 and/or generating information that can be utilized by memory component 820, monitoring component 830, generation component 840, communication component 850, and/or triggering component 860. Additionally or alternatively, processor component 810 can be configured to control one or more components of API unit 800.
In another aspect, memory component 820 is coupled to processor component 810 and configured to store computer-readable instructions executed by processor component 810. Memory component 820 can also be configured to store any of a plurality of other types of data including data generated by any of monitoring component 830, generation component 840, communication component 850, and/or triggering component 860. Here, it is noted that memory component 820 is analogous to memory components 220 and 520 in resource management unit 200 and scalability interface 500, respectively. Accordingly, it can be appreciated that any of the aforementioned features/configurations of memory components 220 and 520 are also applicable to memory component 820.
As illustrated, API unit 800 can also include monitoring component 830 and generation component 840. Within such embodiment, monitoring component 830 is configured to monitor a response performance associated with responding to data consumption requests for data hosted by a content provider, whereas generation component 840 is configured to generate an API call based on a characterization of the response performance.
In another aspect, API unit 800 includes communication component 850, which is coupled to processor component 810 and configured to interface API unit 800 with external entities. For instance, communication component 850 can be configured to transmit the API call generated by generation component 840 to the content provider. Communication component 850 can also be configured to receive an API response from the content provider, wherein such response indicates whether a scaling of resources for hosting the data was performed. Within such embodiment, a processing of the data consumption requests can then be modified according to the scaling of resources.
In a further aspect, it is contemplated that API calls are generated/transmitted according to a tiered characterization of the response performance. Within such embodiment, triggering component 860 can be included, wherein triggering component 860 is configured to determine when the response performance exhibits a particular characterization based on any of a plurality of tiered performance thresholds. For instance, triggering component 860 can be configured to detect a triggering of a warning threshold, wherein the API call includes a warning message indicating that the response performance has exceeded a pre-determined “warning” threshold, e.g., at 25% slowdown.
Triggering component 860 can also be configured to detect a triggering of a mandatory scaling threshold, wherein the API call includes a mandatory scaling message indicating that the response performance has exceeded a pre-determined “mandatory scaling” threshold, e.g., at 50% slowdown. Here, it is noted that particular details can be included in the API call and/or API response to facilitate such a mandatory scaling threshold. For instance, the API call can include an indication of a current number of replicas of the data, a response time associated with the triggering of the mandatory scaling threshold, and/or an average response time, whereas the API response can include an indication of a new number of replicas of the data, a location of a new data source associated with the data, and/or a status of a scaling procedure, performed by the content provider and/or a third party associated with the content provider.
More severe tiers are also contemplated, e.g., at 50% slowdown. For instance, triggering component 860 can be configured to detect a triggering of a policy modification threshold. Within such embodiment, in response to the triggering of the policy modification threshold, a processing of the data consumption requests can include a modification of a cache policy associated with the data consumption requests.
FIG. 9 is a flow diagram illustrating an exemplary non-limiting embodiment for providing a user interface to scale resources according to an embodiment. At 900, a response performance associated with responding to data consumption requests is monitored. For this particular embodiment, the data consumption requests are requests for data hosted by a content provider. An application programming interface (API) call is then generated at 910 based on a characterization of the response performance. Next, at 920, the API call is transmitted to the content provider. An API response is then received from the content provider at 930, which indicates whether a scaling of resources for hosting the data was performed. Within such embodiment, a processing of the data consumption requests is modified according to the scaling of resources.
By way of some additional background, today, while information can be obtained over networks, such as the Internet, today's offerings tend to the proprietary in terms of access and framework, and are thus limited in terms of third party provider participation. For instance, currently, there is no adequate business model for commercial content providers to publish their data in a way that does not relinquish at least some of the value of such commercial content, and thus historically, owners of valuable content have tended to expose that content through limited proprietary means. Or, in instances where storage of such content is provided by secure cloud storage providers, there is little value in storage alone when a consumer wades through thousands of tables to potentially find an item of interest as a result. In addition, even where cloud storage providers attempt to collect data from various providers, at best such providers can boast a modest, small or incomplete catalog of data.
Much of the stunting of potential growth in this area has been the result of mistrust over handling and IP, e.g., copyrights. In short, big players don't trust cloud providers with crown jewels because a single compromise can end the value of the data. In addition, such cloud providers to date have had a weak position with respect to information workers who wish to extract value from such data for their informational needs, and in addition, due to the proprietary nature of such systems, developers have thus far had limited ability to expand tools for developing informational capabilities.
Thus, in one aspect, the account key provided by the infrastructure for information as a service as described for one or more embodiments herein is the developer's private key. This key enables billing and reporting on content used in connection with the developer's applications. As such, this private developer key is not to be shared without purpose, and precautions in securing the key are to be taken where developing native applications running on mobile or desktop solutions and planning to integrate the key as part of the deployment. For example, cryptographic storage can be used to ensure the key is not cracked.
In addition to the account key, which is used to track the application consuming the content, the user ID can be a unique user ID that is a globally unique identifier (GUID) that represents the developer's individual users. This field allows billing for content that is priced on a per-user basis programmatically. For example, if a developer is developing a mobile application with an individual user consuming the application, the developer returns the same GUID each time requests are made on behalf of that individual user. However, if the developer is developing a web portal and issuing web service requests on behalf of a variety of users, it is up to the developer to assign a new GUID for each user visiting the portal. For example, each registered user can be assigned a GUID or each IP address/port combination can be assigned a user ID GUID, etc.
While REST APIs can be constructed on any platform to consume content from the infrastructure for information as a service as described for one or more embodiments herein, in one embodiment, proxy classes can be dynamically generated for services in C#. Achieving this is a matter of downloading the object models, adding them to the current developer project, and updating the account and user values, e.g., unique user values.
Benefits for Content Partners include: (a) easy publication and onboarding process regardless of blob data, structured data, or dynamic web services, (b) developer tooling on the selected platform to ease development, e.g., via Visual Studio and .NET or other runtime system development, (c) exposing developer content to global developer and information worker community, (d) content discovery and integration inside pre-existing content consumption applications and (e) a scalable cloud computing platform handles storage, delivery, billing, and reporting on behalf of all parties.
Accordingly, the infrastructure solves a current customer and developer pain point with a potentially significant revenue upside, creates business intelligence opportunities attached with instant data for modeling, reporting, analysis and trending and creates adoption and stickiness for any platform by encouraging data owners to store their data via the infrastructure, thereby differentiating the infrastructure's value proposition when compared with conventional cloud storage environments.
FIG. 11 is a block diagram generally illustrating the various parties that can participate in an ecosystem providing information as a service as described herein. For instance a set of network accessible information services 1100 provide access to a variety of trusted or untrusted data stores 1110, depending on the sensitivity or other characteristics of the data. As shown, thus, what type of data store, 1112, 1114, . . . , 1116 is not so important since the ecosystem supports any kind of data, blob, structured, unstructured, etc. As mentioned, the system includes publishers 1120 that add data to the ecosystem, subscribers 1130 that consume the data and application developers or providers 1150 who help consumption of the data with their applications. An access information generator 1170 can also govern access to the data by various parties through maintaining or enforcing account information, key information, etc. In this respect, content owners 1160 can span any of the roles in that a content owner 1160 can be a publisher 1120, a subscriber 1130 and/or an application developer as well. In one aspect, the common infrastructure for all parties enables administration 1165, auditing 1175, billing 1175 as well as other desired ancillary services to the data transactions occurring across the infrastructure.
1. A method performed by a management unit that receives and manages a plurality of data requests for data stored in at least one database hosted by a content provider, the management unit being communicatively coupled between the content provider and a consumer of the data via a network, the method comprising:
determining a characterization of a response performance associated with responding to the plurality of data requests;
sending a resource request associated with the characterization of the response performance to the content provider; and
receiving a response from the content provider that identifies one or more locations of one or more additional resources that are allocated by the content provider responsive to the resource request.
2. The method according to claim 1, wherein said sending comprises sending an application programming interface (API) call to the content provider including the resource request.
3. The method according to claim 1, wherein the one or more additional resources allocated include a replica database.
receiving scalability input from the content provider via a scalability interface including receiving instructions from the content provider associated with the one or more additional resources that are allocated.
determining a data consumption status indicative of content provider data hosted by a content provider, the data consumption status being based on a plurality of requests for the content provider data, the plurality of requests being received and managed by a management unit that is communicatively coupled between the content provider and a consumer of the content provider data via a network;
receiving an input from the content provider via a scalability interface that displays at least one aspect of the data consumption status to the content provider;
allocating, by the scalability interface, one or more additional data availability resources for providing the content provider data in response to the input; and
providing to the management unit an identification of one or more locations of the one or more additional data availability resources that are allocated by the scalability interface in response to the input.
6. The method of claim 5, wherein the receiving the input includes receiving a business metric from the content provider, and further comprising:
converting the business metric to a scalability metric, and wherein said allocating comprises allocating the one or more additional data availability resources based on the scalability metric.
7. The method of claim 6, wherein the receiving the business metric includes receiving a metric associated with at least one of a demand associated with the content provider data or a cost of hosting a scaled amount of the content provider data and wherein the converting includes converting the business metric to a capacity metric associated with a capacity to process a number of queries per unit of time or number of data transactions per unit of time.
8. The method of claim 6, wherein the receiving the input includes receiving a multiplier of a given business metric, and wherein the converting includes converting the scalability metric based on the multiplier.
9. The method of claim 8, wherein the receiving the input via the scalability interface includes receiving the input via a variable multiplier user interface element of the scalability interface from the content provider.
10. The method of claim 5, wherein the receiving the input via the scalability interface includes receiving the input from an interaction with a graphical representation of the at least one aspect of the data consumption status via the scalability interface.
11. A method that facilitates scalable availability of information that is performed by a management unit that receives and manages a plurality of data consumption requests for data stored in at least one database hosted by a content provider, the management unit being communicatively coupled between the content provider and a consumer of the data via a network, the method comprising:
monitoring a response performance associated with responding to data consumption requests for data hosted by a content provider;
generating an application programming interface (API) call based on a characterization of a response performance associated with responding to the data consumption requests;
transmitting the API call to the content provider; and
receiving a response to the API call from the content provider indicating whether a scaling of resources for hosting the data was performed based on the characterization of the response performance and further indicating one or more locations of one or more additional resources that are allocated by the content provider responsive to the API call.
12. The method according to claim 11, wherein the generating includes generating the API call according to a tiered characterization of the response performance based on a plurality of tiered performance thresholds.
detecting a triggering of a warning threshold, and wherein the transmitting the API call includes transmitting a warning message associated with the characterization of the response performance.
detecting a triggering of a mandatory scaling threshold, wherein the transmitting the API call includes transmitting a mandatory scaling message associated with the characterization of the response performance.
15. The method according to claim 14, wherein the transmitting the API call includes transmitting at least one of an indication of at least one of a current number of replicas of the data, a response time associated with the triggering of the mandatory scaling threshold, or an average response time.
16. The method according to claim 14, wherein the response further indicates at least one of a new number of replicas of the data or a status of a scaling procedure.
detecting a triggering of a policy modification threshold, wherein processing of the data consumption requests includes modifying a cache policy associated with the data consumption requests.
18. The method according to claim 1, wherein the sending includes sending the request according to a tiered characterization of the response performance based on a plurality of tiered performance thresholds.
detecting a triggering of a warning threshold, and wherein sending the request to the content provider includes sending a warning message associated with the characterization of the response performance.
a management unit that is configured to receive and manage a plurality of data requests for data stored in at least one database hosted by a content provider, the management unit being configured to be communicatively coupled between the content provider and a consumer of the data via a network, the management unit configured to:
determine a characterization of a response performance;
send a resource request associated with the characterization of the response performance to the content provider; and
receive a response from the content provider that identifies one or more additional resources that are allocated by the content provider responsive to the resource request.
21. A computer-readable memory storing computer-executable instructions that, in response to execution by a computing device comprising a management unit that receives and manages a plurality of data requests for data stored in at least one database hosted by a content provider, the management unit being communicatively coupled between the content provider and a consumer of the data via a network, cause the computing device to perform operations comprising:
determining a characterization of a response performance;
receiving a response from the content provider that identifies one or more additional resources that are allocated by the content provider responsive to the resource request.
a memory component containing computer-readable instructions, which, when executed by the processor component, is configured to:
determine a data consumption status indicative of content provider data hosted by a content provider, the data consumption status being based on a plurality of requests for the content provider data, the plurality of requests being received and managed by a management unit that is communicatively coupled between the content provider and a consumer of the content provider data via a network;
receive an input from the content provider via a scalability interface that displays at least one aspect of the data consumption status to the content provider;
allocate, by the scalability interface, one or more additional data availability resources for providing the content provider data in response to the input; and
provide an identification of the one or more additional data availability resources that are allocated by the scalability interface in response to the input to the management unit.
23. A computer-readable memory storing computer-executable instructions that, in response to execution by a computing device, cause the computing device to perform operations comprising:
providing an identification of the one or more additional data availability resources that are allocated by the scalability interface in response to the input to the management unit.
a management unit that is configured to receive and manage a plurality of data consumption requests for data stored in at least one database hosted by a content provider, the management unit being configured to be communicatively coupled between the content provider and a consumer of the data via a network, the management unit being configured to:
generate an application programming interface (API) call based on a characterization of a response performance associated with responding to the data consumption requests;
transmit the API call to the content provider; and
receive a response to the API call from the content provider indicating whether a scaling of resources for hosting the data was performed based on the characterization of the response performance and further indicating one or more additional resources that are allocated by the content provider responsive to the API call.
25. A computer-readable memory storing computer-executable instructions that, in response to execution by a computing device comprising a management unit that receives and manages a plurality of data consumption requests for data stored in at least one database hosted by a content provider, the management unit being communicatively coupled between the content provider and a consumer of the data via a network, cause the computing device to perform operations comprising:
receiving a response to the API call from the content provider indicating whether a scaling of resources for hosting the data was performed based on the characterization of the response performance and further indicating one or more additional resources that are allocated by the content provider responsive to the API call.
US12907979 2010-10-19 2010-10-19 Availability management for reference data services Active 2032-06-21 US9483313B2 (en)
US12907979 US9483313B2 (en) 2010-10-19 2010-10-19 Availability management for reference data services
EP20110834812 EP2630584A4 (en) 2010-10-19 2011-09-23 Availability management for reference data services
AU2011318494A AU2011318494B2 (en) 2010-10-19 2011-09-23 Availability management for reference data services
PCT/US2011/053030 WO2012054177A3 (en) 2010-10-19 2011-09-23 Availability management for reference data services
JP2013534921A JP5890839B2 (en) 2010-10-19 2011-09-23 Availability management for the reference data service
CN 201110330856 CN102426541B (en) 2010-10-19 2011-10-18 The availability of reference data management services
US15274838 US20170013052A1 (en) 2010-10-19 2016-09-23 Availability management for reference data services
US15337655 US20170048164A1 (en) 2010-10-19 2016-10-28 Availability management for reference data services
US15274838 Continuation US20170013052A1 (en) 2010-10-19 2016-09-23 Availability management for reference data services
US15337655 Continuation US20170048164A1 (en) 2010-10-19 2016-10-28 Availability management for reference data services
US20120096093A1 true US20120096093A1 (en) 2012-04-19
US9483313B2 true US9483313B2 (en) 2016-11-01
ID=45935064
US12907979 Active 2032-06-21 US9483313B2 (en) 2010-10-19 2010-10-19 Availability management for reference data services
US15274838 Pending US20170013052A1 (en) 2010-10-19 2016-09-23 Availability management for reference data services
US15337655 Pending US20170048164A1 (en) 2010-10-19 2016-10-28 Availability management for reference data services
US (3) US9483313B2 (en)
EP (1) EP2630584A4 (en)
JP (1) JP5890839B2 (en)
CN (1) CN102426541B (en)
WO (1) WO2012054177A3 (en)
US20050190771A1 (en) 2002-09-06 2005-09-01 Matsushita Electric Industrial Co., Ltd. Methods for performing medium dedication in order to ensure the quality of service for delivering real-time data across wireless network
JP2007200347A (en) 2007-03-26 2007-08-09 Hitachi Ltd Virtual computer system and program
US20080313160A1 (en) 2004-11-19 2008-12-18 International Business Machines Corporation Resource Optimizations in Computing Utilities
US20090254552A1 (en) 2008-04-03 2009-10-08 Microsoft Corporation Highly available large scale network and internet systems
WO2010095836A2 (en) 2009-02-18 2010-08-26 Cdnetworks Co., Ltd. File system and method for delivering contents in file system
WO2010109952A1 (en) 2009-03-27 2010-09-30 日本電気株式会社 Resource allocation request device, resource allocation device, resource allocation request method, and resource allocation method
"International Search Report", Mailed Date: May 1, 2012, Application No. PCT/US2011/053030, Filed Date: Sep. 23, 2011, pp. 8.
"Network Socket", Published on: Mar. 19, 2009, Available At: http://web.archive.org/web/20141206004534/http://en.wikipedia.org/wiki/Network-socket, 4 pages.
"Scaleout Software", Published Date: Jul. 19, 2010, 5 pages, http://www.scaleoutsoftware.com/pages/products/scaleout-stateserver.php.
"Websphere eXtreme Scale REST data service", Published Jul. 19, 2010, 3 pages, http://www.ibm.com/developerworks/websphere/downloads/xs rest service.html.
Amila Suriarachchi "Auto Scaling Web Services on Amazon EC2", Published Date: Feb. 12, 2010, 4 pages, http://wso2.org/library/articles/auto-scaling-web-services-amazon-ec2.
English translation of the Summary of Text of the Third Office Action, for Chinese Application No. 201110330856.1, Oct. 20, 2014, 3 pages.
Fifth Office Action Issued in Chinese Patent Application No. 201110330856.1, Mailed Date: Oct. 26, 2015, 7 Pages.
Fourth Office Action and Search Report received for Chinese Patent Application No. 201110330856.1, Mail Date: Apr. 16, 2015, 14 Pages.
Jonathan Purdy, "Data Grids and Service-Oriented Architecure", Published Date: 2007, 13 pages.
Microsoft Corporation "Introducing Windows Server AppFabric", Published Date: Jul. 19, 2010 , 4 pages, http://msdn.microsoft.com/en-us/library/ee677312(printer).aspx.
Office Action Issued in Australia Patent Application No. 2011318494, Mail Date: Aug. 14, 2014, 4 Pages.
Office Action Issued in Australia Patent Application No. 2011318494, Mail Date: Oct. 20, 2014, 8 Pages.
Office Action Issued in Australian Patent Application No. 2011318494, Mail Date: Feb. 3, 2015, 4 Pages.
Office Action Issued in Japanese Patent Application No. 2013-534921, Mailed Date: Oct. 2, 2015, 8 Pages.
Office Action received for Australian Patent Application No. 2011318494, Mail Date: Dec. 19, 2014, 4 Pages.
Office action received for Chinese Application No. 201110330856.1, dated Oct. 20, 2014, English translation and Chinese official version, 14 pages.
Second Office Action Issued in Chinese Patent Application No. 201110330856.1, Mail Date: Apr. 14, 2014, 13 Pages.
WO2012054177A2 (en) 2012-04-26 application
US20170048164A1 (en) 2017-02-16 application
US20120096093A1 (en) 2012-04-19 application
JP2013543626A (en) 2013-12-05 application
US20170013052A1 (en) 2017-01-12 application
EP2630584A4 (en) 2017-07-05 application
WO2012054177A3 (en) 2012-06-28 application
CN102426541A (en) 2012-04-25 application
EP2630584A2 (en) 2013-08-28 application
JP5890839B2 (en) 2016-03-22 grant
CN102426541B (en) 2016-08-17 grant
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOUW, RENEE JACCO;GWORZDZ, LUKASZ;KHOSRAVY, MOE;AND OTHERS;REEL/FRAME:025163/0303
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOUW, RENE JACCO;GWOZDZ, LUKASZ;KHOSRAVY, MOE;AND OTHERS;REEL/FRAME:026768/0469