Experience-based dispatch of regulated workloads in cloud environments

Abstract

A mechanism is 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 regulations or policies that restrict data storage of a particular type of data to computing devices within the specified boundary. In response to the service instance determining that the data cannot be accessed because it 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 request directly to the service instance associated with the target location. (Figure 1)

Description

[Technical Field]

[0001] The present application relates generally to improved data processing apparatus and methods, and more particularly to improved computing tools and improved computing tool operations / functionality for automatically dispatching regulated and / or segmented workloads in a cloud computing environment based on prior experience and feedback.

[0002] With respect to data security, the physical storage location of data is a concern because it can affect the accessibility of the data and who can access it. This concern can be geographic, where national regulations require that sensitive data, such as personally identifiable data about citizens, be stored within the geographic boundaries and corresponding data network boundaries of a particular nation. This is increasingly a concern in cloud-based computing environments and large-scale data centers that can span various geographic regions and many different nations, as well as potentially different organizations. Being able to control who can access data and how and when individuals can access this data is extremely important, especially when the data is sensitive. Summary of the Invention

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described herein in the Detailed Description. This Summary is not intended to identify key elements or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] In one exemplary 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 of a plurality of data storage boundaries. Each data storage boundary is defined by a regulation or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological region. The method further includes receiving a feedback response from the first service instance in response to the first service instance determining that the first service instance 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. The feedback response specifies a target location associated with the second data storage boundary. The method further includes automatically generating a dynamic dispatch rule specifying the identity and the target location in response to receiving the feedback response and storing the dynamic dispatch rule in a dynamic dispatch rule database. The method also includes processing the subsequent request specifying the identity by at least performing a lookup operation in the dynamic dispatch rule database for a matching dynamic dispatch rule corresponding to the specified identity, and executing the matching dynamic dispatch rule to dispatch a second subsequent request directly to a second service instance associated with the target location.In this way, the mechanisms of the exemplary embodiments are able to automatically generate dynamic dispatch rules that take data storage boundaries into account, bypassing much of the network traffic and processing costs associated with different service instances needing to re-dispatch requests due to inaccessibility of data due to data storage boundary regulations / policies.

[0005] In some exemplary embodiments, dispatching the first request to a first service instance includes performing a lookup in the dynamic dispatch rule database for the identity specified in the first request. In response to not finding a matching entry in the dynamic dispatch rule database for the identity, performing a load balancing operation to dispatch the first request to a next available service instance as the first service instance. In this manner, if a request can be quickly submitted to a first available service instance and that service instance is unable to access data due to a data store boundary, the mechanism of the exemplary embodiments can determine a target location and data store boundary to dispatch the request to an appropriate service instance and generate a dynamic dispatch rule for handling such requests directed to the identity in the future.

[0006] In some exemplary embodiments, receiving the feedback response from the first service instance includes requesting, by the first service instance, data corresponding to the identity in the request from a backend service instance database, and, in response to not finding the data corresponding to the identity in the backend service instance database, sending, by the first service instance, a target location request to a global account management service, requesting the target location of the data. Further, such exemplary embodiments further include receiving, by the first service instance, the target location of the data from the global account management service, and sending, by a feedback agent of the first service instance, the feedback response to the data processing system, specifying the target location. In this manner, the feedback agent can obtain the actual target location of the requested data from the global account management service and provide feedback specifying this target location for use in automatically generating dynamic dispatch rules to be executed when processing subsequent requests directed to the specified identity.

[0007] In some exemplary embodiments, the feedback response is sent by the feedback agent to the data processing system asynchronously with respect to processing the first request, and automatically generating dynamic dispatch rules is performed asynchronously with respect to processing the first request. In this manner, the feedback mechanism and the generation of dynamic dispatch rules may be performed substantially simultaneously with the processing of the first request, or at different times or in parallel paths of execution. That is, the feedback and dynamic dispatch rule generation are not dependent on the completion of processing the first request.

[0008] In some exemplary embodiments, the method further includes dispatching the first request by the first service instance to the second service instance and receiving, by the first service instance, from the second service instance, the data to which access is requested in the first request. In these exemplary embodiments, the method also includes generating a response to the first request based on the received data and transmitting the response to the requesting computing device that sent the first request. In this manner, the first service instance can obtain the requested data response from the second service request and return it to the requesting computing device, thereby completing processing of the first request.

[0009] In some exemplary embodiments, processing the subsequent second request includes performing a lookup in the dynamic dispatch rule database for the identity specified in the second request, and, in response to finding a matching dynamic dispatch rule in the dynamic dispatch rule database for the identity, executing the matching dynamic dispatch rule to set a data storage boundary corresponding to the identity among the plurality of data storage boundaries as a second data storage boundary. In these exemplary embodiments, the method also includes sending the second request to the second service instance, wherein the second service instance is associated with the second data storage boundary. In these exemplary embodiments, the method further includes receiving data requested by the second request based on processing the second request at the second service instance to retrieve the data requested by the second request from the target location, and sending a response to the requesting computing device that sent the second request based on the received data from the target location. In this way, by executing matching dynamic dispatch rules from the database, the computational and network traffic costs of determining the target location and data store boundary and its corresponding service instance, as well as those costs associated with re-dispatching requests between service instances when a service instance is received that cannot access the requested data due to such data store boundary, can be avoided.

[0010] In some exemplary embodiments, the plurality of data storage boundaries is at least one of a geographic, geopolitical, or organizational data storage boundary that designates data associated with a geographic, geopolitical, or organizational entity that cannot be stored outside the corresponding data storage boundary. While any data storage boundary may be utilized, the geographic, geopolitical, or organizational data storage boundary is utilized to protect personally identifiable information about individuals associated with the corresponding geographic, geopolitical, or organizational entity. Thus, exemplary embodiments operate to meet data storage boundary requirements for such entities.

[0011] In some exemplary embodiments, the identity specified in the first request is an API Key corresponding to the data to which access is requested by the first request, the data including personally identifiable data of one or more accounts in a cloud computing environment, the personally identifiable data of the one or more accounts being restricted to storage within a corresponding data storage boundary among the plurality of data storage boundaries. In some exemplary embodiments, the data processing system is a global gateway computing system of a cloud computing environment operating in conjunction with multiple different service instances across multiple data storage boundaries. In some exemplary embodiments, the multiple different service instances are regional identity and access management (IAM) cloud service instances. Again, this enables protection of personally identifiable data in accordance with specified regulations / policies based on data storage boundaries across multiple data storage boundaries that are part of the cloud computing environment, with a regional IAM cloud service instance operating in each of the different data storage boundaries.

[0012] In another exemplary embodiment, a computer program product is provided that includes a computer usable or readable medium containing a computer readable program that, when executed on a computing device, causes the computing device to perform various and combinations of the operations outlined above with respect to the exemplary embodiment of the method.

[0013] In yet another exemplary embodiment, a system / apparatus is provided that may include one or more processors and a 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 and combinations of the operations outlined above with respect to the exemplary embodiment of the method.

[0014] These and other features and advantages of the present invention will be described or will become apparent to those skilled in the art in view of the following detailed description of exemplary embodiments of the invention. [Brief explanation of the drawings]

[0015] The invention, together with its most preferred mode of use and further objects and advantages, will best be understood by reference to the following detailed description of illustrative embodiments when read in connection with the accompanying drawings.

[0016] [Figure 1] FIG. 1 illustrates an exemplary diagram illustrating operation of a global gateway with target services under regulatory and segmentation workload restrictions, according to one exemplary embodiment.

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

[0018] [Figure 3] 1 is an exemplary diagram of data flow between entities of a cloud computing system for a request for which a dispatch rule exists for a specified identity, according to one exemplary embodiment.

[0019] [Figure 4] 10 is an exemplary diagram of feedback provided by a target service in response to the target service being unable to access requested data, according to an exemplary embodiment.

[0020] [Figure 5] FIG. 1 is an exemplary diagram of dispatch rules that are automatically and dynamically generated based on feedback received from a target service, according to one exemplary embodiment.

[0021] [Figure 6A] 1 is a flowchart outlining an example operation of a dispatch rules engine for a global gateway according to one example embodiment.

[0022] [Figure 6B] 1 is a flowchart outlining an example operation of a service instance augmented with a feedback agent, according to one example embodiment.

[0023] [Figure 7] FIG. 1 illustrates an exemplary distributed data processing system environment in which aspects of the exemplary embodiments may be implemented and in which at least a portion of the computer code involved in performing the methodology of the present invention may be executed. DETAILED DESCRIPTION OF THE INVENTION

[0024] As noted above, data security is a very important concern in computing environments, especially with respect to personally identifiable (PI) data related to specific populations, such as citizens, specific employees of a government agency, members of a specific group, organizations, etc. This is particularly a concern in cloud computing environments, which themselves span multiple geographic regions and involve numerous different parties that may or may not be subject to different regulations depending on their physical location. To address this openness and pervasiveness of cloud computing environments, government regulations are often in place that require restrictions on the storage and management of data in these cloud computing environments. For example, these restrictions may require that PI data storage and management be restricted to only specific physical or virtual locations, where these physical / virtual locations are defined with respect to geographic, geopolitical, or organizational areas defined by regulation or policy, and locations that are part of the same geographic, geopolitical, or organizational area are referred to herein as "boundaries." It should be understood that such boundaries may be associated with corresponding geographic, geopolitical, or organizational entities, such as nations, states, corporations, etc.

[0025] For example, in 2011, the U.S. federal government established the Federal Risk and Authorization Management Program (FedRAMP), which seeks 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 regulations, the "perimeter" is a U.S. data center, meaning that PI data associated with a FedRAMP-compliant cloud account must be stored and managed only in a U.S. data center. Also, because the boundary where the requested data resides may not be known by the caller, requests must be routed through a global gateway. A global gateway is a component that enables data to flow from the Internet to the service infrastructure and vice versa. Based on the client's source, the global gateway uses the fastest network path between the client and the service infrastructure. One example of such a global gateway may be the Identity and Access Management (IAM) Global Gateway Computing System available from International Business Machines (IBM) of Armonk, New York.

[0026] As such, requests to access data, such as account data, are routed through a global gateway, but these requests may or may not specify the location where the requested data is stored. That is, a requester computing device, an application running on the requester computing device, etc., may send a request that includes an account identifier (ID), which may be used to succinctly associate an account ID with a location. However, in other cases, the request may not specify an account relationship, thereby requiring an expensive computation to determine where the requested data is stored, where "expensive" is a performance measure measured in terms of the time to process the request, the amount of processing cycles required, or other computer performance measure.

[0027] The global gateway is a service provided by a different team or even organization than the target services themselves. Due to separation of concerns, it is not a good idea to build knowledge of backend services into the global gateway. Furthermore, giving the global gateway access to backend data can be dangerous because a security exposure on the global gateway immediately compromises the backend data; if the global gateway only provides access to services, there is another layer of security to protect the backend data. Therefore, the global gateway does not have access to the backend data; only the target service of a request can determine the location of the requested data. Therefore, determining the location of the requested data cannot be performed by the global gateway for all requests; as a result, requests are sent from the global gateway to the target service, which may often require the request to be rerouted back through the global gateway to the determined location of the requested data.

[0028] As an example, consider an Application Programming Interface (API) Key (API Key) is a unique piece of code transmitted over a data network from one application to another, ensuring that the interface is used only in the intended manner. The API Key is an authentication mechanism that prevents unauthorized programs from accessing functions or resources on the target computing system. The API Key may be used to obtain an identity token, e.g., a JavaScript Object Notation (JSON) Web Token (JWT), or other proof of identity for an identity in a particular cloud computing environment account. This API Key value used in this exchange does not provide any indication that an actual API Key (document) is stored, as embedded field or account information in the API Key itself prevents it from being moved to a different location. As such, determining the API Key and corresponding account data location requires costly computation, which may include (1) authorization / authentication checks on the authorization header, including, for example, an outbound call to obtain a client identifier; (2) parameter validation; (3) cryptographic operations on the API Key; (4) an outbound call to a database at the current location to determine the presence of the API Key; and (5) a redirect to another area if the API Key does not exist at the current location. These operations impose significant execution overhead, or cost.

[0029] These operations must be performed with each request for access to account data where no account information is specified in the request, which is often the case 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 must be forwarded from the global gateway to the target service, which must perform costly calculations and processing to identify the location of the account data and then reroute or redirect the request to the actual location of the account data and the corresponding target service, often requiring a flow back to this location through the global gateway. This creates significant overhead and performance inefficiencies in request processing. This overhead and performance inefficiencies become significant when one realizes that many cloud computing systems and services process millions of calls (requests for access) for account data every hour. This results in increased requirements for processing power, resource allocation, and network traffic, as well as slower response times for users.

[0030] Exemplary embodiments provide improved data processing apparatus and methods, and more particularly, improved computing tools and improved computing tool operations / functionality for automatically dispatching regulated and / or segmented workloads in a cloud computing environment based on prior experience and feedback. Using the improved computing tools and improved computing tool operations / functionality of exemplary embodiments, in a cloud computing system, a global gateway service computing system automatically and dynamically generates and applies dispatch 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 for fulfilling a received request when the received request requires a different location or redirection of the request to the target service. The feedback data is generated as a result of the target service performing a calculation to determine the location of the requested account data. Therefore, in the absence of a dispatch rule, the target service performs increased-cost processing of the request to determine the location of the account data and provides that location information in feedback from the target service.

[0031] The feedback data specifying the location of the account data for fulfilling the request is provided to a global gateway service that automatically and dynamically generates a dispatch rule that correlates the identity specified in the request with the location of the account data, e.g., API Key to account data location mapping. Once the dispatch rule is automatically and dynamically generated, future requests to access data associated with the same identity, e.g., API Key, are automatically dispatched to the correlated location in the dispatch rule corresponding to the identity without requiring the request to be forwarded to the target service to determine the location of the requested data. In this manner, high overhead or costly processing of requests to identify the location of the requested data may be avoided, thereby reducing processing power, resource allocation, and network traffic requirements, as well as improving response times for users by providing faster response times.

[0032] If the location of the requested details changes, this change is automatically detected and the dispatch rules are automatically and dynamically updated to dispatch the request directly to the current location of the requested data. For example, if a dispatch rule specifies location A for the requested data and the requested data has moved to location B, 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 a calculation to determine the location of the requested data, and return feedback to the global gateway, which then generates / updates the dispatch rule to specify the new location B.

[0033] Thus, for a request for a specified identity, e.g., APIKey, where no dispatch rules exist or the location of the account data corresponding to the requested data, e.g., identity (e.g., APIKey), has moved, the necessary computations and processing to identify the location of the requested data are performed and feedback data is returned to the global gateway for automatic and dynamic generation / update of dispatch rules. For subsequent requests directed to this same identity, if the location of the requested data has not changed, the request can be dispatched directly to the target service associated with the location of the requested data without having to perform computations and processing to determine the location.

[0034] Before continuing with a description of various aspects of the exemplary embodiments and the improved computer operations performed by the exemplary embodiments, it should first be understood that throughout this description, the term “mechanism” will be used to refer to elements of the present invention that perform various operations, functions, etc. A “mechanism,” as the term is used herein, may be an implementation of a function or aspect of an exemplary embodiment in the form of an apparatus, a procedure, or a computer program product. In the case of a procedure, the procedure is implemented by one or more devices, apparatuses, computers, data processing systems, etc. In the case of a computer program product, the 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 the function or perform the operation associated with the particular “mechanism.” Thus, the mechanisms described herein may be implemented as specialized hardware, software that runs on the hardware and thereby configures the hardware to implement specific functions of the present invention not otherwise executable by the hardware, software instructions stored on a medium such that the instructions are readily executable by the hardware, thereby specifically configuring the hardware to perform the indicated functions and specific computer operations described herein, a procedure or method for performing a function, or any combination of the above.

[0035] The present specification and claims may use the terms "one," "at least one of," and "one or more of" in reference to particular features and elements of exemplary embodiments. It should be understood that these terms and phrases are intended to state that there is at least one of a particular feature or element present in a particular exemplary embodiment, but that there may also be more than one. That is, these terms / phrases are not intended to limit the present specification or claims to the presence of a single feature / element or to require the presence of a plurality of such features / elements. To the contrary, these terms / phrases require only at least a single feature / element; the possibility of there being a plurality of such features / elements is within the scope of the present specification and claims.

[0036] Additionally, the use of the term “engine,” when used herein in connection with describing embodiments and features of the present invention, is not intended to limit any particular technical implementation for realizing and / or performing the actions, steps, processes, etc., attributed to and / or performed by the engine; however, it should be understood that “engine” is limited in that it is implemented in computer technology and its actions, steps, processes, etc. are not performed as mental processes or through manual effort, even though the engine may function in conjunction with manual input or provide output intended for manual or mental consumption. An engine is implemented as one or more of software running on hardware, dedicated hardware, and / or firmware, or any combination thereof, specially configured to perform the specified functions. Hardware may include, but is not limited to, the use of a processor in combination with appropriate software that is loaded or stored in machine-readable memory and executed by a processor, thereby specially configuring the processor for a specific purpose that includes one or more of the functions of one or more embodiments of the present invention. Furthermore, any name associated with a particular engine, unless otherwise specified, is for convenience of reference and is not intended to limit a particular implementation. Furthermore, any functionality attributed to one engine may be incorporated into and / or combined with the functionality of another engine of the same or different type, or may be distributed across one or more engines in various configurations and performed in the same way by multiple engines.

[0037] Additionally, it should be understood that the following description uses multiple and various examples of various elements of the exemplary embodiments to further illustrate exemplary implementations of the exemplary embodiments and to aid in understanding the mechanisms of the exemplary embodiments. These examples are intended to be non-limiting and do not exhaust the various possibilities for implementing the mechanisms of the exemplary embodiments. In light of this specification, it will be apparent to those skilled in the art that there are many other alternative implementations of these various elements that could be utilized in addition to or in place of the examples provided herein without departing from the spirit and scope of the present invention.

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

[0039] The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present invention.

[0040] Various aspects of the present disclosure are described through 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, operations may be performed in an order different from that shown in a given flowchart, depending on the technology involved. For example, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner, again depending on the technology involved.

[0041] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain 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 that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, 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 diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing.

[0042] A computer-readable storage medium, as that term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through wires, and / or other transmission media. As one skilled in the art will appreciate, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but the above does not qualify a storage device as transitory because the data is not transitory while it is stored.

[0043] As noted above, exemplary embodiments of the present invention are specifically directed to an improved computing tool that automatically and dynamically generates dispatch rules executed at a global gateway to control access to requested data according to established boundaries for workloads, such as those prescribed by government or organizational rules. All of the functionality of the exemplary embodiments described herein is intended to be performed using automated processes without human intervention. As such, the exemplary embodiments do not orchestrate any human activity and are not actually executable by the human mind, but rather are actually directed to the automated logic and functionality of the improved computing tool.

[0044] FIG. 1 is an exemplary diagram illustrating the operation of a global gateway with a target service under regulatory and segmentation workload restrictions, according to one exemplary embodiment. While FIG. 1 assumes an API Key-based request to access account data for a user of a requesting computing device 110, it should be understood that the exemplary embodiment is not limited to such. To the contrary, the exemplary embodiment may be applied to any computer architecture where a request for access to sensitive or confidential data is received and where government or organizational rules require perimeter-based access and administrative controls over the requested data, e.g., in the case of government geographic restrictions such as FedRAMP, which require that such data be stored within specific geographic boundaries of the United States and its territories. Additionally, the exemplary embodiment is applicable to any type of data that cannot be automatically mapped to regulatory and segmentation domains and instead must utilize a target service to determine the segmentation domain.

[0045] As shown in Figure 1, one or more end-user computing devices 110, also referred to as requesting computing devices 110, are provided in a distributed data processing system environment 100 to submit requests to access data, which may include sensitive data. While Figure 1 shows only a single end-user computing device 110 associated with an end user 105 for ease of illustration and description herein, it should be understood that an actual distributed data processing system environment 100 may include hundreds, thousands, or more end users and corresponding end-user computing devices submitting requests and receiving access to secure data via the mechanisms of the exemplary embodiments.

[0046] In addition to end-user computing devices 110, the distributed data processing system environment provides a global gateway 120 that is enhanced in accordance with the exemplary embodiment 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-balanced computer infrastructure having one or more computing devices, e.g., servers, that perform load-balancing algorithms and other services. Generally, the global gateway 120 routes requests to backend services based solely on load-balancing concerns without being extended to include the dynamic dispatch engine 130 of the exemplary embodiment. The global gateway 120 cannot perform content-knowledge-based, requirement-based dispatching of requests to appropriate backend services without being extended to the exemplary embodiment.

[0047] The global gateway 120 is an infrastructure component in front of the identity and access management (IAM) service 160 (relative to the end-user computing device 110) that is comprised of multiple standalone computing devices, which may be physical and / or virtual machines, that traverse multiple different boundaries 140-150. In the illustrated example, the boundaries 140-150 are shown to be different geographies, but they may be organizational boundaries, governmental boundaries, network topology boundaries, etc. that are not necessarily tied to geography. The global gateway 120 performs a determination as to which physical / virtual machine (hereinafter collectively referred to as "machine") a request should be routed to based on the load and origin of the request from the end-user computing device 110.

[0048] The IAM service system 160 provides a centralized identity and access management framework for accessing organizational data. In the illustrated example, the IAM service 160 is configured with multiple machines across multiple geographic boundaries 140-150, e.g., a United States (US) IAM instance 140 and a European Union (EU) IAM instance 150, with each geographic boundary 140-150 providing 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. The IAM runtime 144, 154 runs applications and performs operations to process requests and access data stored in the corresponding backend IAM database 146, 156, among other operations. For example, an IAM database 146, 156 may store account data for multiple user accounts, e.g., accounts 1-6 in the illustrated example, and the corresponding IAM runtime 144, 154 provides a data interface and applications for accessing this account data in the backend IAM database 146, 156.

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

[0050] The dispatch rule lookup engine 132 provides computer-implemented logic to perform operations / functions to automatically perform a lookup of dispatch rules stored in the dynamic dispatch rule storage 138 in response to receiving a request from a requesting computing device (e.g., the end-user computing device 110) having an identity specified in the request. While the identity may be specified in any suitable manner for a particular implementation, for purposes of the illustrated example, the identity is specified as an API Key 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 138.

[0051] Dispatch rules stored in the dynamic dispatch rule storage 138 associate a dispatch location with a corresponding identity. Thus, if a lookup operation performed by the dispatch rule lookup engine 132 results in a matching dispatch rule in the dynamic dispatch rule storage 138, the matching dispatch rule is executed to direct the request directly to the corresponding dispatch location rather than to a location determined through load balancing. If a matching dispatch rule is not found through the lookup operation, the global gateway 120 performs request dispatching based on its normal load balancing determination, which may result in the request being sent to a location, i.e., an IAM instance, that is not authorized to access the requested data due to boundary constraints related to the storage of and management of access to sensitive data. Thus, contrary to the normal load balancing operation of the global gateway 120, which does not look at the content of the request to direct the dispatch of the request to the IAM service instance 142, 152, the dynamic dispatch rule engine 130 provides additional operations and functionality for intelligently dispatching requests based on the identity specified within the request itself and data boundary constraints imposed by governmental and / or organizational rules or policies.

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

[0053] According to example embodiments, the IAM service instances 142, 152 are further enhanced to include feedback agents 143, 153 that operate to provide feedback responses to the global gateway 120 specifying the actual, defined target location of the requested data when the IAM service instances 142, 152 cannot access the requested data, i.e., are not associated with the actual target location of the requested data. The feedback interceptor 136 intercepts these feedback responses from the feedback agents 143, 153 of the IAM instances 142, 152 and provides feedback information to the 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 example embodiments, the feedback information may further specify whether the request was dispatched based on a matching existing dispatch rule in the dynamic dispatch rule storage 138. The dispatch rule generator uses the feedback information to automatically and dynamically generate a new dispatch rule in the dynamic dispatch rule storage 138 that is associated with the specified identity. As a result, when a subsequent request is received from any requesting computing device 110, which need not be the same computing device 110 as the previous request, the stored dynamic dispatch rule is found as a match during the lookup operation, and the subsequent request is dispatched directly to the actual location, i.e., the IAM instance, that has accessibility to the requested data.

[0054] It should be understood that there may be some instances where a matching dynamic dispatch rule exists in dynamic dispatch rule storage 138, but the requested data, e.g., account data, has moved location, for example, from EU IAM instance 152 backend database 156 to US IAM instance database 146. In such cases, a lookup operation performed by lookup engine 132 finds a matching dynamic dispatch rule and executes the matching dispatch rule to dispatch the request to the IAM instance specified in the dispatch rule. However, the IAM instance determines that it does not have access to the requested data and performs a calculation to determine the actual current location of the requested data. In such cases, the IAM instance sends a feedback response back to global gateway 120, which is intercepted by feedback interceptor 136, which provides feedback to dispatch rule generator 134. Before generating a new dynamic dispatch rule, dispatch rule generator 134 may again invoke lookup engine 132 to determine whether an existing matching dispatch rule already exists for the identity, and if so, update the existing matching dispatch rule to reference the current actual location that has accessibility to the requested data. Alternatively, as noted above, the feedback information may include a dispatch identifier field that is set to specify that the request was originally dispatched based on a matching dynamic dispatch rule that exists in dynamic dispatch rule storage 138, so that the feedback information may be used by dispatch rule generator 134 to update the existing matching dynamic dispatch rule in storage 138.

[0055] In operation, as shown in FIG. 1 , requesting computing device 110 submits request 170 to access account data (for account 4 in the illustrated example) by specifying in the request the API Key for the account for which data is requested. 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 requesting computing device 110, an automatically generated request by an application running on requesting computing device 110, etc. For example, client 110 may invoke an IBM Cloud service such as a Cloudant database, an IBM Watson service, etc. Before being able to invoke the IBM Cloud service, client 110 may need to obtain an “IAM token,” which is a short-lived data set to provide the client identity. To obtain the “IAM token,” client 110 makes a call to an IAM service to exchange an API Key for the “IAM token.” This is merely one example, and the illustrative embodiment is not limited to an API Key or “IAM token,” but rather may be used with any identifier of identity and / or account or data set without departing from the spirit and scope of the present invention. The requests 170 are routed through a local area network (not shown), a wide area network (not shown), and / or other wired / wireless data communication connections to the global gateway 120. The global gateway 120, according to an exemplary embodiment, is enhanced to provide a dynamic dispatch rules engine 130.

[0056] In response to receiving a request specifying an identity, e.g., an APIKey, associated with the requested data, the lookup engine 132 performs a lookup of the identity (APIKey) in the dynamic dispatch rule database 138. Assuming there is no existing dynamic dispatch rule for the identity (APIKey) in the database 138, the global gateway 130 performs its normal load balancing-based routing of the request to the IAM instances 142, 152 regardless of the data storage boundary 140, 150. Thus, in the illustrated example, the request may be routed to the US IAM instance 142 in a geographic location associated with the United States and its territories, for example, even though data for Account 4 associated with the APIKey is actually stored in a backend database 156 associated with the EU IAM instance 152 within the geographic boundary 150, and the US IAM instance 142 does not have access to the data for Account 4.

[0057] As a result, the US IAM instance 142 performs costly calculations to determine the target location of the requested data associated with the identity (API Key) and determines that the target location is the EU IAM instance backend database 156, to which it does not have access. Therefore, the US IAM instance 142 processes the request and dispatches 172 the request to the EU IAM instance 152 associated with the correct target location in database 156. The EU IAM instance 152 processes the request, retrieves the requested data, and provides the requested data 173 to the global gateway 120 via the US IAM instance 142, which stores the data only temporarily and non-persistently in accordance with government and / or organizational rules. In some example embodiments, if government and / or organizational rules do not allow temporary, non-persistent storage of data outside of the territorial boundary 150, the EU IAM instance 152 may instead send the data 173 directly back to the global gateway 120, bypassing the US IAM instance 142.

[0058] Furthermore, in response to the US IAM instance 142 determining that it cannot access the requested data because it is not associated with the target location of the requested data, i.e., it is not stored in the backend database 146 of the US IAM instance 142, the feedback agent 143 is instructed by the US IAM instance runtime environment 144 to send a feedback response 174 to the global gateway 120 specifying feedback information including the defined target location and identity specified in the original request 170, e.g., the API Key. In some cases, this feedback information may include a dispatch rule identifier set to a first value to indicate whether this feedback was due to a matching dynamic dispatch rule being found for the API Key when the original request was dispatched from the global gateway 120, or set to a second value if a matching dynamic dispatch rule was not found for the API Key. Whether the dispatch of the original request was due to a matching dynamic dispatch rule may be specified in the dispatch of the original request 170 from the global gateway 120 to the IAM instance. This indicator is not required, but in some example embodiments may be provided to facilitate the decision to create new dynamic dispatch rules or update existing dynamic dispatch rules in dynamic dispatch rule database 138 based on the feedback information.

[0059] In the illustrated example, in response to feedback response 174 being received by global gateway 120, feedback interceptor 136 of dispatch rule engine 130 intercepts feedback response 174 and provides feedback information to dispatch rule generator 134, which generates / updates a dynamic dispatch rule for the specified identity (API Key) and target location in dynamic dispatch rule database 138. Thereafter, when a subsequent request 176 having the same identity is received from either the same requesting computing device 110 or another requesting computing device, lookup engine 132 performs a lookup operation in dynamic dispatch rule database 138 and finds a matching dynamic rule based on the identity (API Key). As a result, global gateway 120 executes the matching dynamic dispatch rule and dispatches request 176 directly to an IAM instance associated with backend database 156 associated with the target location, e.g., EU IAM instance 152, e.g., EU IAM instance 152. This avoids the need to perform computations and network traffic if the subsequent result 176 is sent to an incorrect IAM instance, e.g., the US IAM instance, due to load balancing-based routing.

[0060] It should be understood that the depiction in Figure 1 is merely an exemplary architecture and is not intended to describe or imply any limitations with respect to architectures in which aspects of the exemplary embodiments may be implemented. While the illustrated example uses the IBM IAM service and global gateway as examples, the exemplary embodiments are not so limited. To the contrary, dynamic dispatch engine 130 may instead be provided in any architecture in which there is a requirement for control of physical storage locations for storing sensitive data, and for dispatch / access control of such sensitive data taking into account physical storage boundary requirements.

[0061] FIG. 1 provides an overview of the operation of the primary operational entities of an architecture according to one or more exemplary embodiments. This architecture may be a cloud computing system architecture in which an IAM instance provides cloud computing services for performing identity and data access management. This management may include a global account management service that determines the target location of requested data, i.e., whether the requested data is associated with the IAM instance that received the request or 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 among the primary operational entities, detailed below in the following data flow diagrams. While the data flow diagrams shown in FIGS. 2-3 assume an exemplary embodiment based on a Representational State Transfer (REST) ​​API and IAM service, it should be understood that the present invention is not limited to such and other implementations may use other APIs and services. Thus, while FIGS. 2-3 refer to REST API operations such as POST, GET, etc. for convenience herein, this is not intended to describe or imply any limitations on the architecture or APIs that may be used in combination with the mechanisms of the exemplary embodiments.

[0062] 2 provides an exemplary diagram of data flow between entities of a cloud computing system for automatically and dynamically generating dispatch rules in a global gateway, according to one exemplary embodiment. Like reference numerals in FIG. 2, and other figures, are intended to refer to like entities as previously described with respect to FIG. 1.

[0063] 2, operation begins with a requesting computing device 110, referred to in FIGS. 2-3 as the “client” computing device 110, wishing to obtain a token for an existing APIKey, i.e., apikey=“abc”, however, the client is unaware of which data store boundary the API key is associated with, i.e., where the requested data is physically stored with respect to the data store boundaries 140, 150. As a result, the client 110 invokes the global gateway 120 by executing a POST / token(apikey=abc) call 201.

[0064] In response to the call from client 110, dispatch rules engine 130 of global gateway 120, via lookup engine 132, performs a dynamic dispatch rule lookup in dynamic dispatch rule database 138 and, in this example, finds no matching dynamic dispatch rule. That is, global gateway 120 checks whether a dispatch rule exists for the API key; at this point in the exemplary data flow, this is the first call for the given API key to global gateway 120, and no dynamic dispatch rule currently exists. Therefore, dispatch rules engine 130 returns result 202 that no dispatch rule was found.

[0065] In response to result 202 indicating that no dispatch rule was found, global gateway 120 forwards original call 201 to the next available IAM runtime cluster based on a load balancing algorithm, which in the illustrated example turns out to be an IAM runtime within EU geographic boundary 150, i.e., EU IAM runtime 154. Accordingly, global gateway 120 forwards POST / token(apikey=abc) call 201 to EU IAM runtime 154 via forward call 203. In response to receiving forward call 203, EU IAM runtime 154 may perform API Key preprocessing 204 to determine if the API Key is valid and may perform other operations to prepare for processing the request (call) and access to the requested data.

[0066] The EU IAM runtime 154 determines whether the requested data associated with the API Key is stored within the EU, US, or other data storage boundary as defined by government and / or organizational rules and / or policies. Therefore, the EU IAM runtime 154 checks within the API Key record to determine which account the API Key belongs to by making a call 205 to the EU IAM database 156 to retrieve account information for the API Key “abc” and determine that the API Key corresponds to account “123” in the illustrated example. The EU IAM runtime 154 then asks the global account management service 200, which may be provided as part of the IAM service 160 architecture or as a separate component from the IAM service 160 architecture, where the requested data for account “123” is physically stored by invoking the global account management service 200 with a GET / account_location?account=123 call 207. The global account management service 200 returns a response 208 specifying the target location for the requested data for account "123," which in this example is the US boundary. Note that the global account management service (GAMS) 200 does not store any personally identifiable (PI) related data, but does provide information about where the account data is physically located, i.e., within which boundaries 140, 150 the account data can be found, so that it can be used by each of the IAM service infrastructure 160 instances 142, 152 that traverse the various boundaries 140, 150.

[0067] In response to the response 208 from the global account management service 200, the EU IAM runtime 154 determines whether dispatch 209 of the original request, i.e., call 201, is required. In this example, the IAM runtime within the EU, i.e., EU IAM runtime 154, does not have access to the IAM database within the US boundary, i.e., US IAM database 146, and therefore determines that dispatch of the call 201 to the US IAM runtime 144 is required.

[0068] The EU IAM runtime 154 asynchronously sends a notification 230 to the global gateway 120 specifying the target location of the requested data for account "123" associated with the APIKey in the original call 201 by performing a POST / feedback(apikey "abc" requests dispatch to US) 230. This feedback causes a dispatch rule to be automatically and dynamically generated and stored in the dynamic dispatch rule database 138, thereby allowing subsequent calls for the same APIKey to be routed directly to the US boundary, i.e., to the US IAM runtime 144. The dynamic dispatch rule is added to the database 138 via a "set dispatch rule" operation 235, which allows operations 203-209 to be skipped for subsequent calls with the same APIKey.

[0069] In response to determining in operation 209 that the request (call 201) needs to be dispatched, the EU IAM runtime 154 dispatches the request to the US IAM runtime 144 by executing a POST / token(apikey=abc) call 210. The US IAM runtime 144 performs operations 211-216, which are similar to operations 204-209 performed by the EU IAM runtime 154. However, in the determination performed in operation 216 (similar to operation 209), the result of the determination is that dispatching of the request is not required because the US IAM runtime 144 has access to account detail data for account "123" corresponding to API Key "abc" in the US IAM database 146. Therefore, the US IAM runtime 144 determines to continue generating a token (the requested data) on the local cluster.

[0070] As a result, the US IAM runtime 144 retrieves account details for the APIKey from the US IAM database 146 by executing a "get details for apikey" operation 217. The US IAM database 146 returns 218 account details for the account "123" corresponding to the APIKey "abc" to the US IAM runtime 144. The US IAM runtime 144 generates 219 a token for the APIKey and returns 220 the token to the caller, e.g., the EU IAM runtime 154 in this example. The EU IAM runtime 154 passes 221 the token to the caller, i.e., the global gateway 120, which sends the token to the original caller via operation 222.

[0071] 3 is an exemplary diagram of data flow between entities of a cloud computing system for a request for which a dispatch rule exists for a specified identity, according to one exemplary embodiment. The operation shown in FIG. 3 is similar to that in FIG. 2, except that in this case, dynamic dispatch rule database 138 has an existing dynamic dispatch rule that matches the identity (API Key) in call 301, and as a result, the calculation to determine the target location of the corresponding account for the specified identity can be skipped.

[0072] Thus, as shown in Figure 3, the operation begins with a client computing device 110 wanting to obtain a token for the same existing APIKey, i.e., apikey="abc", specified in the request from client 110 in Figure 2. Again, the client is unaware of which data storage boundary the API key is associated with, i.e., where the requested data is physically stored with respect to data storage boundaries 140, 150. As a result, client 110 invokes global gateway 120 by executing a POST / token(apikey=abc) call 301.

[0073] In response to the call from the client 110, the dispatch rule engine 130 of the global gateway 120, via the lookup engine 132, performs a lookup of dynamic dispatch rules in the dynamic dispatch rule database 138, where a matching dynamic dispatch rule is found 302 due to the previous request processing shown in FIG. 2. The global gateway 120 executes the matching dynamic dispatch rule found in the database 138, resulting in forwarding 303 the call 301 to the US IAM runtime 144 known to be associated with the US IAM database 146 where the account details reside, i.e., the target location specified in the dynamic dispatch rule. The US IAM runtime 144 may perform pre-processing 304 similar to that previously described with respect to FIG. 2 and other similar operations 305-312 to obtain the account associated with the API Key, obtain the account details from the US IAM database 146, and generate a corresponding token.

[0074] Note that in some exemplary embodiments, the global gateway 120 uses a dynamic dispatch rule mechanism that specifies that API Key "abc" is connected to account "123," which is bound to the US region, but this information is not passed to the US IAM runtime 144. Therefore, the US IAM runtime 144 performs operations 304-312 to again verify the account location. However, in other exemplary embodiments, some of these account location verification operations, such as operations 307 and 308, may be avoided because the global gateway 120 has existing dispatch rules that specify the US region, and therefore verification via GAMS 200 is not required. This information may be provided by the global gateway 120 to the US IAM runtime 144, thereby allowing operations 307 and 308 to be omitted from the illustrated flow. Both possibilities are intended to be within the spirit and scope of the present invention and may be selected based on the implementation and level of security desired.

[0075] The resulting token is then sent back to the caller, in this case global gateway 120, via operation 313, thereby bypassing the need to return the token to an intermediate caller, e.g., operations 220 and 221 in Figure 2. Global gateway 120 then forwards 314 the token to the original caller 110. Thus, significant cost savings in processing time, processing resources, and network traffic, e.g., associated with operations 203-209, 230-235, and 220-221 in Figure 2, are achieved by the dynamic dispatch rule mechanism of the exemplary embodiment, at least when an existing dynamic dispatch rule is found to match the identity specified in call 301 and the data has not been moved to a different data storage boundary.

[0076] FIG. 4 is an example diagram of feedback provided by a target service in response to the target service being unable to access requested data, according to an example embodiment. As shown in FIG. 4, the example feedback response specifies the target location as "dispatch_target," which in this example is location "eu.iam.cloud.ibm.com." Context information for the feedback response includes "apikey," which in this case is apikey "ABCDEFG." Other details, including method, contextpath, and param_name, describe the operation for which the dynamic rule exists. That is, each REST request is one of the methods GET, POST, PUT, or DELETE. Each REST request has a target contextpath, 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 for which parameters this rule is valid.

[0077] 4, the feedback interceptor of the example embodiment may extract at least the dispatch target and API Key content for use by dispatch rule generator 134 in automatically generating / updating dynamic dispatch rules for storage in dynamic dispatch rule database 138, and for subsequent use in performing direct dispatch of the request to the appropriate target location via operation of lookup engine 132. This feedback information, along with other content of the feedback information, may be used to automatically and dynamically populate / update fields in a dynamic dispatch rule template that specifies the conditions of the dynamic dispatch rule and the particular actions to be taken as a result of those conditions being met.

[0078] 5 is an exemplary diagram of a dispatch rule that is automatically and dynamically generated based on feedback received from a target service, according to one exemplary embodiment. As shown in FIG. 5, the content of the feedback information from the feedback response in FIG. 4 may be used to input conditions and computer-executable instructions for the dynamic dispatch rule, which may be stored in dynamic dispatch rule database 138. In the above example, the method specified in the feedback response, i.e., the “GET” method, is used to input the first condition 510, the context path specified in the feedback response is used to input the second condition 520, and the parameter name and value for the APIKey are used to input the third condition 530 of dynamic dispatch rule 500. Action 540 of the dynamic dispatch rule dispatches the request or call to the target location specified in the feedback response of FIG. 4, which in this case is the “eu.iam.cloud.ibm.com” target location. Thus, dynamic dispatch rule 500 indicates that if the request / call is "GET", and the request is for a context path of " / identity / token", and the APIKey is "ABCDEFG", then a corresponding action is performed that dispatches the request to the target location "eu.iam.cloud.ibm.com".

[0079] 6A-6B present a flowchart outlining exemplary operations of elements of the present invention in connection with one or more exemplary embodiments. It should be understood that the operations outlined in FIGS. 6A-6B are specifically performed automatically by the improved computing tools of the exemplary embodiments and are not intended to be, and indeed cannot be, performed by humans, either as mental processes or by orchestrating human activity. To the contrary, although in some cases a human may initiate the performance of the operations described in FIGS. 6A-6B and in some cases may use results produced as a result of the operations described in FIGS. 6A-6B, the operations in FIGS. 6A-6B themselves are specifically performed by the improved computing tools in an automated manner.

[0080] 6A is a flowchart outlining an exemplary operation of a dispatch rule engine, such as dispatch rule engine 130 for a global gateway, according to one exemplary embodiment. As shown in FIG. 6A, operation begins with receiving a request from a requesting computing device, where the request specifies an identity to which access to associated requested data is to be provided (step 601). The dispatch rule engine of the global gateway performs a lookup operation to determine whether an existing dynamic dispatch rule exists in a dynamic dispatch rule database that matches the identity in the request (step 602). If an existing matching 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 a matching dynamic dispatch rule does not exist (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] A determination is made as to whether a feedback response and / or the requested data has been received from the service instance to which the request was forwarded (step 606). If a feedback response has been received, it is processed by a feedback interceptor, which extracts the feedback information provided to the dispatch rule generator (step 607). The dispatch rule generator 607 automatically and dynamically generates / updates dynamic dispatch rules for the identities specified in the original request, specifying the actual target location of the requested data (step 608). As previously discussed with respect to FIGS. 1-5, the actual target location may be determined by the service instance through a process of computation and interaction between different service instance runtimes, global account management services, etc., to determine where the requested data is physically located relative to the data storage boundary and which service instances can access that physical location. A feedback agent in the service instance runtime may provide the feedback information to the global gateway. The global gateway continues to wait for the requested data, e.g., the token in FIGS. 2-3, to be returned if it has not already been received by the global gateway.

[0082] Thus, if the requested data, e.g., a token, is received, which may occur with or without a previous asynchronous feedback response having been received, the requested data is forwarded to the original requestor, i.e., requesting computing device (step 609). Operation then ends.

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

[0084] If the request needs to be redirected (step 613; yes), i.e., 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). In addition, the feedback agent generates a feedback response specifying the identity in the original request, the target location returned by the global account management service, and other context information, such as the method and context path used (step 616). The feedback response is asynchronously sent to the global gateway for use in generating / updating dynamic dispatch rules for the identity (step 617). The operation then ends.

[0085] As is apparent from the above description, the present invention may be a specially configured computing system configured with hardware and / or software that is itself specially configured to implement particular mechanisms and functions described herein, a method performed by a specially configured computing system, and / or a computer program product including software logic loaded onto a computing system to specially 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 exemplary embodiments described herein are specifically directed to the improved computing tool and method implemented by this improved computing tool. In particular, the improved computing tool of the exemplary embodiment provides a dispatch rule engine for a global gateway infrastructure that specifically includes one or more computing devices running applications and services for handling identity and account management (IAM) across multiple different data store boundaries. The improved computing tool implements mechanisms and functions, such as automatic and dynamic dispatch rule generation and execution for dispatching requests to target locations based on data store boundaries, which cannot actually be performed by a human being, either outside of or with the assistance of a technological environment, such as a mental process.The improved computing tool provides practical application of the method at least in that the improved computing tool can reduce computational costs and network traffic in existing identity and account management computing systems and computing architectures by automatically and dynamically generating / updating dispatch rules that can be executed to bypass costly operations for identifying a physical target storage location of data associated with an identity specified in a data access request.

[0086] Figure 7 is an illustrative diagram of an exemplary computing environment in which aspects of the exemplary embodiments may be provided. Computing environment 700 includes an example of an environment for execution of at least a portion of the computer code involved in performing the inventive method, such as operations performed by dispatch rules engine 130 of global gateway 120 in Figure 1. Similarly, computing devices in computing environment 700 may be configured to provide feedback agents, such as feedback agents 143 and 153 in Figure 1, for operation with dispatch rules engine 130 of global gateway 120 according to one or more exemplary embodiments as previously described.

[0087] In addition to block 130, computing environment 700 includes, for example, a computer 701, a wide area network (WAN) 702, an end user device (EUD) 703, a remote server 704, a public cloud 705, and a private cloud 706. In this embodiment, computer 701 includes a set of processors 710 (including processing circuitry 720 and cache 721), a communications fabric 711, volatile memory 712, persistent storage 713 (including an operating system 722 and block 500, as identified above), a set of peripheral devices 714 (including a user interface (UI), a set of devices 723, storage 724, and a set of Internet of Things (IoT) sensors 725), and a network module 715. Remote server 704 includes a remote database 730. Public cloud 705 includes a gateway 740, a cloud orchestration module 741, a set of host physical machines 742, a set of virtual machines 743, and a set of containers 744.

[0088] Computer 701 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 730. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this presentation of computing environment 700, the detailed discussion focuses on a single computer, specifically computer 701, to keep the presentation as simple as possible. Computer 701 may be located in a cloud, although not depicted in the cloud in FIG. 7 . However, computer 701 is not required to be in the cloud except to the extent that it may be affirmatively indicated.

[0089] Processor set 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, e.g., multiple cooperating integrated circuit chips. Processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. Cache 721 is located on the processor chip package and is typically memory used for data or code that should be available for quick access by threads or cores executing on processor set 710. Cache memory is usually organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 710 may be designed to operate with qubits and perform quantum computing.

[0090] Computer-readable program instructions are typically loaded onto computer 701 to cause processor set 710 of computer 701 to execute a series of operational steps, thereby implementing a computer-implemented method; thus, the instructions so executed will instantiate the method specified in the flowcharts and / or written descriptions of the computer-implemented methods contained herein (collectively referred to as the "methods of the present 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 processor set 710 to control and direct the execution of the methods of the present invention. In computing environment 700, at least some of the instructions that implement the methods of the present invention may be stored in block 200 in persistent storage 713.

[0091] Communications fabric 711 is the signal-conducting pathway that allows various components of computer 701 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as switches and conductive pathways that make up buses, bridges, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0092] Volatile memory 712 may be any type of volatile memory now known or later developed. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, although this is not required unless affirmatively indicated. In computer 701, volatile memory 712 is located in a single package and is internal to computer 701; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 701.

[0093] Persistent storage 713 is any form of non-volatile computer storage now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 701 and / or directly to persistent storage 713. Persistent storage 713 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 722 may take several forms, such as various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that utilize a kernel. The code contained in block 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 the set of peripheral devices of computer 701. Data communication connections between peripheral devices and other components of computer 701 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB)-type cables), insertion-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 723 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 724 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 724 may be persistent and / or volatile. In some embodiments, storage 724 may take the form of a quantum computing storage device that stores data in the form of qubits. In embodiments where computer 701 is required to have a large amount of storage (e.g., computer 701 stores and manages large databases locally), then this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 725 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

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

[0096] WAN 702 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any technology for communicating computer data now known or later developed. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. 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] The end-user device (EUD) 703 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 701) and may take any of the forms discussed above in connection with the computer 701. The EUD 703 typically receives useful and useful data from the operation of the computer 701. For example, in the hypothetical case where the computer 701 is designed to provide recommendations to the end user, the recommendations would typically be communicated from the network module 715 of the computer 701 over the WAN 702 to the EUD 703. In this manner, the EUD 703 can display or otherwise present the recommendations to the end user. In some embodiments, the EUD 703 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, or the like.

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

[0099] A public cloud 705 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functions, particularly data storage (cloud storage) and computing power, without direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct and active management of the computing resources of the public cloud 705 is performed by the computer hardware and / or software of a cloud orchestration module 741. The computing resources provided by the public cloud 705 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 742 of computers within and / or available to the public cloud 705. The virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 743 and / or containers from a container set 744. It is understood that these VCEs may be stored as images and can be transferred among and between various physical machine hosts, either as images or after instantiation of the VCEs. The cloud orchestration module 741 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages active instantiations of VCE deployments. The gateway 740 is a collection of computer software, hardware, and firmware that enables the public cloud 705 to communicate over the WAN 702.

[0100] Some further description of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to that container; this feature is known as containerization.

[0101] Private cloud 706 is similar to public cloud 705, except that its computing resources are available only for use by a single enterprise. While private cloud 706 is shown in communication with WAN 702, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both public cloud 705 and private cloud 706 are part of a larger hybrid cloud.

[0102] 7 , one or more of the computing devices, e.g., computer 701 or remote server 704, may be specifically configured to implement elements of the global gateway, including extensions of dispatch rules engine 130 of the exemplary embodiments. Configuring the computing device may include the provision of special-purpose hardware, firmware, etc., to facilitate performing the operations and generating output described herein with respect to the exemplary embodiments. Configuring the computing device may also, or alternatively, include the provision of software applications stored in one or more storage devices and loaded into memory of the computing device, such as computing device 701 or remote server 704, to cause one or more hardware processors of the computing device to execute the software applications that configure the processors to perform the operations and generate output described herein with respect to the exemplary embodiments. Also, any combination of special-purpose hardware, firmware, software applications running on hardware, etc., may be used without departing from the spirit and scope of the exemplary embodiments.

[0103] It should be understood that once a computing device is configured in one of these ways, the computing device becomes a specialized computing device specifically configured to implement the mechanisms of the exemplary embodiments, and not a general-purpose computing device. Furthermore, as will be described below, implementation of the mechanisms of the exemplary embodiments improves the functionality of the computing device, providing useful and reliable results that facilitate automatic and dynamic dispatch rule generation / update and execution for more efficient and lower computational and network traffic cost dispatching of requests to service instances, taking into account data storage boundaries established by governmental or organizational rules and / or policies.

[0104] As noted above, it should be understood that the exemplary embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In one exemplary embodiment, the mechanisms of the exemplary embodiments may be implemented in software or program code, including but not limited to firmware, resident software, microcode, etc.

[0105] Any data processing system suitable for storing and / or executing program code will include at least one processor coupled directly or indirectly to memory elements through a communications bus, such as a system bus. The memory elements may include local memory employed during the actual execution of the program code, bulk storage, and cache memory that provides temporary storage of at least some program code to reduce the number of times the code must be retrieved from bulk storage during execution. The memory may be of various types, including but not limited to, ROM, RPROM, EPROM, EEPROM, DRAM, SRAM, flash memory, solid-state memory, etc.

[0106] Input / output or I / O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to this system either directly or through intervening wired or wireless I / O interfaces and / or controllers, etc. I / O devices can take many different forms other than traditional keyboards, displays, pointing devices, etc., such as communication devices coupled through wireless or wired connections, including but not limited to smartphones, tablet computers, touch screen devices, voice recognition devices, etc. Any I / O device now known or later developed is intended to be within the scope of the exemplary embodiments.

[0107] Network adapters may be coupled to the system to enable the data processing system to be coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. 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 may also be utilized, including, but not limited to, 802.11a / b / g / n wireless communication adapters, Bluetooth® wireless adapters, and the like. Any network adapter known or yet to be developed is intended to be within the spirit and scope of the present invention.

[0108] The description of the present invention has been presented for purposes of illustration and description and is not intended to be exhaustive or limited to the invention in the form disclosed. 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 have been chosen and described to best explain the principles and practical applications of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications suited to the particular uses contemplated. The terminology used herein has been chosen to best explain the principles, practical applications, or technical improvements of the embodiments over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A method in a data processing system for dispatching requests to service instances based on data storage boundaries, the method comprising: receiving a first request to access data associated with an identity specified in the first request; dispatching the first request to a first service instance associated with a first data storage boundary of a plurality of data storage boundaries, where each data storage boundary is defined by a regulation or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological region; 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 that is different from the first data storage boundary, wherein the feedback response specifies a target location associated with the second data storage boundary; automatically generating a dynamic dispatch rule that specifies the identity and the target location in response to receiving the feedback response and storing the dynamic dispatch rule in a dynamic dispatch rule database; and processing the subsequent request specifying the identity by at least performing a lookup operation in the dynamic dispatch rule database for a matching dynamic dispatch rule corresponding to the specified identity, and executing the matching dynamic dispatch rule to dispatch a second subsequent request directly to a second service instance associated with the target location. A method for providing

2. Dispatching the first request to a first service instance comprises: performing a lookup in the dynamic dispatch rules database for the identity specified in the first request; and in response to not finding a matching entry in the dynamic dispatch rules database for the identity, performing a load balancing operation to dispatch the first request to a next available service instance as the first service instance.

2. The method of claim 1, comprising:

3. receiving the feedback response from the first service instance, requesting, by the first service instance, data corresponding to the identity in the request from a backend service instance database; sending, by the first service instance, a target location request to a global account management service requesting the target location of the data in response to not finding the data corresponding to the identity in the backend service instance database; receiving, by the first service instance, the target location of the data from the global account management service; and sending, by a feedback agent of the first service instance, the feedback response to the data processing system specifying the target location.

3. The method of claim 1 or 2, comprising:

4. 4. The method of claim 3, wherein the feedback response is sent by the feedback agent to the data processing system asynchronously with respect to the step of processing the first request, and wherein automatically generating dynamic dispatch rules is performed asynchronously with respect to the step of processing the first request.

5. dispatching the first request by the first service instance to the second service instance; receiving, by the first service instance, from the second service instance, the data to which access is requested in the first request; 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. The method according to claim 1 , further comprising:

6. The step of processing the subsequent second request comprises: performing a lookup in the dynamic dispatch rules database for the identity specified in the second request; in response to finding a matching dynamic dispatch rule in the dynamic dispatch rule database for the identity, executing the matching dynamic dispatch rule to set a data storage boundary corresponding to the identity among the plurality of data storage boundaries as a second data storage boundary; sending the second request to the second service instance, wherein the second service instance is associated with the second data storage boundary; receiving data requested by the second request based on processing the second request at the second service instance, and retrieving the data requested by the second request from the target location; and transmitting a response to the requesting computing device that sent the second request based on the received data from the target location.

6. The method according to claim 1, wherein

7. 7. The method of claim 1, wherein the plurality of data storage boundaries are at least one of geographic, geopolitical, or organizational data storage boundaries that designate data associated with a geographic, geopolitical, or organizational entity that cannot be stored outside the corresponding data storage boundary.

8. 8. The method of claim 1, wherein the identity specified in the first request is an API Key corresponding to the data to which access is requested by the first request, the data including personally identifiable data of one or more accounts in a cloud computing environment, and the personally identifiable data of the one or more accounts is restricted to storage within a corresponding data storage boundary among the plurality of data storage boundaries.

9. The method according to claim 1 , wherein the data processing system is a global gateway computing system of a cloud computing environment that operates in conjunction with multiple different service instances across multiple data storage boundaries.

10. The method of claim 9 , wherein the plurality of different service instances are regional Identity and Access Management (IAM) cloud service instances.

11. a computer-readable storage medium having a computer-readable program stored thereon, the computer-readable program, when executed on a computing device, causing the computing device to: receiving a first request to access data associated with an identity specified in the first request; dispatching the first request to a first service instance associated with a first data storage boundary of a plurality of data storage boundaries, where each data storage boundary is defined by a regulation or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological region; receiving a feedback response from the first service instance in response to the first service instance determining that the data cannot be accessed due to the data being of a type associated with a second data storage boundary that is different from the first data storage boundary, wherein the feedback response specifies a target location associated with the second data storage boundary; automatically generating a dynamic dispatch rule specifying the identity and the target location in response to receiving the feedback response, and storing the dynamic dispatch rule in a dynamic dispatch rule database; performing a lookup operation in the dynamic dispatch rule database for a matching dynamic dispatch rule corresponding to at least the specified identity, and processing the subsequent request specifying the identity by executing the matching dynamic dispatch rule to dispatch a subsequent second request directly to a second service instance associated with the target location. Computer program products.

12. Dispatching the first request to a first service instance comprises: performing a lookup in the dynamic dispatch rules database for the identity specified in the first request; and in response to not finding a matching entry in the dynamic dispatch rules database for the identity, performing a load balancing operation to dispatch the first request to a next available service instance as the first service instance.

12. The computer program product of claim 11, comprising:

13. receiving the feedback response from the first service instance, requesting, by the first service instance, data corresponding to the identity in the request from a backend service instance database; sending, by the first service instance, a target location request to a global account management service requesting the target location of the data in response to not finding the data corresponding to the identity in the backend service instance database; receiving, by the first service instance, the target location of the data from the global account management service; and sending, by a feedback agent of the first service instance, the feedback response to the data processing system specifying the target location.

13. A computer program product according to claim 11 or 12, comprising:

14. 14. The computer program product of claim 13, wherein the feedback response is sent by the feedback agent to the data processing system asynchronously with respect to processing the first request, and wherein automatically generating dynamic dispatch rules is performed asynchronously with respect to processing the first request.

15. dispatching the first request by the first service instance to the second service instance; receiving, by the first service instance, from the second service instance, the data to which access is requested in the first request; generating a response to the first request based on the received data; sending the response to the requesting computing device that sent the first request. A computer program product according to one of claims 11 to 14, further comprising:

16. The step of processing the subsequent second request comprises: performing a lookup in the dynamic dispatch rules database for the identity specified in the second request; in response to finding a matching dynamic dispatch rule in the dynamic dispatch rule database for the identity, executing the matching dynamic dispatch rule to set a data storage boundary corresponding to the identity among the plurality of data storage boundaries as a second data storage boundary; sending the second request to the second service instance, wherein the second service instance is associated with the second data storage boundary; receiving data requested by the second request based on processing the second request at the second service instance, and retrieving the data requested by the second request from the target location; and transmitting a response to the requesting computing device that sent the second request based on the received data from the target location.

16. A computer program product according to one of claims 11 to 15, comprising:

17. 17. The computer program product of claim 11, wherein the plurality of data storage boundaries are at least one of geographic, geopolitical, or organizational data storage boundaries that designate data associated with a geographic, geopolitical, or organizational entity that cannot be stored outside the corresponding data storage boundary.

18. 18. The computer program product of claim 11, wherein the identity specified in the first request is an API Key corresponding to the data to which access is requested by the first request, the data including personally identifiable data of one or more accounts in a cloud computing environment, and the personally identifiable data of the one or more accounts is restricted to storage within a corresponding data storage boundary among the plurality of data storage boundaries.

19. 19. The computer program product of claim 11, wherein the data processing system is a global gateway computing system of a cloud computing environment that operates in conjunction with multiple different service instances across multiple data storage boundaries.

20. at least one processor; and at least one memory coupled to the at least one processor, wherein the at least one memory, when executed by the at least one processor, causes the at least one processor to: receiving a first request to access data associated with an identity specified in the first request; dispatching the first request to a first service instance associated with a first data storage boundary of a plurality of data storage boundaries, where each data storage boundary is defined by a regulation or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological region; receiving a feedback response from the first service instance in response to the first service instance determining that the data cannot be accessed due to the data being of a type associated with a second data storage boundary that is different from the first data storage boundary, wherein the feedback response specifies a target location associated with the second data storage boundary; automatically generating a dynamic dispatch rule specifying the identity and the target location in response to receiving the feedback response, and storing the dynamic dispatch rule in a dynamic dispatch rule database; performing a lookup operation in the dynamic dispatch rule database for a matching dynamic dispatch rule corresponding to at least the specified identity, and processing the subsequent request specifying the identity by executing the matching dynamic dispatch rule to dispatch a subsequent second request directly to a second service instance associated with the target location. Contains instructions An apparatus comprising:

Images