Empirical-based dispatch of regulated workloads in cloud environments

Abstract

Mechanisms are provided for dispatching requests to service instances based on data storage boundaries. A request specifying an identity is received and dispatched to a service instance of a data storage boundary, where each data storage boundary is defined by a rule or policy that limits data storage of a particular type of data to a computing device within a specified boundary. In response to determining that the service instance cannot access the data because the data is associated with a different data storage boundary, a feedback response specifying a target location is received from the service instance. A dynamic dispatch rule specifying the identity and the target location is generated, and subsequent requests specifying the identity are processed by executing the dynamic dispatch rule to dispatch the subsequent requests directly to a service instance associated with the target location.

Description

Background Technology

[0001] This application generally relates to improved data processing apparatus and methods, and more specifically to improved computing tools and improved computing tool operation / functions for automatically allocating controlled and / or segmented workloads in a cloud computing environment based on prior experience and feedback.

[0002] Regarding data security, the physical storage location of data is a concern because it can affect data accessibility and who can access it. This concern can be geographical, where national regulations require sensitive data (such as personally identifiable information of a nation's citizens) to be stored within the geographical boundaries of a specific country and the corresponding data network boundaries. This is increasingly becoming a concern for cloud-based computing environments and large-scale data centers that may span various geographical regions and many different countries and potentially different organizations. Being able to control who can access data and how and when individuals can access it is crucial, especially when the data is sensitive in nature. Summary of the Invention

[0003] This summary is provided to introduce some concepts in a simplified form, which will be further described in the specific embodiments herein. This summary is not intended to identify key elements or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0004] In one illustrative embodiment, a method is provided in a data processing system for dispatching requests to service instances based on data storage boundaries. The method includes receiving a first request to access data associated with an identity specified in the first request, and dispatching the first request to a first service instance associated with a first data storage boundary among a plurality of data storage boundaries. Each data storage boundary is defined by a provision or policy that restricts the storage of one or more specific types of data to computing devices within a specified physical or network topology area. The method further includes receiving a feedback response from the first service instance in response to the first service instance determining that the data cannot be accessed because the data is of a type associated with a second data storage boundary different from the first data storage boundary. The feedback response specifies a target location associated with the second data storage boundary. Furthermore, the method includes, in response to receiving the feedback response, automatically generating dynamic dispatch rules for the specified identity and target location, and storing the dynamic dispatch rules in a dynamic dispatch rule database. Additionally, the method includes processing a subsequent second request for the specified identity by at least performing a lookup operation in the dynamic dispatch rule database to find a matching dynamic dispatch rule corresponding to the specified identity, and performing the matching dynamic dispatch rule to directly dispatch the subsequent request to the second service instance associated with the target location. In this way, the mechanism of the illustrative embodiment can automatically generate dynamic dispatch rules that take into account data storage boundaries and bypass most of the network traffic and processing costs associated with the re-dispatch of requests due to different service instances being unable to access data due to data storage boundary provisions / policies.

[0005] In some illustrative embodiments, dispatching a first request to a first service instance includes performing a lookup in a dynamic dispatch rule database against the identity specified in the first request. In response to the failure to find a matching entry for the identity in the dynamic dispatch rule database, a load balancing operation is performed to dispatch the first request to the next available service instance that is the first service instance. In this way, requests can be quickly submitted to the first available service instance, and if a service instance cannot access data due to data storage boundaries, the mechanism of the illustrative embodiments can determine the target location and data storage boundaries to dispatch the request to the appropriate service instance and generate dynamic dispatch rules to handle future such requests for that identity.

[0006] In some illustrative embodiments, receiving a feedback response from a first service instance includes the first service instance requesting data corresponding to the identity in the request from a backend service instance database, and in response to the first service instance not finding data corresponding to the identity in the backend service instance database, the first service instance sending a target location request for the target location of the requested data to a global account management service. Furthermore, such illustrative embodiments also include the first service instance receiving the target location of the data from the global account management service, and the feedback agent of the first service instance sending a feedback response specifying the target location to the data processing system. In this way, the feedback agent can obtain the actual target location of the data requested from the global account management service and provide feedback specifying that target location for automatically generating dynamic dispatch rules for execution when processing subsequent requests for a specified identity.

[0007] In some illustrative embodiments, the feedback response is sent asynchronously by a feedback agent to the data processing system relative to the processing of the first request, and the automatically generated dynamic dispatch rules are executed asynchronously relative to the processing of the first request. In this way, the feedback mechanism and the generation of dynamic dispatch rules can be executed substantially simultaneously with the processing of the first request, or at different time intervals, or in parallel execution paths. That is, the feedback and dynamic dispatch rule generation are independent of the completion of the processing of the first request.

[0008] In some illustrative embodiments, the method further includes dispatching a first request from a first service instance to a second service instance, and receiving data requested in the first request from the second service instance. In these illustrative embodiments, the method further includes generating a response to the first request based on the received data, and sending the response to the requesting computing device that sent the first request. In this way, the first service instance is able to obtain the requested data response from the second service request and provide it back to the requesting computing device, thereby completing the processing of the first request.

[0009] In some illustrative embodiments, processing a subsequent second request includes performing a lookup in a dynamic dispatch rule database for the identity specified in the second request, and, in response to finding a matching dynamic dispatch rule in the database for that identity, executing the matching dynamic dispatch rule to set the data storage boundary corresponding to that identity among a plurality of data storage boundaries as the second data storage boundary. Furthermore, in these illustrative embodiments, the method also includes transmitting the second request to a second service instance, wherein the second service instance is associated with the second data storage boundary. Additionally, in these illustrative embodiments, the method includes receiving data requested by the second request based on processing of the second request at the second service instance to obtain the data requested by the second request from a target location, and transmitting a response to the requesting computing device that sent the second request based on the data received from the target location. In this way, by executing a matching dynamic dispatch rule from the database, the computational and network traffic costs of determining the target location and data storage boundary and their corresponding service instance, as well as the costs associated with re-distributing the request among service instances when the receiving service instance cannot access the requested data due to such a data storage boundary, are avoided.

[0010] In some illustrative embodiments, multiple data storage boundaries are at least one of geographic, geopolitical, or organizational data storage boundaries that specify that data associated with a geographic, geopolitical, or organizational entity cannot be stored outside the corresponding data storage boundary. Any data storage boundary can be utilized, but geographic, geopolitical, or organizational data storage boundaries are used to protect personally identifiable information of individuals associated with the corresponding geographic, geopolitical, or organizational entity. Therefore, the illustrative embodiments operate to meet the requirements for data storage boundaries concerning such entities.

[0011] In some illustrative embodiments, the identity specified in the first request is an API Key corresponding to the data requested for access in the first request, and the data includes personally identifiable information (PII) of one or more accounts in a cloud computing environment, wherein the PII of one or more accounts is restricted to storage within corresponding data storage boundaries across multiple data storage boundaries. In some illustrative embodiments, the data processing system is a global gateway computing system of the cloud computing environment that operates across multiple data storage boundaries in conjunction with multiple different service instances. In some illustrative embodiments, the multiple different service instances are regional identity and access management (IAM) cloud service instances. Again, this allows for the protection of personally identifiable information across multiple data storage boundaries that are part of the cloud computing environment, based on specified rules / policies, and wherein the regional IAM cloud service instance operates within each different data storage boundary.

[0012] In other illustrative embodiments, a computer program product is provided that includes a computer-usable or readable medium having a computer-readable program. When executed on a computing device, the computer-readable program causes the computing device to perform various operations and combinations thereof outlined above in the illustrative embodiments of the method.

[0013] In yet another illustrative embodiment, a system / apparatus is provided. This system / apparatus may include one or more processors and memory coupled to the one or more processors. The memory may include instructions that, when executed by the one or more processors, cause the one or more processors to perform various operations and combinations thereof outlined above in the illustrative embodiments concerning the method.

[0014] These and other features and advantages of the invention will become apparent to those skilled in the art from the following detailed description of exemplary embodiments of the invention. Attached Figure Description

[0015] The invention, its preferred modes of use, and further objects and advantages will be best understood when read in conjunction with the accompanying drawings, and by referring to the following detailed description of illustrative embodiments, in which:

[0016] Figure 1 This is an example diagram illustrating the operation of a global gateway with target services under controlled and segmented workload constraints according to an illustrative embodiment;

[0017] Figure 2 This is an example diagram of data flow between entities in a cloud computing system for automatically and dynamically generating dispatch rules in a global gateway, according to an illustrative embodiment.

[0018] Figure 3 This is an example diagram of the data flow between entities of a cloud computing system for a request, according to an illustrative embodiment, for which there are assignment rules for a specified identity.

[0019] Figure 4 This is an example diagram illustrating the feedback provided by the target service in response to the target service's inability to access the requested data, according to an illustrative embodiment.

[0020] Figure 5 This is an example diagram illustrating a dispatch rule that is automatically and dynamically generated based on feedback received from a target service, according to an illustrative embodiment.

[0021] Figure 6A This is a flowchart outlining example operations of a dispatch rule engine for a global gateway according to an illustrative embodiment.

[0022] Figure 6BThis is a flowchart outlining example operations of a service instance enhanced with a feedback broker according to an illustrative embodiment; and

[0023] Figure 7 This is an example diagram of a distributed data processing system environment in which aspects of the illustrative embodiments can be implemented and at least some of the computer code involved in performing the methods of the present invention can be executed. Detailed Implementation

[0024] As mentioned above, data security is a critical concern in computing environments, particularly regarding personally identifiable (PI) data of specific groups (e.g., citizens of a country, specific employees of a government agency, members of certain groups, organizations, etc.). This is especially true in cloud computing environments, which span multiple geographic regions and involve many different parties, who may be subject to different regulations or no regulations at all depending on their physical location. To address this openness and pervasiveness of cloud computing environments, government regulations have been developed in many cases requiring restrictions on the storage and management of data in these cloud computing environments. For example, these restrictions may require PI data storage and management to be limited to specific physical or virtual locations, defined according to geographic, geopolitical, or organizational regions as defined by regulations or policies. Locations that are part of the same geographic, geopolitical, or organizational region are referred to herein as “boundaries.” It should be understood that such boundaries may be associated with corresponding geographic, geopolitical, or organizational entities (e.g., countries, ethnic groups, commercial enterprises, etc.).

[0025] For example, in 2011, the U.S. federal government established the Federal Risk and Authorization Management Program (FedRAMP), which sought to provide a cost-effective, risk-based approach to the adoption and use of cloud services by the U.S. federal government. As part of FedRAMP, the “boundary” is the U.S. data center, meaning that PI data associated with a FedRAMP-compliant cloud account only needs to be stored and managed in U.S. data centers. Furthermore, requests need to be routed by a global gateway because the boundary where the requested data resides may not be known to the caller. A global gateway is a component that allows data to flow from the Internet to the service infrastructure and back. Based on the client’s origin, the global gateway uses the fastest network path between the client and the service infrastructure. An example of such a global gateway could be the Identity and Access Management (IAM) Global Gateway Computing System available from IBM in Armonk, New York.

[0026] Therefore, requests for accessing data (such as account data) are routed through the global gateway, but these requests may or may not specify the location where the requested data is stored. That is, the requesting computing device, the application running on the requesting computing device, etc., can send a request including an account identifier (ID), which can be used to directly associate the account ID with a location. However, in other cases, the request may not specify an account relationship, and therefore will require expensive computation to determine where the requested data is stored, where "cost" is a performance metric measured based on the time required to process the request, the number of processing cycles required, or other computer performance metrics.

[0027] A global gateway is a service provided by a team or even a company different from the target service itself. From a separation of concerns perspective, building knowledge about the backend service into the global gateway is not a good idea. Furthermore, granting the global gateway access to backend data can be dangerous, as security exposure on the global gateway will immediately threaten the backend data, whereas if the global gateway only provides access to the service, there is another security layer protecting the backend data. Therefore, the global gateway cannot access the backend data, and only the target service can determine the location of the requested data. Consequently, determining the location of the requested data cannot be performed by the global gateway for all requests, and therefore, requests sent from the global gateway to the target service can often result in requests having to be rerouted through the global gateway back to the determined location of the requested data.

[0028] As an example, consider an Application Programming Interface (API) key (APIKey) as a unique piece of code sent from one application to another over a data network, ensuring that the interface is used only in the intended manner. An APIKey is an authentication mechanism that prevents unauthorized programs from accessing functionality or resources on a target computing system. An APIKey can be used to obtain identity tokens, such as JavaScript Object Notation (JSON) Web Tokens (JWT) or other proof of identity within a specific cloud computing environment account. The APIKey value used in this exchange does not provide any indication of where the actual APIKey (document) is stored, as embedding region or account information into the APIKey itself would prevent it from being moved to a different location. Therefore, costly computation is required to determine the location of the APIKey and its corresponding account data, which may involve (1) authorization / authentication checks on the authorization header, including outbound calls to obtain, for example, a client identifier; (2) parameter validation; (3) encryption operations on the APIKey; (4) outbound calls to the database at the current location to determine the presence of the APIKey; and (5) redirection to another region if the APIKey is not present at the current location. These operations represent significant performance overhead or cost.

[0029] When account information is not specified in the request, these operations will need to be performed on every request to access account data. This often happens in systems using API keys, for example, because the location of the account data cannot be identified at the global gateway. That is, the request needs to be forwarded from the global gateway to the target service, which performs expensive computations and processing to locate the account data. The request must then be rerouted or redirected to the actual location of the account data and the corresponding target service, typically requiring a return trip through the global gateway to that location. This results in considerable overhead and inefficiency in request processing. This overhead and inefficiency are significant when considering that many cloud computing systems and services handle millions of calls (access requests) to account data per hour. This leads to increased demands on processing power, resource allocation, network traffic, and slower response times for users.

[0030] The illustrative embodiments provide an improved data processing apparatus and method, and more specifically, an improved computing tool and improved computing tool operation / function for automatically allocating managed and / or segmented workloads in a cloud computing environment based on prior experience and feedback. Utilizing the improved computing tool and improved computing tool operation / function of the illustrative embodiments, in a cloud computing system, a global gateway service computing system automatically and dynamically generates and applies allocation rules based on automatically generated feedback from a target service. The automatically generated feedback from the target service includes feedback data specifying the location of account data, used to satisfy received requests when a request requires redirection to a different location or target service. Feedback data is generated as a result of the target service performing calculations to determine the location of the requested account data. Therefore, when an allocation rule does not exist, the target service performs increased-cost request processing to determine the location of the account data and provides that location information in the feedback from the target service.

[0031] Feedback data specifying the location of the account data used to fulfill the request is provided to the global gateway service. The global gateway service automatically and dynamically generates dispatch rules that associate the identity specified in the request with the location of the account data, such as an APIKey-to-account data location mapping. Once the dispatch rules are automatically and dynamically generated, future requests to access data associated with the same identity (e.g., APIKey) are automatically dispatched to the relevant location corresponding to that identity in the dispatch rules, without having to forward the request to the target service to determine the location of the requested data. In this way, the high overhead or expensive processing of identifying the location of the requested data is avoided, thereby reducing processing power, resource allocation, and network traffic requirements, and improving response time for users by providing faster response times.

[0032] If the location of the requested details changes, this change will be automatically detected, and the dispatch rules will be automatically and dynamically updated to dispatch the request directly to the current location of the requested data. For example, if the dispatch rules specify location A for the requested data, and the requested data has moved to location B, then when the request is dispatched to the target service associated with location A, the target service will again determine that it cannot access the requested data, perform calculations to determine the location of the requested data, and return feedback to the global gateway. The global gateway will then generate / update the dispatch rules to specify the new location B.

[0033] Therefore, for requests targeting a specific identity (e.g., APIKey) where there are no dispatch rules for that identity or the location of the requested data (e.g., account data) corresponding to that identity (e.g., APIKey) has been moved, the calculations and processing required to locate the requested data are performed, and feedback data is provided back to the global gateway for automatic and dynamic generation / updating of dispatch rules. For subsequent requests targeting the same identity, if the location of the requested data has not changed, the request can be directly dispatched to the target service associated with the location of the requested data, without having to perform calculations and processing to determine the location.

[0034] Before proceeding with the discussion of various aspects of the illustrative embodiments and the improved computer operations performed by the illustrative embodiments, it should first be understood that throughout this specification, the term "mechanism" will be used to refer to elements of the invention that perform various operations, functions, etc. As used herein, the term "mechanism" can be an implementation of a function or aspect of an illustrative embodiment in the form of an apparatus, process, or computer program product. In the case of a process, the process is implemented by one or more devices, apparatuses, computers, data processing systems, etc. In the case of a computer program product, logic represented by computer code or instructions embodied in or on the computer program product is executed by one or more hardware devices to implement a function or perform an operation associated with a particular "mechanism." Therefore, the mechanism described herein can be implemented as dedicated hardware, software executed on hardware to configure the hardware to perform a specific function of the invention that the hardware would not otherwise perform, software instructions stored on a medium such that the instructions are readily executable by hardware to specifically configure the hardware to perform the described function and the particular computer operations described herein, a process or method for performing the function, or any combination of the foregoing.

[0035] This specification and claims may use the terms "a," "at least one of," and "one or more of" with respect to specific features and elements of illustrative embodiments. It should be understood that these terms and phrases are intended to indicate the presence of at least one of a particular feature or element in a particular illustrative embodiment, but more than one may also be present. That is, these terms / phrases are not intended to limit the specification or claims to the presence of a single feature / element or to require the presence of multiple such features / elements. Rather, these terms / phrases require only at least a single feature / element, where multiple such features / elements are within the scope of the specification and claims.

[0036] Furthermore, it should be understood that if the term "engine" is used herein in connection with the description of embodiments and features of the invention, the use of the term "engine" is not intended to limit any particular technical implementation attributable to and / or performed by the engine for completing and / or executing actions, steps, processes, etc., but rather to limit "engine" to implementation using computer technology, and whose actions, steps, processes, etc., are not performed as mental processes or by manual effort, even if the engine can work in conjunction with manual input or can provide output intended for manual or mental exertion. An engine is implemented as one or more of software, dedicated hardware and / or firmware, or any combination thereof, executed on hardware, specifically configured to perform a specified function. Hardware may include, but is not limited to, the use of a combination of a processor and appropriate software loaded or stored in machine-readable memory and executed by the processor, thereby specifically configuring the processor for a dedicated purpose including one or more functions of one or more embodiments of the invention. Furthermore, unless otherwise stated, any name associated with a particular engine is for convenience of reference and is not intended to limit a particular implementation. Additionally, any function attributable to an engine may be performed equivalently by multiple engines, incorporated into and / or combined with the function of another engine of the same or different type, or distributed across one or more engines in various configurations.

[0037] Furthermore, it should be understood that the following description uses various examples of various elements from the illustrative embodiments to further illustrate exemplary implementations of the illustrative embodiments and to aid in understanding the mechanisms of the illustrative embodiments. These examples are intended to be non-limiting and are not exhaustive of all possibilities for implementing the mechanisms of the illustrative embodiments. In view of this specification, it will be apparent to those skilled in the art that many other alternative implementations of these various elements may be used in addition to or in place of the examples provided herein without departing from the spirit and scope of the invention.

[0038] It should be understood that, for clarity, certain features of the invention described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, for brevity, various features of the invention described in the context of a single embodiment may also be provided separately or in any suitable sub-combination.

[0039] This invention can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium (or medium) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0040] Various aspects of this disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0041] Computer Program Product Embodiment (“CPP Embodiment” or “CPP”) is a term used in this disclosure to describe any collection of one or more storage media (also referred to as “media”) collectively included in a group of one or more storage devices, which collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A “storage device” is any tangible device capable of holding and storing instructions used by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or pits / platforms formed in the main surface of the disk), or any suitable combination of the foregoing.

[0042] As used herein, the term computer-readable storage medium should not be construed as storing transient signals in their own form, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses through fiber optic cables, or electrical signals transmitted through wires and / or other transmission media. As those skilled in the art will understand, during normal operation of the storage device, such as during access, defragmentation, or garbage collection, data typically moves at some occasional points in time; however, this does not render the storage device transient, as the data is not transient when it is stored.

[0043] As described above, the illustrative embodiments of the present invention specifically address an improved computing tool that automatically and dynamically generates dispatch rules for execution in a global gateway to control access to requested data based on boundaries established for the workload (e.g., boundaries set by government or organizational regulations). All functionality of the illustrative embodiments described herein is intended to be performed using automated processes without human intervention. Therefore, the illustrative embodiments do not involve any human activity and cannot actually be executed in the human mind, but rather are specifically aimed at the automated logic and functionality of the improved computing tool.

[0044] Figure 1 This is an example diagram illustrating the operation of a global gateway with a target service under controlled and segmented workload constraints according to an illustrative embodiment. It should be understood that, although... Figure 1 This illustrative embodiment assumes an APIKey-based request for accessing the account data of a user requesting the source computing device 110, but it is not limited to this. Instead, it can be applied to any computing architecture where a request for access to sensitive or confidential data is received, and government or organizational regulations require border-based access and management controls on the requested data, such as in the case of government geographic regulations like FedRAMP, which require such data to be stored within specific geographic boundaries of the United States and its territories. Furthermore, the illustrative embodiment is applicable to any type of data that cannot be automatically mapped to controlled and segmented regions and, alternatively, must utilize a target service to determine the segmented regions.

[0045] like Figure 1 As shown, in the distributed data processing system environment 100, one or more end-user computing devices 110, also referred to as request-source computing devices 110, are provided because they submit requests for access to data, which may include sensitive data. Although for the sake of illustration and description herein... Figure 1Only a single end-user computing device 110 associated with end-user 105 is shown; however, it should be understood that a real distributed data processing system environment 100 may include hundreds, thousands, or more end-users and corresponding end-user computing devices that submit requests for and receive access to secure data via the mechanisms of the illustrative embodiment.

[0046] In addition to end-user computing device 110, the distributed data processing system environment also provides a global gateway 120, which, according to illustrative embodiments, is enhanced to include one or more instances of a dynamic dispatch engine 130 executing within the global gateway 120. The global gateway 120 is a load-distribution computing infrastructure with one or more computing devices (e.g., servers) performing load balancing algorithms and other services. Typically, without the enhancements to include the dynamic dispatch engine 130 of the illustrative embodiments, the global gateway 120 routes requests to backend services solely based on load balancing considerations. Without the enhancements of the illustrative embodiments, the global gateway 120 cannot perform the task of distributing requests to appropriate backend services based on content-knowledge-based requirements.

[0047] Global Gateway 120 is an infrastructure component in front of Identity and Access Management (IAM) service 160 (relative to end-user computing device 110), which includes multiple independent computing devices across several different boundaries 140-150, which can be physical computing devices and / or virtual machines. In the depicted example, boundaries 140-150 are shown as different geographical locations, but could also be organizational boundaries, government boundaries, network topology boundaries, etc., and are not necessarily associated with geographical locations. Global Gateway 120 performs the determination of which physical / virtual machine (hereinafter collectively referred to as "machine") the request is routed to based on the load and origination of the request from end-user computing device 110.

[0048] IAM service system 160 provides a centralized identity and access management framework for accessing organizational data. In the depicted example, IAM service 160 includes multiple machines across multiple geographic boundaries 140-150, such as a US IAM instance 140 and an EU IAM instance 150, where each geographic boundary 140-150 provides one or more corresponding IAM service instances 142, 152. Each IAM service instance 142, 152 includes a corresponding IAM runtime 144, 154 and a backend IAM database (DB) 146, 156. IAM runtimes 144, 154 execute applications to perform operations for processing requests and accessing data stored in the corresponding backend IAM databases 146, 156, as well as other operations. For example, IAM databases 146, 156 may store account data for multiple user accounts (e.g., accounts 1-6 in the depicted example), where the corresponding IAM runtimes 144, 154 provide data interfaces and applications for accessing that account data in the backend IAM databases 146, 156.

[0049] According to an illustrative embodiment, the global gateway 120 is enhanced with a dynamic dispatch engine 130, which provides improved computing tools and operations / functions for automatically and dynamically learning the physical storage locations of requested data with respect to physical storage boundaries 140-150, and generating dispatch rules to directly direct requests to these learned physical storage locations without having to perform IAM service computing system calculations to locate the physical locations of data across the various boundaries 140-150. The dynamic dispatch engine 130 includes a dispatch rule lookup engine 132, a dispatch rule generator 134, a feedback interceptor 136, and a dynamic dispatch rule storage device 138. Additional components (not shown) may also be provided to the dynamic dispatch engine 130 to perform supporting functions such as application programming interfaces, libraries, control logic, etc., which facilitate the operation and functionality of elements 132-138.

[0050] The dispatch rule lookup engine 132 provides computer-executed logic to perform operations / functions for automatically executing a lookup of dispatch rules stored in the dynamic dispatch rule storage device 138 in response to a request received from a request source computing device (e.g., end-user computing device 110) with an identity specified in the request. The identity can be specified in any suitable manner for a particular implementation, but for the purposes of the depicted example, the identity is specified as the APIKey in the received request. The dispatch rule lookup engine 132 performs a lookup operation to determine whether an existing dispatch rule associated with the specified identity exists in the dynamic dispatch rule storage device 138.

[0051] The dispatch rules stored in the dynamic dispatch rule storage device 138 associate dispatch locations with corresponding identities. Therefore, if a lookup operation performed by the dispatch rule lookup engine 132 results in a matching dispatch rule being found in the dynamic dispatch rule storage device 138, the matching dispatch rule is executed to directly route the request to the corresponding dispatch location, rather than through load balancing. If no matching dispatch rule is found through the lookup operation, the global gateway 120 dispatches the request based on its normal load balancing determination, which may result in the request being sent to a location where access to the requested data is not permitted due to boundary constraints on the storage and management of sensitive data, i.e., the IAM instance. Therefore, in contrast to the normal load balancing operation of the global gateway 120, which dispatches the request directly to IAM service instances 142, 152 without examining the request content, the dynamic dispatch rule engine 130 provides additional operations and functions to intelligently dispatch requests based on the identity specified within the request itself and data boundary constraints imposed by government and / or organizational regulations or policies.

[0052] In addition to the dispatch rule lookup engine 132 and the dynamic dispatch rule storage device 138, the dynamic dispatch engine 130 also includes a dispatch rule generator 134 and a feedback interceptor 136. When a request specifies an identity that does not have a corresponding dispatch rule in the dynamic dispatch rule storage device 138, the request is dispatched to an IAM service instance based on load balancing and / or other considerations, disregarding government / organizational regulations and / or policies regarding physical storage location requirements. The location to which the request is dispatched, or the IAM service instance, performs the operations previously described above to calculate the actual location of the requested data and forward the request to the IAM service instance and / or a computing device that can access the requested data.

[0053] According to an illustrative embodiment, IAM service instances 142 and 152 are further enhanced to include feedback agents 143 and 153, which operate to provide feedback responses to global gateway 120. These feedback responses specify the actual, determined target location of the requested data if IAM service instances 142 and 152 cannot access the requested data, i.e., if the data is not associated with the actual target location of the requested data. Feedback interceptor 136 intercepts these feedback responses from feedback agents 143 and 153 of IAM instances 142 and 152 and provides feedback information to dispatch rule generator 134. This feedback information may include the current actual location of the requested data and the specified identity in the request. In some illustrative embodiments, the feedback information may further specify whether the request is dispatched based on an existing dispatch rule matching in dynamic dispatch rule store 138. The dispatch rule generator uses the feedback information to automatically and dynamically generate new dispatch rules associated with the specified identity in dynamic dispatch rule store 138. As a result, when a next request is received from any request source computing device 110 (which is not necessarily the same computing device 110 as the previous request), the stored dynamic dispatch rules will be found as matches during the lookup operation, and subsequent requests will be directly dispatched to the actual location where the requested data can be accessed, i.e., the IAM instance.

[0054] It should be understood that there are instances where matching dynamic dispatch rules may exist in the dynamic dispatch rule storage device 138, but the requested data (e.g., account data) may have been moved, for example, from the EU IAM instance 152 backend database 156 to the US IAM instance database 146. In such cases, the lookup operation performed by the lookup engine 132 will find a matching dynamic dispatch rule and execute the matching dispatch rule to dispatch the request to the IAM instance specified in the dispatch rule. However, the IAM instance will determine that it cannot access the requested data and will perform calculations to determine the actual current location of the requested data. In this case, the IAM instance will again send a feedback response to the global gateway 120, which will be intercepted by the feedback interceptor 136, which will provide feedback to the dispatch rule generator 134. The dispatch rule generator 134 may again call the lookup engine 132 before generating a new dynamic dispatch rule to determine whether an existing matching dispatch rule already exists for that identity, and if so, update the existing matching dispatch rule to reference the current actual location where the requested data can be accessed. Alternatively, as described above, the feedback information may include a dispatch identifier field, which is set to specify that the request was initially dispatched based on a matching dynamic dispatch rule existing in the dynamic dispatch rule storage device 138, and therefore, the feedback information may be used by the dispatch rule generator 134 to update the existing matching dynamic dispatch rule in the storage device 138.

[0055] In operation, such as Figure 1 As shown, the requesting source computing device 110 submits a request 170 for accessing account data (used for account 4 in the depicted example) by specifying the APIKey of the account whose data is requested in the request. The request may be generated in response to user input to a graphical user interface or any other user interface of an application running on the requesting source computing device 110, a request automatically generated by an application running on the requesting source computing device 110, or the like. For example, client 110 may invoke IBM cloud services, such as Cloudant databases, IBM Watson services, etc. Before being able to invoke IBM cloud services, client 110 may need to obtain an "IAM token," which is a short-lived dataset used to provide client identity. To obtain an "IAM token," client 110 makes a call to an IAM service to exchange the APIKey for the "IAM token." This is merely an example, and the illustrative embodiment is not limited to an APIKey or "IAM token," but can be used with any identifier of identity and / or account or dataset without departing from the spirit and scope of the invention. Request 170 is routed to global gateway 120 via a local area network (not shown), a wide area network (not shown), and / or other wired / wireless data communication connection. According to an illustrative embodiment, global gateway 120 has been enhanced to provide a dynamic dispatch rule engine 130.

[0056] In response to receiving a request specifying an identity (e.g., APIKey) associated with the requested data, lookup engine 132 performs an identity (APIKey) lookup in dynamic dispatch rule database 138. Assuming no existing dynamic dispatch rule exists for the identity (APIKey) in database 138, global gateway 130 performs its normal load-balanced request routing to IAM instances 142, 152, regardless of data storage boundaries 140, 150. Therefore, in the depicted example, even if the data for account 4 associated with the APIKey is actually stored in a backend database 156 associated with the EU IAM instance 152 at geographic boundary 150, and the US IAM instance 142 cannot access the data for account 4, the request can still be routed to the US IAM instance 142 at geographic boundary 140, for example, a geographic location associated with the United States and its territories.

[0057] As a result, US IAM instance 142 performs expensive computations to determine the target location of the requested data associated with the identity (APIKey) and determines that the target location is the EU IAM instance backend database 156, which it cannot access. Therefore, US IAM instance 142 processes the request and dispatches it 172 to the EU IAM instance 152 associated with the correct target location in database 156. EU IAM instance 152 processes the request, retrieves the requested data, and provides the requested data 173 to global gateway 120 via US IAM instance 142, which stores the data temporarily and non-persistently only according to government and / or organizational regulations. In some illustrative embodiments, if government and / or organizational regulations do not permit temporary, non-persistent storage of data outside area boundaries 150, EU IAM instance 152 may alternatively bypass US IAM instance 142 and send data 173 directly back to global gateway 120.

[0058] Furthermore, in response to US IAM instance 142 determining that it is not associated with the target location of the requested data—that is, the requested data cannot be accessed because it is not stored in the backend database 146 of US IAM instance 142—USIAM instance runtime environment 144 instructs feedback broker 143 to send feedback response 174 to global gateway 120. Feedback response 174 specifies feedback information including the determined target location and the identity (e.g., APIKey) specified in the original request 170. In some cases, this feedback information may include a dispatch rule identifier, which is set to a first value to indicate whether the feedback is due to a matching dynamic dispatch rule being found for the APIKey when the original request is dispatched from global gateway 120, or a second value if no matching dynamic dispatch rule is found for the APIKey. It can be specified whether the dispatch of the original request 170 from global gateway 120 to the IAM instance is due to a matching dynamic dispatch rule. This indicator is not required, but may be provided in some illustrative embodiments to facilitate determining, based on feedback information, whether to create a new dynamic assignment rule or update an existing dynamic assignment rule in the dynamic assignment rule database 138.

[0059] In the described example, in response to the global gateway 120 receiving a feedback response 174, the feedback interceptor 136 of the dispatch rule engine 130 intercepts the feedback response 174 and provides the feedback information to the dispatch rule generator 134. The dispatch rule generator 134 generates / updates dynamic dispatch rules in the dynamic dispatch rule database 138 specifying the identity (APIKey) and the target location. Subsequently, when a subsequent request 176 with the same identity is received from the same request source computing device 110 or another request source computing device, the lookup engine 132 performs a lookup operation in the dynamic dispatch rule database 138 and finds a matching dynamic rule based on the identity (APIKey). As a result, the global gateway 120 executes the matching dynamic dispatch rule and directly dispatches the request 176 to the IAM instance (e.g., EU IAM instance 152) associated with the target location (e.g., the backend database 156 associated with EU IAM instance 152). This avoids the computation and network traffic that must be performed when subsequent result 176 is sent to the wrong IAM instance (e.g., the US IAM instance) due to load-balanced routing.

[0060] It should be understood that Figure 1 The depiction in this paper is merely an example architecture and is not intended to represent or imply any limitation on the architecture in which the aspects of the illustrative embodiments can be implemented. While the depicted example uses IBM IAM services and a global gateway as examples, the illustrative embodiments are not limited thereto. Instead, the dynamic dispatch engine 130 can be alternatively set up in any architecture where, due to physical storage boundary requirements, it is necessary to control the physical storage location used to store sensitive data and dispatch / control access to such sensitive data.

[0061] Figure 1 An overview of the operation of the main operational entities according to an architecture based on one or more illustrative embodiments is provided. This architecture may be a cloud computing system architecture, where IAM instances provide cloud computing services for performing identity and data access management. This management may include a global account management service that determines the destination location of requested data, regardless of whether the requested data is associated with the IAM instance receiving the request or with a different IAM instance. The process for dispatching and forwarding requests from the global gateway and / or from one IAM instance to another involves multiple interactions between the main operational entities, which will now be described in detail in the data flow diagram below. Figures 2-3 The data flow diagrams shown assume an exemplary illustrative embodiment based on the Representational State Transition (REST) ​​API and IAM services; however, it should be understood that the invention is not limited thereto, and other implementations may use other APIs and services. Therefore, Figures 2-3Reference will be made to REST API operations, such as POST, GET, etc., for the purposes of this description, but is not intended to represent or imply any limitation on the architecture or API that may be used in combination with the mechanisms of the illustrative embodiments.

[0062] Figure 2 An example diagram of data flow between entities in a cloud computing system for automatically and dynamically generating dispatch rules in a global gateway, according to an illustrative embodiment, is provided. Figure 2 Similar reference numerals in other figures are intended to refer to, as previously stated, Figure 1 The similar entity described.

[0063] like Figure 2 As shown, the operation begins at the requesting source computing device 110, in Figures 2-3 A computing device 110, referred to as the "client," wants to obtain a token for an existing API key, i.e., apikey="abc". However, the client does not know which data storage boundaries the API key is associated with, i.e., where the requested data is physically stored relative to data storage boundaries 140 and 150. As a result, client 110 invokes global gateway 120 by executing a POST / token(apikey=abc) call 201.

[0064] In response to a call from client 110, the dispatch rule engine 130 of global gateway 120 performs a lookup of dynamic dispatch rules in the dynamic dispatch rule database 138 via lookup engine 132, and in this example, no matching dynamic dispatch rule is found. That is, global gateway 120 checks if a dispatch rule exists for the API key, and in this example data stream, this is the first call to global gateway 120 for a given API key, therefore no dynamic dispatch rule exists. Therefore, dispatch rule engine 130 returns result 202 indicating no dispatch rule found.

[0065] In response to result 202 indicating no dispatch rule was found, global gateway 120 forwards the original call 201 to the next available IAM runtime cluster based on a load balancing algorithm. In the depicted example, this is the IAM runtime in EU geographic boundary 150, namely EU IAM runtime 154. Therefore, global gateway 120 forwards the POST / token (apikey = abc) call 201 to EU IAM runtime 154 via forwarding call 203. Upon receiving forwarding call 203, EU IAM runtime 154 may perform APIKey preprocessing 204 to determine if the APIKey is valid, and perform other operations to prepare for processing the request (call) and accessing the requested data.

[0066] EU IAM runtime 154 determines whether the requested data associated with the APIKey is stored within the EU, US, or other data storage boundaries, such as those defined by government and / or organizational regulations and / or policies. Therefore, EU IAM runtime 154 examines the APIKey record to determine which account the APIKey belongs to by performing a call 205 to the EU IAM database 156 to obtain account information for the APIKey “abc,” and determines that the APIKey corresponds to account “123” in the example shown. EUIAM runtime 154 then invokes the global account management service 200 using a GET / account_location? account=123 call 207, querying the global account management service 200 for the physical storage location of the requested data for account “123.” The global account management service 200 may be provided as part of the IAM service 160 architecture or as a separate component from the IAM service 160 architecture. The global account management service 200 returns a response 208 specifying the target location of the requested data for account “123,” which in this example is the US boundary. It should be noted that the Global Account Management Service (GAMS) 200 can be used by each of the IAM service infrastructure 160 instances 142, 152 across various boundaries 140, 150, because it does not store any personally identifiable (PI) related data, but provides information about where the account data is physically located (i.e., on which boundary 140, 150 the account data can be found).

[0067] In response to response 208 from the Global Account Management Service 200, the EU IAM runtime 154 determines 209 whether the original request, i.e., call 201, needs to be dispatched. In this example, the IAM runtime in the EU, i.e., EU IAM runtime 154, cannot access the IAM database in the US boundary, i.e., US IAM database 146, and therefore determines that call 201 needs to be dispatched to US IAM runtime 144.

[0068] EU IAM runtime 154 asynchronously sends a notification 230 to global gateway 120 by performing a POST / feedback (APIKey "abc" needs to be dispatched to the US) 230, which specifies the target location of the requested data for account "123" associated with the APIKey in the original call 201. This feedback will cause dispatch rules to be automatically and dynamically generated and stored in dynamic dispatch rule database 138, so that subsequent calls to the same APIKey can be directly routed to the US boundary, i.e., US IAM runtime 144. The dynamic dispatch rules are added to database 138 via "Set Dispatch Rule" operation 235, which will allow subsequent calls with the same APIKey to skip operations 203-209.

[0069] In response to the determination in operation 209 that a request needs to be dispatched (call 201), EU IAM runtime 154 dispatches the request to US IAM runtime 144 by executing POST / token (apikey = abc) call 210. US IAM runtime 144 performs operations 211-216, similar to operations 204-209 performed by EU IAM runtime 154. However, in the determination performed in operation 216 (similar to operation 209), the result is that no request needs to be dispatched because US IAM runtime 144 can access the account details data of account "123" corresponding to APIKey "abc" in US IAM database 146. Therefore, US IAM runtime 144 decides to continue generating the token (the requested data) on the local cluster.

[0070] As a result, US IAM runtime 144 retrieves the account details data of the APIKey from US IAM database 146 by performing the "Get APIKey Details" operation 217. US IAM database 146 returns 218 account details data corresponding to account "123" for APIKey "abc" to US IAM runtime 144. US IAM runtime 144 generates 219 a token for the APIKey and returns 220 the token to the caller, such as EU IAM runtime 154 in this example. EU IAM runtime 154 passes 221 the token to its caller, namely global gateway 120, which sends the token to the original caller via operation 222.

[0071] Figure 3 This is an example diagram of the data flow between entities in a cloud computing system for a request, according to an illustrative embodiment, for which there are assignment rules for a specified identity. Figure 3 The operation shown is similar to Figure 2In addition to the operation in this case, the dynamic assignment rule database 138 has existing dynamic assignment rules that match the identity (APIKey) in call 301, thereby enabling the ability to skip the calculation of the target location of the corresponding account for the specified identity.

[0072] Therefore, as Figure 3 As shown, the operation begins when the client computing device 110 wants to obtain data from... Figure 2 The client 110 requests a token with the same existing APIKey (i.e., apikey="abc"). Again, the client is unaware of which data storage boundaries the API key is associated with, i.e., where the requested data is physically stored relative to data storage boundaries 140 and 150. As a result, client 110 invokes global gateway 120 by performing a POST / token (apikey=abc) call 301.

[0073] In response to a call from client 110, the dispatch rule engine 130 of global gateway 120 performs a lookup of dynamic dispatch rules in dynamic dispatch rule database 138 via lookup engine 132, and in this case, because Figure 2 The previous request processing, as shown, found a 302 match for the dynamic dispatch rule. Global Gateway 120 executes the matching dynamic dispatch rule found in database 138, resulting in a 301 forwarding 303 call to US IAM runtime 144, which is known to be associated with US IAM database 146, containing account details data, i.e., the target location specified in the dynamic dispatch rule. US IAM runtime 144 can then execute the previously related... Figure 2 The process described is similar to preprocessing 304, and other similar operations 305-312 are performed to obtain the account associated with the APIKey, obtain account details data from the US IAM database 146, and generate the corresponding token.

[0074] It should be noted that in some illustrative embodiments, the global gateway 120 uses a dynamic dispatch rule mechanism that specifies that APIKey “abc” is connected to account “123” bound to a US region, but this information is not passed to the USIAM runtime 144. Therefore, the USIAM runtime 144 performs operations 304-312 to re-verify the account location. However, in other illustrative embodiments, some of these account location verification operations, such as operations 307 and 308, can be avoided because the global gateway 120 has existing dispatch rules specifying the US region, and therefore verification via GAMS 200 is unnecessary. This information can be provided by the global gateway 120 to the USIAM runtime 144, allowing operations 307 and 308 to be removed from the depicted flow. Both possibilities are intended to fall within the spirit and scope of the invention and can be chosen based on desired implementation and security levels.

[0075] The obtained token is then sent back to the caller via operation 313. In this case, the caller is the global gateway 120, which bypasses the need to return the token to an intermediate caller, for example... Figure 2 Operations 220 and 221 in the process. Then, global gateway 120 forwards the token 314 to the original caller 110. Thus, when an existing dynamic dispatch rule matching the identity specified in call 301 is found, and when the data has not yet been moved to a different data storage boundary, the dynamic dispatch rule mechanism of the illustrative embodiment achieves improvements in processing time, processing resources, and network traffic (e.g., at least with...). Figure 2 Significant cost savings (in processing time / resource costs and network traffic) associated with operations 203-209, 230-235, and 220-221.

[0076] Figure 4 This is an example diagram illustrating the feedback provided by the target service in response to the target service's inability to access the requested data, according to an illustrative embodiment. (See diagram for example.) Figure 4As shown, the example feedback response specifies the target location as "dispatch_target", which in this example is "eu.iam.cloud.ibm.com". The context information of the feedback response includes "apikey", which in this case is "ABCDEFG". Other details, including method, contextpath, and param_name, describe the operation for which the dynamic rule exists. That is, each REST request is a GET, POST, PUT, or DELETE method. Each REST request has a target context path, which in this illustrated example is / identity / token. Depending on the target path, the functionality of the REST call differs. The example "param_name / param_value" section describes which parameters the rule applies to.

[0077] from Figure 4 In the feedback response shown, the feedback interceptor of the illustrative embodiment can at least extract the dispatch target and APIKey content for the dispatch rule generator 134 to automatically generate / update dynamic dispatch rules for storage in the dynamic dispatch rule database 138, and subsequently use to directly dispatch requests to the appropriate target location via the operation of the lookup engine 132. This feedback information, along with other content thereof, can be used to automatically and dynamically populate / update fields of the dynamic dispatch rule template to specify the conditions of the dynamic dispatch rule and the specific actions performed as a result of satisfying these conditions.

[0078] Figure 5 This is an example diagram illustrating a dispatch rule that is automatically and dynamically generated based on feedback received from the target service, according to an illustrative embodiment. (See diagram for example.) Figure 5 As shown, from Figure 4 The feedback information in the feedback response can be used to populate the conditions and computer-executable instructions of the dynamic dispatch rule that can be stored in the dynamic dispatch rule database 138. In this example, the method specified in the feedback response, namely the "GET" method, is used to populate the first condition 510 of the dynamic dispatch rule 500, the context path specified in the feedback response is used to populate the second condition 520 of the dynamic dispatch rule 500, and the parameter name and value of APIKey are used to populate the third condition 530 of the dynamic dispatch rule 500. The action 540 of the dynamic dispatch rule is to dispatch the request or call to Figure 4The target location specified in the feedback response is, in this case, "eu.iam.cloud.ibm.com". Therefore, Dynamic Dispatch Rule 500 indicates that if the request / call is "GET", the request is for the context path " / identity / token", and the APIKey is "ABCDEFG", then the corresponding action of dispatching the request to the target location "eu.iam.cloud.ibm.com" will be performed.

[0079] Figures 6A-6B A flowchart outlining example operations of elements of the invention with respect to one or more illustrative embodiments is presented. It should be understood that... Figures 6A-6B The operations outlined herein are specifically performed automatically by the improved computer tools of the illustrative embodiments and are not intended to, and in fact, cannot be performed by humans as mental processes or by organizing human activities. Rather, while humans may initiate such actions in certain circumstances... Figures 6A-6B The operations described herein are executed, and in some cases can be utilized as... Figures 6A-6B The results are generated based on the consequences of the operations described in the text, but Figures 6A-6B The operations themselves are performed automatically by improved computing tools.

[0080] Figure 6A This is a flowchart outlining example operation of a dispatch rule engine (such as dispatch rule engine 130) for a global gateway according to an illustrative embodiment. Figure 6A As shown, the operation begins by receiving a request from the requesting computing device, where the request specifies the identity for which access to the associated requested data is to be granted (step 601). The global gateway's dispatch rule engine performs a lookup operation to determine whether an existing dynamic dispatch rule exists in the dynamic dispatch rule database that matches the identity in the request (step 602). If a matching existing dynamic dispatch rule exists (step 603; yes), the rule is executed, and the global gateway dispatches the request to the target location specified in the matching dynamic dispatch rule (step 604). If no matching dynamic dispatch rule exists (step 603; no), the global gateway forwards the request to the next available service instance based on a load balancing algorithm (step 605) and waits for a response.

[0081] Determine whether a feedback response and / or the requested data have been received from the service instance to which the request was forwarded (step 606). If a feedback response is received, it is processed by a feedback interceptor, which extracts feedback information, which is then provided to the dispatch rule generator (step 607). The dispatch rule generator 607 automatically and dynamically generates / updates dynamic dispatch rules for the specified identity in the original request, specifying the actual target location of the requested data (step 608). As previously mentioned... Figures 1-5 The actual target location discussed can be determined by the process of computation and interaction between different service instance runtimes, the global account management service, etc., to determine where the requested data is physically located relative to the data storage boundary, and which service instance can access that physical location. The feedback broker at the service instance runtime can provide feedback information to the global gateway. If the requested data (e.g.) Figures 2-3 If the token in the data has not yet been received by the global gateway, the global gateway will continue to wait for the data to be returned.

[0082] Therefore, if the requested data (e.g., a token) is received, which can occur whether a previous asynchronous feedback response has been received or not, the requested data is forwarded to the original requester, i.e., the requesting source computing device (step 609). The operation then terminates.

[0083] Figure 6B This is a flowchart outlining example operations of a service instance enhanced with a feedback broker according to an illustrative embodiment. Figure 6B As shown, the operation begins when a service instance receives a request (or call) from the global gateway to access data corresponding to a specified identity (step 610). The service instance runtime determines the data corresponding to the specified identity in the request by querying the backend service instance database (step 611), and then sends a request for the target location of the data to the global account management service (step 612). The service instance runtime receives the target location from the global account management service and determines whether the request needs to be dispatched to another service instance (step 613). If not (step 613; no), the service instance performs an operation to retrieve the requested data from the local service instance database, generates the corresponding token, and returns the token to the global gateway (step 614).

[0084] If the request needs to be redirected (step 613; Yes), meaning the service instance runtime cannot access the target location, the request is dispatched to the service instance runtime corresponding to the target location (step 615). Additionally, the feedback broker generates a feedback response specifying the identity in the original request, the target location returned by the global account management service, and other contextual information, such as the method used and the context path (step 616). The feedback response is asynchronously sent to the global gateway to generate / update dynamic dispatch rules for that identity (step 617). The operation then terminates.

[0085] As can be clearly seen from the above description, the present invention can be a specially configured computing system equipped with hardware and / or software specifically configured to implement the specific mechanisms and functions described herein; a method implemented by a specially configured computing system; and / or a computer program product containing software logic loaded into the computing system to specifically configure the computing system to implement the mechanisms and functions described herein. Whether described as a system, method, or computer program product, it should be understood that the illustrative embodiments described herein are specifically directed to improved computing tools and methods implemented by such improved computing tools. Specifically, the improved computing tools of the illustrative embodiments specifically provide a dispatch rule engine for a global gateway infrastructure, which includes one or more computing devices executing applications and services for processing Identity and Account Management (IAM) across multiple different data storage boundaries. The improved computing tools implement mechanisms and functions, such as automatic and dynamic dispatch rule generation and execution for dispatching requests to target locations based on data storage boundaries, which cannot be actually performed by humans, whether completely detached from the technical environment or with the assistance of the technical environment (e.g., psychological processes). The improved computing tools provide practical applications for this approach, at least because they can reduce computational costs and network traffic in existing identity and account management computing systems and architectures by automatically and dynamically generating / updating dispatch rules that can be executed to bypass the expensive operations of locating the physical target storage location of data associated with the identity specified in the data access request.

[0086] Figure 7 This is an example diagram of an example computing environment that can provide aspects of illustrative embodiments. The computing environment 700 includes an example of an environment for executing at least some of computer code relating to performing the methods of the present invention, such as those performed by... Figure 1 The dispatch rule engine 130 of the global gateway 120 performs the operations. Similarly, computing devices in the computing environment 700 can be configured to provide feedback brokers, such as... Figure 1 Feedback agents 143 and 153 are configured to operate in conjunction with the dispatch rule engine 130 of the global gateway 120 according to one or more illustrative embodiments described above.

[0087] In addition to frame 130, the computing environment 700 also includes, for example, a computer 701, a wide area network (WAN) 702, an end-user equipment (EUD) 703, a remote server 704, a public cloud 705, and a private cloud 706. In this embodiment, the computer 701 includes a processor set 710 (including processing circuitry 720 and a cache 721), a communication architecture 711, volatile memory 712, permanent storage 713 (including an operating system 722 and frame 500, as described above), a peripheral device set 714 (including a user interface (UI), a device set 723, a storage device 724, and an Internet of Things (IoT) sensor set 725), and a network module 715. The remote server 704 includes a remote database 730. The public cloud 705 includes a gateway 740, a cloud orchestration module 741, a host physical machine set 742, a virtual machine set 743, and a container set 744.

[0088] Computer 701 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or to be developed in the future capable of running programs, accessing networks, or querying databases (such as remote database 730). As fully understood in the field of computer technology, and depending on the technology, the execution of the computer-implemented method may be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 700, detailed discussion focuses on a single computer, specifically computer 701, to keep the presentation as simple as possible. Computer 701 may reside in the cloud, even if it is not physically present in the cloud. Figure 7 The cloud is shown in the diagram. On the other hand, computer 701 is not required to be in the cloud except to any extent that can be definitively indicated.

[0089] Processor assembly 710 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 720 may be distributed across multiple packages, such as multiple coordinated integrated circuit chips. Processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. Cache 721 is memory located within the processor chip package(s) and is typically used for data or code that should be readily accessible by the threads or cores running on processor assembly 710. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor assembly may be located “off-chip.” In some computing environments, processor assembly 710 may be designed to work with qubits and perform quantum computing.

[0090] Computer-readable program instructions are typically loaded onto computer 701 to cause the processor set 710 of computer 701 to perform a series of operational steps to implement a computer-implemented method, such that the instructions, when executed, instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively, the “method of the invention”). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 721 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 710 to control and direct the execution of the method of the invention. In computing environment 700, at least some of the instructions for performing the method of the invention may be stored in block 200 of permanent storage device 713.

[0091] The communication structure 711 is a signal transmission path that allows various components of the computer 701 to communicate with each other. Typically, this structure is made of switches and conductive paths, such as switches and conductive paths that constitute buses, bridges, physical input / output ports, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0092] Volatile memory 712 is any type of volatile memory now known or to be developed in the future. Examples include dynamically typed random access memory (RAM) or statically typed RAM. Typically, volatile memory is characterized by random access, but this is not necessary unless explicitly indicated. In computer 701, volatile memory 712 is located in a single package and is internal to computer 701, but optionally or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer 701.

[0093] The persistent storage device 713 is any form of non-volatile storage device for a computer, now known or to be developed in the future. The non-volatility of this storage device means that the stored data is retained regardless of whether the computer 701 is powered or / or whether the persistent storage device 713 is powered directly. The persistent storage device 713 may be a read-only memory (ROM), but typically at least a portion of the persistent storage device allows data to be written, deleted, and rewritten. Some familiar forms of persistent storage devices include hard disks and solid-state storage devices. The operating system 722 may take several forms, such as various known proprietary operating systems or operating systems employing an open-source portable operating system interface type with a kernel. The code included in box 200 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0094] Peripheral device set 714 includes a collection of peripheral devices for computer 701. Data communication connections between peripheral devices and other components of computer 701 can be implemented in various ways, such as Bluetooth connectivity, near field communication (NFC) connectivity, connections via cables (such as Universal Serial Bus (USB) type cables), plug-in connections (e.g., Secure Digital (SD) cards), connections via local area communication networks, and even connections via wide area networks (such as the Internet). In various embodiments, UI device set 723 may include components such as displays, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage device 724 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. Storage device 724 may be permanent and / or volatile. In some embodiments, storage device 724 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 701 requires substantial storage (e.g., where computer 701 locally stores and manages a large database), this storage can be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 725 consists of sensors that can be used in IoT applications. For example, one sensor could be a thermometer, while another could be a motion detector.

[0095] Network module 715 is a collection of computer software, hardware, and firmware that allows computer 701 to communicate with other computers via WAN 702. Network module 715 may include hardware (such as a modem or Wi-Fi transceiver), software for packetizing and / or depacketizing data transmitted over the communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control functions and network forwarding functions of network module 715 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN), the control functions and forwarding functions of network module 715 are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer-readable program instructions for performing the methods of the present invention can typically be downloaded to computer 701 from an external computer or external storage device via a network adapter card or network interface included in network module 715.

[0096] A WAN (702) is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology known now or developed in the future for transmitting computer data. In some implementations, a WAN may be replaced and / or supplemented by a local area network (LAN) (such as a Wi-Fi network) designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0097] End User Equipment (EUD) 703 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 701) and can take any of the forms discussed above in conjunction with computer 701. EUD 703 typically receives helpful and useful data from the operation of computer 701. For example, assuming computer 701 is designed to provide recommendations to the end user, these recommendations are typically transmitted from network module 715 of computer 701 to EUD 703 via WAN 702. In this way, EUD 703 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 703 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0098] Remote server 704 is any computer system that provides at least some data and / or functionality to computer 701. Remote server 704 can be controlled and used by the same entity operating computer 701. Remote server 704 represents a machine that collects and stores helpful and useful data for use by other computers, such as computer 701. For example, if computer 701 is designed and programmed to provide recommendations based on historical data, that historical data can be provided to computer 701 from a remote database 730 of remote server 704.

[0099] Public cloud 705 is any computer system that can be used by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, especially data storage (cloud storage) and computing power, without the need for direct active management by the user. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 705 is performed by the computer hardware and / or software of cloud orchestration module 741. The computing resources provided by public cloud 705 are typically implemented by virtual computing environments running on various computers constituting host physical machine set 742, which is the range of physical computers in and / or available to public cloud 705. Virtual computing environments typically take the form of virtual machines from virtual machine set 743 and / or containers from container set 744. It should be understood that these VCEs can be stored as images and can be transferred as images or between various physical machine hosts after VCE instantiation. Cloud orchestration module 741 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiation of VCE deployments. Gateway 740 is a collection of computer software, hardware, and firmware that allows public cloud 705 to communicate via WAN 702.

[0100] Now, we will provide some further explanation of Virtualized Computing Environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to the operating system's ability for the kernel to allow multiple isolated user-space instances (called containers) to exist. From the perspective of the programs running within them, these isolated user-space instances typically behave like a real computer. Computer programs running on a regular operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices allocated to the container; this is a characteristic known as containerization.

[0101] Private cloud 706 is similar to public cloud 705, except that computing resources are available only to a single enterprise. While private cloud 706 is depicted as communicating with WAN 702, in other embodiments, private cloud can be completely disconnected from the internet and accessible only via a local / private network. Hybrid cloud is a combination of multiple clouds of different types (e.g., private cloud, community cloud, or public cloud types) typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by a standardized or proprietary technology that enables orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, public cloud 705 and private cloud 706 are both part of a larger hybrid cloud.

[0102] like Figure 7 As shown, one or more computing devices (e.g., computer 701 or remote server 704) may be specifically configured as elements implementing a global gateway, including enhancements to the dispatch rule engine 130 of the illustrative embodiment. The configuration of the computing device may include providing dedicated hardware, firmware, etc., to facilitate the execution of the operations described herein with respect to the illustrative embodiments and the generation of output. The configuration of the computing device may also, or alternatively, include providing a software application stored in one or more storage devices and loaded into the memory of the computing device (such as computing device 701 or remote server 704) for causing one or more hardware processors of the computing device to execute the software application, which configures the processor to perform the operations described herein with respect to the illustrative embodiments and generate the output described herein with respect to the illustrative embodiments. Furthermore, any combination of dedicated hardware, firmware, software applications executed on hardware, etc., may be used without departing from the spirit and scope of the illustrative embodiments.

[0103] It should be understood that once a computing device is configured in one of these ways, it becomes a dedicated computing device specifically configured to implement the mechanisms of the illustrative embodiments, rather than a general-purpose computing device. Furthermore, as described below, the implementation of the mechanisms of the illustrative embodiments improves the functionality of the computing device and provides useful and concrete results that facilitate the automatic and dynamic generation / updating and enforcement of dispatch rules to perform more efficient and less computationally and network-traffic-cost request dispatching to service instances, taking into account data storage boundaries established by government or organizational regulations and / or policies.

[0104] As described above, it should be understood that illustrative embodiments may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment that includes both hardware and software elements. In one example embodiment, the mechanism of the illustrative embodiment is implemented in software or program code, including but not limited to firmware, resident software, microcode, etc.

[0105] A data processing system suitable for storing and / or executing program code will include at least one processor directly or indirectly coupled to memory elements via a communication bus (e.g., a system bus). Memory elements may include local memory, mass storage, and cache memory used during the actual execution of the program code, providing temporary storage for at least some of the program code to reduce the number of times code must be retrieved from mass storage during execution. Memory can be of various types, including but not limited to ROM, PROM, EPROM, EEPROM, DRAM, SRAM, flash memory, solid-state memory, etc.

[0106] Input / output (I / O) devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system directly or via intermediate wired or wireless I / O interfaces and / or controllers. I / O devices can take many different forms besides conventional keyboards, displays, pointing devices, etc., such as communication devices coupled via wired or wireless connections, including but not limited to smartphones, tablet computers, touchscreen devices, voice recognition devices, etc. Any known or hereafter developed I / O devices are intended to be within the scope of the illustrative embodiments.

[0107] Network adapters can also be coupled to the system to enable the data processing system to couple to other data processing systems or remote printers or storage devices via an intermediate private or public network. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters for wired communications. Wireless communication-based network adapters can also be utilized, including but not limited to 802.11a / b / g / n wireless communication adapters, Bluetooth wireless adapters, etc. Any known or subsequently developed network adapters are within the spirit and scope of this invention.

[0108] The invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the forms disclosed herein. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The embodiments were chosen and described to best explain the principles of the invention, its practical application, and to enable those skilled in the art to understand the various embodiments of the invention with various modifications suitable for the intended particular use. The terminology used herein is chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for dispatching requests to service instances based on data storage boundaries in a data processing system, the method comprising: Receive a first request to access data associated with the identity specified in the first request; The first request is dispatched to a first service instance associated with a first data storage boundary among a plurality of data storage boundaries, wherein each data storage boundary is defined by a provision or policy that restricts the data storage of one or more specific types of data to computing devices within a specified physical or network topology area; In response to the first service instance determining that it cannot access the data because the data is of a type associated with a second data storage boundary that is different from the first data storage boundary, a feedback response is received from the first service instance, wherein the feedback response specifies a target location associated with the second data storage boundary; In response to receiving the feedback response, automatically generate dynamic assignment rules specifying the identity and the target location, and store the dynamic assignment rules in a dynamic assignment rule database; and The subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic assignment rule database, the lookup operation finding a matching dynamic assignment rule corresponding to the specified identity, and executing the matching dynamic assignment rule to directly assign the subsequent second request to a second service instance associated with the target location; Processing the subsequent second request includes: A lookup is performed in the dynamic assignment rule database for the identity specified in the second request; In response to finding a matching dynamic assignment rule for the identity in the dynamic assignment rule database, the matching dynamic assignment rule is executed to set the data storage boundary corresponding to the identity among the plurality of data storage boundaries as the second data storage boundary; The second request is transmitted to the second service instance, wherein the second service instance is associated with the second data storage boundary; Based on the processing of the second request at the second service instance, the data requested by the second request is received to obtain the data requested by the second request from the target location; and Based on the data received from the target location, a response is transmitted to the requesting computing device that sent the second request.

2. The method according to claim 1, wherein, Dispatching the first request to the first service instance includes: Perform a lookup in the dynamic assignment rule database for the identity specified in the first request; and In response to the failure to find a matching entry for the identity in the dynamic dispatch rule database, a load balancing operation is performed to dispatch the first request to the next available service instance that is the first service instance.

3. The method according to claim 1, wherein, Receiving the feedback response from the first service instance includes: The first service instance requests data corresponding to the identity in the request from the backend service instance database; In response to the fact that no data corresponding to the identity is found in the backend service instance database, the first service instance sends a target location request to the global account management service to request the target location of the data. The target location where the first service instance receives the data from the global account management service; and The feedback agent of the first service instance sends the feedback response specifying the target location to the data processing system.

4. The method according to claim 3, wherein, The feedback response is sent asynchronously by the feedback agent to the data processing system relative to the processing of the first request, and wherein automatically generated dynamic dispatch rules are executed asynchronously relative to the processing of the first request.

5. The method according to any one of claims 1 to 4, further comprising: The first request is dispatched from the first service instance to the second service instance; The first service instance receives the data requested for access in the first request from the second service instance; Generate a response to the first request based on the received data; as well as The response is sent to the requesting computing device that sent the first request.

6. The method according to any one of claims 1 to 4, wherein, The plurality of data storage boundaries are at least one of geographic, geopolitical, or organizational data storage boundaries, which specifies that data associated with a geographic entity, geopolitical entity, or organizational entity cannot be stored outside the corresponding data storage boundary.

7. The method according to any one of claims 1 to 4, wherein, The identity specified in the first request is an API key corresponding to the data requested for access by the first request, and wherein the data includes personally identifiable information of one or more accounts in a cloud computing environment, wherein the personally identifiable information of the one or more accounts is restricted to being stored within a corresponding data storage boundary among the plurality of data storage boundaries.

8. The method according to any one of claims 1 to 4, wherein, The data processing system is a global gateway computing system in a cloud computing environment. The global gateway computing system operates across multiple data storage boundaries and combines multiple different service instances.

9. The method according to claim 8, wherein, The various service instances are regional identity and access management (IAM) cloud service instances.

10. A computer program product comprising a computer-readable storage medium therein storing a computer-readable program, wherein the computer-readable program, when executed on a computing device, causes the computing device to: Receive a first request to access data associated with the identity specified in the first request; The first request is dispatched to a first service instance associated with a first data storage boundary among a plurality of data storage boundaries, wherein each data storage boundary is defined by a provision or policy that restricts the data storage of one or more specific types of data to computing devices within a specified physical or network topology area; In response to the first service instance determining that it cannot access the data because the data is of a type associated with a second data storage boundary different from the first data storage boundary, a feedback response is received from the first service instance, wherein, The feedback response specifies the target location associated with the second data storage boundary; In response to receiving the feedback response, a dynamic assignment rule specifying the identity and the target location is automatically generated, and the dynamic assignment rule is stored in the dynamic assignment rule database. as well as The subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic assignment rule database, the lookup operation finding a matching dynamic assignment rule corresponding to the specified identity, and executing the matching dynamic assignment rule to directly assign the subsequent second request to a second service instance associated with the target location; Processing the subsequent second request includes: A lookup is performed in the dynamic assignment rule database for the identity specified in the second request; In response to finding a matching dynamic assignment rule for the identity in the dynamic assignment rule database, the matching dynamic assignment rule is executed to set the data storage boundary corresponding to the identity among the plurality of data storage boundaries as the second data storage boundary; The second request is transmitted to the second service instance, wherein the second service instance is associated with the second data storage boundary; Based on the processing of the second request at the second service instance, the data requested by the second request is received to obtain the data requested by the second request from the target location; and Based on the data received from the target location, a response is transmitted to the requesting computing device that sent the second request.

11. The computer program product according to claim 10, wherein, Dispatching the first request to the first service instance includes: Perform a lookup in the dynamic assignment rule database for the identity specified in the first request; and In response to the failure to find a matching entry for the identity in the dynamic dispatch rule database, a load balancing operation is performed to dispatch the first request to the next available service instance that is the first service instance.

12. The computer program product according to claim 10, wherein, Receiving the feedback response from the first service instance includes: The first service instance requests data corresponding to the identity in the request from the backend service instance database; In response to the fact that no data corresponding to the identity is found in the backend service instance database, the first service instance sends a target location request to the global account management service to request the target location of the data. The target location where the first service instance receives the data from the global account management service; and The feedback agent of the first service instance sends the feedback response specifying the target location to the data processing system.

13. The computer program product according to claim 12, wherein, The feedback response is sent asynchronously by the feedback agent to the data processing system relative to the processing of the first request, and wherein automatically generated dynamic dispatch rules are executed asynchronously relative to the processing of the first request.

14. The computer program product according to any one of claims 10 to 13, further comprising: The first request is dispatched from the first service instance to the second service instance; The first service instance receives the data requested for access in the first request from the second service instance; Generate a response to the first request based on the received data; as well as The response is sent to the requesting computing device that sent the first request.

15. The computer program product according to any one of claims 10 to 13, wherein, The plurality of data storage boundaries are at least one of geographic, geopolitical, or organizational data storage boundaries, which specifies that data associated with a geographic entity, geopolitical entity, or organizational entity cannot be stored outside the corresponding data storage boundary.

16. The computer program product according to any one of claims 10 to 13, wherein, The identity specified in the first request is an API key corresponding to the data requested for access by the first request, and wherein the data includes personally identifiable information of one or more accounts in a cloud computing environment, wherein the personally identifiable information of the one or more accounts is restricted to being stored within a corresponding data storage boundary among the plurality of data storage boundaries.

17. The computer program product according to any one of claims 12 to 13, wherein, The data processing system is a global gateway computing system in a cloud computing environment. The global gateway computing system operates across multiple data storage boundaries and combines multiple different service instances.

18. A data processing apparatus, comprising: At least one processor; and At least one memory coupled to the at least one processor, wherein the at least one memory includes instructions that, when executed by the at least one processor, cause the at least one processor to: Receive a first request to access data associated with the identity specified in the first request; The first request is dispatched to a first service instance associated with a first data storage boundary among a plurality of data storage boundaries, wherein each data storage boundary is defined by a provision or policy that restricts the data storage of one or more specific types of data to computing devices within a specified physical or network topology area; In response to the first service instance determining that it cannot access the data because the data is of a type associated with a second data storage boundary that is different from the first data storage boundary, a feedback response is received from the first service instance, wherein the feedback response specifies a target location associated with the second data storage boundary; In response to receiving the feedback response, automatically generate dynamic assignment rules specifying the identity and the target location, and store the dynamic assignment rules in a dynamic assignment rule database; and The subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic assignment rule database, the lookup operation finding a matching dynamic assignment rule corresponding to the specified identity, and executing the matching dynamic assignment rule to directly assign the subsequent second request to a second service instance associated with the target location; Processing the subsequent second request includes: A lookup is performed in the dynamic assignment rule database for the identity specified in the second request; In response to finding a matching dynamic assignment rule for the identity in the dynamic assignment rule database, the matching dynamic assignment rule is executed to set the data storage boundary corresponding to the identity among the plurality of data storage boundaries as the second data storage boundary; The second request is transmitted to the second service instance, wherein the second service instance is associated with the second data storage boundary; Based on the processing of the second request at the second service instance, the data requested by the second request is received to obtain the data requested by the second request from the target location; and Based on the data received from the target location, a response is transmitted to the requesting computing device that sent the second request.

Images