Empirical-based dispatch of regulated workloads in cloud environment

Abstract

Mechanisms are provided for assigning requests to service instances based on data storage boundaries. A request specifying an identity is received and assigned to service instances of data storage boundaries, where each data storage boundary is defined by provisions or policies that limit data storage of a particular type of data to computing devices within the specified boundary. In response to determining that the service instance cannot access the data due to the data being associated with the different data storage boundaries, a feedback response is received from the service instance that specifies the target location. A dynamic assignment rule specifying an identity and a target location is generated, and a subsequent request specifying the identity is processed by executing the dynamic assignment rule to assign the subsequent request directly to a service instance associated with the target location.

Description

Background Art

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

[0002] With respect to data security, the physical storage location of data is of concern because it may affect the accessibility of the data and who may access the data. The concern may be geographic, where national regulations require that sensitive data (such as personally identifiable data of national citizens) be stored within the geographic boundaries of a particular country and the corresponding data network boundaries. This is increasingly a concern in cloud-based computing environments and large-scale data centers that may span a variety of geographic regions and many different countries and potentially different organizations. Being able to control who can access the data and how and when individuals can access the data is very important, especially when the data is of a sensitive nature. Summary of the invention

[0003] This summary is provided to introduce some concepts in a simplified form that are further described in the detailed description herein. This summary is not intended to identify key factors 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 illustrative embodiment, a method for dispatching requests to service instances based on data storage boundaries in a data processing system is provided. 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 provision or policy that restricts data storage of one or more specific types of data to computing devices within a specified physical or network topology area. The method also includes: in response to the first service instance determining that the first service instance cannot access the data because the data is a type associated with a second data storage boundary that is different from the first data storage boundary, receiving a feedback response from the first service instance. The feedback response specifies a target location associated with the second data storage boundary. In addition, the method includes 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. In addition, the method includes processing a subsequent second request of the specified identity by at least performing a lookup operation in the dynamic dispatch rule database, the lookup operation finding a matching dynamic dispatch rule corresponding to the specified identity, and performing the matching dynamic dispatch rule to dispatch the subsequent request directly to the second service instance associated with the target location. In this way, the mechanisms of the illustrative embodiments are able to automatically generate dynamic dispatch rules that take into account data storage boundaries and bypass much of the network traffic and processing costs associated with having to re-dispatching requests when different service instances are unable to access data due to data storage boundary regulations / policies.

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

[0006] In some illustrative embodiments, receiving a 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 data corresponding to the identity in the backend service instance database, sending, by the first service instance, a target location request for a target location of the requested data to a global account management service. In addition, such illustrative embodiments also 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, a feedback response specifying the target location to a data processing system. In this manner, the feedback agent is able to obtain the actual target location of the data requested from the global account management service, and provide feedback specifying the target location for automatically generating dynamic dispatch rules for execution when processing subsequent requests for the specified identity.

[0007] In some illustrative embodiments, the feedback response is sent to the data processing system by the feedback agent asynchronously relative to processing the first request, and wherein the automatic generation of the dynamic dispatch rule is performed asynchronously relative to processing the first request. In this manner, the feedback mechanism and the generation of the dynamic dispatch rule can be performed substantially simultaneously with the processing of the first request, or at different timings, or in parallel execution paths. That is, the feedback and the generation of the dynamic dispatch rule are not dependent on the completion of the processing of the first request.

[0008] In some illustrative 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, the data requested for access in the first request from the second service instance. In these illustrative embodiments, the method further includes generating a response to the first request based on the received data, and sending the response to the requesting computing device that sent the first request. In this manner, the first service instance is able to obtain the requested data response from the second service request and provide it back to the requesting computing device, thereby completing the processing of the first request.

[0009] In some illustrative embodiments, processing the subsequent second request includes performing a lookup in a dynamic dispatch rule database for an 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 in a plurality of data storage boundaries to a second data storage boundary. In addition, in these illustrative embodiments, the method also includes transmitting the second request to a second service instance, wherein the second service instance is associated with the second data storage boundary. In addition, in these illustrative embodiments, the method includes receiving the data requested by the second request based on processing the second request at the second service instance to obtain the data requested by the second request from a target location, and transmitting a response to the requesting computing device that sent the second request based on the data received from the target location. In this manner, by executing the matching dynamic dispatch rule from the database, the computational cost and network traffic cost for determining the target location and the data storage boundary and its corresponding service instance are avoided, as well as such costs associated with redispatching requests between service instances when the receiving service instance cannot access the requested data due to such data storage boundaries.

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

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

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

[0013] In yet another illustrative embodiment, a system / apparatus is provided. The system / apparatus 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 operations and combinations thereof in the operations outlined above with respect to the method illustrative embodiment.

[0014] These and other features and advantages of the present invention will become apparent to those of ordinary skill in the art in view of the following detailed description of exemplary embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0018] Figure 3 is an example 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 an illustrative embodiment;

[0019] Figure 4 is an example diagram of feedback provided by a target service in response to the target service being unable to access requested data in accordance with an illustrative embodiment;

[0020] Figure 5 is an example diagram of dispatch rules automatically and dynamically generated based on feedback received from a target service according to one illustrative embodiment;

[0021] Fig. 6A is a flow chart outlining an example operation of a dispatch rules engine for a global gateway according to one illustrative embodiment;

[0022] Figure 6Bis a flowchart outlining an example operation of a service instance enhanced with a feedback agent according to one illustrative embodiment; and

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

[0024] As mentioned above, data security is a key concern in computing environments, especially with respect to personally identifiable (PI) data of specific groups (e.g., citizens of a country, specific employees of a government agency, members of certain groups, organizations, etc.). This is of particular concern in cloud computing environments, where the environment itself spans multiple geographic regions and involves many different parties, which may be subject to different regulations or no regulations depending on their physical location. In order to address this openness and ubiquity of cloud computing environments, in many cases, government regulations have been enacted 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 limited to specific physical or virtual locations, where these physical / virtual locations are defined according to geographic, geopolitical, or organizational regions defined by regulations or policies, and locations that are part of the same geographic, geopolitical, or organizational region are referred to herein as "boundaries." It should be understood that such boundaries may be associated with corresponding geographic, geopolitical, or organizational entities (e.g., countries, nations, commercial enterprises, 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 the FedRAMP regulations, the "border" is the U.S. data center, meaning that PI data associated with a FedRAMP-compliant cloud account only needs to be stored and managed in a U.S. data center. In addition, requests need to be routed by a global gateway because the border where the requested data is located may not be known to the caller. The global gateway is a component that allows data to flow from the Internet to the service infrastructure and back. Based on the source of the client, the global gateway uses the fastest network path between the client and the service infrastructure. An example of such a global gateway may be an identity and access management (IAM) global gateway computing system available from International Business Machines (IBM) in Armonk, New York.

[0026] Thus, requests for access to data (such as account data) are routed through the global gateway, but these requests may or may not specify a location where the requested data is stored. That is, a requestor computing device, an application executing on a requestor computing device, etc. may send a request that includes an account identifier (ID), which may be used to associate the account ID with a location in a straightforward manner. However, in other cases, the request may not specify an account relationship, and therefore expensive computations would be required to determine where the requested data is stored, where the "cost" is a performance metric measured in terms of time to process the request, amount of processing cycles required, or other computer performance metrics.

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

[0028] As an example, consider that an application programming interface (API) key (APIKey) is a unique piece of code sent from one application to another over a data network that ensures that the interface is used only in the manner it is intended. The APIKey is an authentication mechanism that prevents unauthorized programs from accessing functions or resources on a target computing system. The APIKey can be used to obtain an identity token, such as a JavaScript Object Notation (JSON) Web Token (JWT) or other proof of identity in a specific cloud computing environment account. The APIKey value used for this exchange does not give any indication of where the actual APIKey (document) is stored, because embedding the region or account information into the APIKey itself will prevent it from being moved to a different location. Therefore, expensive calculations are required to determine the APIKey and the corresponding account data location, where the calculation may involve (1) authorization / authentication checks on the authorization header, including outbound calls to obtain, for example, a client identifier; (2) parameter validation; (3) cryptographic operations on the APIKey; (4) outbound calls to a database at the current location to determine the existence of the APIKey; and (5) redirection to another region when the APIKey does not exist at the current location. These operations represent significant performance overhead or cost.

[0029] In the case where account information is not specified in the request, these operations will need to be performed for each request to access account data, for example, this is often the case with systems that use APIKeys, etc., because the location of the account data cannot be identified at the global gateway. That is, the request needs to be forwarded from the global gateway to the target service, the target service performs expensive calculations and processing to locate the account data, and then the request must be rerouted or redirected to the actual location of the account data and the corresponding target service, usually requiring a process back to that location through the global gateway. This creates considerable overhead and performance inefficiencies in request processing. This overhead and performance inefficiency are significant when it is recognized that many cloud computing systems and services process millions of calls (access requests) to account data per hour. This results in increased demand for processing power, resource allocation, network traffic, and slower response times to users.

[0030] The illustrative embodiments provide an improved data processing apparatus and method, and more specifically provide an improved computing tool and improved computing tool operation / function for automatically dispatching regulated and / or segmented workloads in a cloud computing environment based on previous experience and feedback. Utilizing the improved computing tool and improved computing tool operation / function of the illustrative embodiments, in a cloud computing system, a global gateway service computing system automatically and dynamically generates and applies 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, which is used to satisfy the received request when the received request requires redirecting the request to a different location or 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, when a dispatch rule does not exist, the target service performs processing of the request with an increased cost to determine the location of the account data and provides the location information in the feedback from the target service.

[0031] Feedback data specifying the location of the account data used to satisfy the request is provided to a global gateway service, which automatically and dynamically generates a dispatch rule that associates the identity specified in the request with the location of the account data, such as an APIKey to account data location mapping. Once the dispatch rule is automatically and dynamically generated, future requests for access to data associated with the same identity (e.g., APIKey) are automatically dispatched to the relevant location in the dispatch rule that corresponds to the identity, without having to forward the request to a target service to determine the location of the requested data. In this way, high overhead or expensive processing of requests to identify the location of the requested data can 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, that change is automatically detected and the dispatch rules automatically and dynamically updated to dispatch the request directly to the current location of the requested data. For example, if the dispatch rules specify location A for the requested data, and the requested data has moved to location B, then when the request is dispatched to the target service associated with location A, the target service will again determine that it cannot access the requested data, will perform calculations to determine the location of the requested data, and return feedback to the global gateway, which will then generate / update the dispatch rules to specify the new location B.

[0033] Therefore, for a request for a specified identity (e.g., APIKey) for which there is no dispatch rule or the location of the requested data (e.g., account data) corresponding to the identity (e.g., APIKey) has been moved, the calculations and processing required to locate the requested data are performed, and feedback data is provided back to the global gateway for automatic and dynamic generation / update of dispatch rules. For subsequent requests for the same identity, when 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 calculations and processing to determine the location.

[0034] Before proceeding to discuss various aspects of the illustrative embodiments and the improved computer operations performed by the illustrative embodiments, it should first be understood that throughout the specification, the term "mechanism" will be used to refer to elements of the present invention that perform various operations, functions, etc. The term "mechanism" used herein can be an implementation of a function or aspect of the illustrative embodiments in the form of a device, process, or computer program product. In the case of a process, the process is implemented by one or more devices, devices, computers, data processing systems, etc. In the case of a computer program product, the logic represented by the 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 a specific "mechanism". Therefore, the mechanism described herein can be implemented as dedicated hardware, software executed on hardware to configure the hardware to implement the dedicated functions of the present invention that the hardware would not be able to perform otherwise, software instructions stored on a medium that makes the instructions easy to be executed by hardware to specifically configure the hardware to perform the recorded functions and specific computer operations described herein, a process or method for performing a function, or any combination of the above.

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

[0036] In addition, it should be understood that if the term "engine" is used in this article with respect to describing embodiments and features of the present invention, the use of the term "engine" is not intended to limit any specific technical implementation that can be attributed to the engine and / or performed by the engine for completing and / or performing actions, steps, processes, etc., but is limited to the "engine" being implemented in computer technology, and its actions, steps, processes, etc. are not performed as mental processes or by manual effort, even if the engine can work in conjunction with manual input or can provide output intended for manual or mental consumption. The engine is implemented as one or more of software, dedicated hardware and / or firmware executed on hardware, or any combination thereof, which is specifically configured to perform the specified function. The hardware may include, but is not limited to, the use of a combination of a processor and appropriate software loaded or stored in a machine-readable memory and executed by the processor, thereby specifically configuring the processor for a dedicated purpose including one or more functions of one or more embodiments of the present invention. In addition, unless otherwise specified, any name associated with a specific engine is for the purpose of convenient reference and is not intended to limit a specific implementation. In addition, any function attributed to an engine can be performed equally by multiple engines, incorporated into the function of another engine of the same or different type and / or combined with the function of another engine of the same or different type, or distributed on one or more engines of various configurations.

[0037] In addition, it should be understood that the following description uses a number of various examples of various elements of the illustrative embodiments to further illustrate the example implementations of the illustrative embodiments and to help understand the mechanisms of the illustrative embodiments. These examples are intended to be non-limiting and are not exhaustive of the various possibilities for implementing the mechanisms of the illustrative embodiments. In view of this specification, it will be apparent to one of ordinary skill in the art that many other alternative implementations of these various elements may be used in addition to or in place of the examples provided herein without departing from the spirit and scope of the present invention.

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

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

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

[0041] Computer program product embodiments ("CPP embodiments" or "CPP") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") collectively included in a set of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can retain and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing.

[0042] The term computer-readable storage medium as used in this disclosure should not be interpreted as storage in the form of a transitory signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide, a light pulse through a fiber optic cable, an electrical signal transmitted through an electric wire and / or other transmission medium. As will be understood by those skilled in the art, during normal operation of a storage device, such as during access, defragmentation, or garbage collection, data is typically moved at some occasional point in time, but this does not make the storage device transitory because the data is not transitory when it is stored.

[0043] As described above, the illustrative embodiments of the present invention are specifically directed to an improved computing tool that automatically and dynamically generates dispatch rules for execution in a global gateway to control access to requested data according to boundaries established for workloads (e.g., boundaries set by government or organizational regulations). All functions of the illustrative embodiments as described herein are intended to be performed using automated processes without human intervention. Therefore, the illustrative embodiments do not organize any human activities and cannot actually be performed in a human mind, but are actually directed to the automated logic and functions of the improved computing tool.

[0044] Figure 1 is an example diagram illustrating the operation of a global gateway with target services under regulated and segmented workload constraints according to one illustrative embodiment. It should be understood that although Figure 1 An APIKey-based request for access to account data of a user of the requesting source computing device 110 will be assumed, but the illustrative embodiments are not limited thereto. Rather, the illustrative embodiments may be applied to any computer architecture in which a request to access sensitive or confidential data is received and government or organizational regulations require boundary-based access and management controls on the requested data, for example, in the case of government geographic regulations such as FedRAMP, requiring that such data be stored within specific geographic boundaries of the United States and its territories. Furthermore, the illustrative embodiments are applicable to any type of data that cannot be automatically mapped into regulated and segmented regions and instead must utilize a target service to determine the segmented regions.

[0045] like Figure 1 As shown, in a distributed data processing system environment 100, one or more end-user computing devices 110 are provided, also referred to as request source computing devices 110, because they submit requests for access to data, which may include sensitive data. Although for ease of depiction and description herein, Figure 1Only a single end-user computing device 110 associated with end-user 105 is shown, but 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 that submit requests and receive access to secure data via the mechanisms of the illustrative embodiments.

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

[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), which includes multiple independent computing devices across multiple different boundaries 140-150, which can be physical computing devices and / or virtual machines. In the depicted example, the boundaries 140-150 are shown as different geographical locations, but can also be organizational boundaries, government boundaries, network topology boundaries, etc., which are not necessarily associated with geographical locations. The global gateway 120 performs a determination as to which physical / virtual machine (hereinafter collectively referred to as a "machine") the request is 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 depicted example, the IAM service 160 includes multiple machines in multiple geographic boundaries 140-150, such as the United States (US) IAM instance 140 and the European Union (EU) IAM instance 150, wherein each geographic boundary 140-150 provides one or more corresponding IAM service instances 142, 152. Each IAM service instance 142, 152 includes a corresponding IAM runtime 144, 154 and a backend IAM database (DB) 146, 156. The IAM runtime 144, 154 executes applications to perform operations for processing requests and accessing data stored in the corresponding backend IAM database 146, 156, as well as other operations. For example, the IAM database 146, 156 can store account data for multiple user accounts (e.g., accounts 1-6 in the depicted example), wherein the corresponding IAM runtime 144, 154 provides a data interface and application for accessing the account data in the backend IAM database 146, 156.

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

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

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

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

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

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

[0055] In operation, Figure 1 As shown, the request source computing device 110 submits a request 170 for accessing account data (for account 4 in the depicted example) by specifying in the request the APIKey of the account whose 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 executed on the request source computing device 110, a request automatically generated by an application executed on the request source computing device 110, or the like. For example, the client 110 may call an IBM cloud service, such as a Cloudant database, an IBM Watson service, or the like. Before being able to call an IBM cloud service, the client 110 may need to obtain an "IAM token", which is a short-term data set used to provide the client's identity. In order to obtain the "IAM token", the client 110 performs a call to the IAM service to exchange the APIKey for the "IAM token". This is merely an example, and the illustrative embodiments are not limited to APIKeys or "IAM tokens", but may be used with any identifier of an identity and / or account or data set without departing from the spirit and scope of the present invention. Request 170 is routed to global gateway 120 via a local area network (not shown), a wide area network (not shown), and / or other wired / wireless data communication connections. Global gateway 120 has been enhanced to provide a dynamic dispatch rules engine 130 in accordance with the illustrative embodiment.

[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 rules database 138. Assuming that no existing dynamic dispatch rules for the identity (APIKey) exist in the database 138, the global gateway 130 performs its normal load balancing-based routing of requests to the IAM instances 142, 152 regardless of the data storage boundaries 140, 150. Thus, in the depicted example, even though the data for Account 4 associated with the APIKey is actually stored in the backend database 156 associated with the EU IAM instance 152 in the geographic boundary 150, and the US IAM instance 142 cannot access the data for Account 4, the request may be routed to the US IAM instance 142 in the geographic boundary 140, e.g., a geographic location associated with the United States and its territories.

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

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

[0059] In the described example, in response to the global gateway 120 receiving the feedback response 174, the feedback interceptor 136 of the dispatch rule engine 130 intercepts the feedback response 174 and provides the feedback information to the dispatch rule generator 134, and the dispatch rule generator 134 generates / updates the dynamic dispatch rule for the specified identity (APIKey) and target location in the dynamic dispatch rule database 138. Thereafter, when a subsequent request 176 with the same identity is received from the same request source computing device 110 or another request source computing device, the lookup engine 132 will perform a lookup operation in the dynamic dispatch rule database 138, and will find a matching dynamic rule based on the identity (APIKey). As a result, the global gateway 120 will execute the matching dynamic dispatch rule and dispatch the request 176 directly to the IAM instance (e.g., EU IAM instance 152) associated with the target location (e.g., the backend database 156 associated with the EU IAM instance 152). This avoids having to perform calculations and network traffic when subsequent results 176 are sent to an incorrect IAM instance (eg, a US IAM instance) due to load balancing based routing.

[0060] It should be understood that Figure 1 The depictions in are merely example architectures and are not intended to state or imply any limitations regarding architectures in which aspects of the illustrative embodiments may be implemented. Although the depicted examples use the IBM IAM service and the global gateway as examples, the illustrative embodiments are not limited thereto. Rather, the dynamic dispatch engine 130 may alternatively be disposed in any architecture in which physical storage locations for storing sensitive data and dispatching / controlling access to such sensitive data need to be controlled, taking into account physical storage boundary requirements.

[0061] Figure 1 An overview of the operation of the major operating entities of an architecture according to one or more illustrative embodiments is provided. The architecture can be a cloud computing system architecture in which an IAM instance provides cloud computing services for performing identity and data access management. The management can include a global account management service that determines the target location of requested data, whether the requested data is associated with the IAM instance that received the request or with a different IAM instance. The process for performing the dispatch and forwarding of requests from the global gateway and / or from one IAM instance to another IAM instance involves multiple interactions between the major operating entities, which will now be described in detail in the data flow diagram below. Figure 2-Figure 3 The data flow diagram shown in will assume an exemplary illustrative embodiment based on a representational state transfer (REST) ​​API and IAM services, but it should be understood that the present invention is not limited thereto and other embodiments may use other APIs and services. Figure 2-Figure 3Reference will be made to REST API operations, such as POST, GET, etc., to facilitate this description, but is not intended to state or imply any limitation with respect to the architecture or API that may be used in combination with the mechanisms of the illustrative embodiments.

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

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

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

[0065] In response to the result 202 indicating that no dispatch rule was found, the global gateway 120 forwards the original call 201 to the next available IAM runtime cluster based on the load balancing algorithm, which in the depicted example is the IAM runtime in the EU geographic boundary 150, namely the EU IAM runtime 154. Therefore, the global gateway 120 forwards the POST / token (apikey=abc) call 201 to the EU IAM runtime 154 via the forward call 203. In response to receiving the transfer call 203, the EU IAM runtime 154 can perform pre-processing 204 of the APIKey to determine whether the APIKey is valid, and perform other operations to prepare to process the request (call) and access the requested data.

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

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

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

[0069] In response to determining in operation 209 that the request needs to be dispatched (call 201), 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 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 the request does not need to be dispatched because the US IAM runtime 144 can access the account detail data of the account "123" corresponding to the APIKey "abc" in the US IAM database 146. Therefore, the US IAM runtime 144 decides to continue to generate the token (the requested data) on the local cluster.

[0070] As a result, the US IAM runtime 144 retrieves the account details data for the APIKey from the US IAM database 146 by performing a “get apikey details” operation 217. The US IAM database 146 returns 218 the account details data 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, such as the EU IAM runtime 154 in this example. The EU IAM runtime 154 passes 221 the token to its caller, i.e., the global gateway 120, which sends the token to the original caller via operation 222.

[0071] Figure 3 is an example 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 an illustrative embodiment. Figure 3 The operation shown in Figure 2, except that in this case, the dynamic dispatch rules database 138 has an existing dynamic dispatch rule that matches the identity (APIKey) in call 301, resulting in the ability to skip the calculation of the target location for determining the corresponding account for the specified identity.

[0072] Therefore, if Figure 3 As shown, the operation begins when the client computing device 110 wants to obtain Figure 2 150. Again, the client does not know which data storage boundaries the API key is associated with, i.e., where the requested data is physically stored relative to the data storage boundaries 140, 150. As a result, the client 110 calls the global gateway 120 by executing a POST / token(apikey=abc) call 301.

[0073] In response to the call from the client 110, the dispatch rules engine 130 of the global gateway 120 performs a lookup of the dynamic dispatch rules in the dynamic dispatch rules database 138 via the lookup engine 132, and in this case, due to Figure 2 The previous request processing shown finds 302 a matching dynamic dispatch rule. The global gateway 120 executes the matching dynamic dispatch rule found in the database 138, and as a result, forwards 303 the call 301 to the US IAM runtime 144, which is known to be associated with the US IAM database 146, where the account detail data, i.e., the target location specified in the dynamic dispatch rule, is stored. The US IAM runtime 144 can execute the previously described Figure 2 Similar pre-processing 304 as described, and performing other similar operations 305-312, is used to obtain the account associated with the APIKey, obtain account detail data from the US IAM database 146, and generate a corresponding token.

[0074] It should be noted that in some illustrative embodiments, the global gateway 120 uses a dynamic dispatch rule mechanism that specifies that the APIKey "abc" is connected to the account "123" 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 verify the location of the account again. However, in other illustrative embodiments, some of these account location verification operations, such as operations 307 and 308, can be avoided because the global gateway 120 has an existing dispatch rule that specifies the US region and therefore does not have to be verified via GAMS 200. This information can be provided to the US IAM runtime 144 by the global gateway 120 so that operations 307, 308 can be removed from the depicted process. Both possibilities are intended to fall within the spirit and scope of the present invention and can be selected based on the desired implementation and security level.

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

[0076] Figure 4 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 illustrative embodiment. Figure 4As shown, the example feedback response specifies the target location as "dispatch_target", which in this example is the location "eu.iam.cloud.ibm.com". The context information of the feedback response includes the "apikey", which in this case is the apikey "ABCDEFG". Other details including method, contextpath, and param_name are a description of the operation for which the dynamic rule exists. That is, each REST request is of method GET, POST, PUT, or DELETE. Each REST request has a target context path, which in this depicted example is / identity / token. Depending on the target path, the functionality of the REST call is different. The example "param_name / param_value" portion describes for which parameters the rule is valid.

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

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

[0079] Figure 6A-6B Flowcharts outlining example operations of elements of the present invention with respect to one or more illustrative embodiments are presented. It should be understood that Figure 6A-6B The operations outlined in the description are specifically performed automatically by the improved computer tools of the illustrative embodiments and are not intended to and cannot actually be performed by humans as mental processes or through organized human activities. On the contrary, although humans may initiate the operations in some cases, Figure 6A-6B Execution of the operations described in , and in some cases can be used as Figure 6A-6B The consequences of the operations described in Figure 6A-6B The operations themselves are specifically performed in an automatic manner by improved computing tools.

[0080] Fig. 6A 1 is a flow chart outlining an example operation of a dispatch rules engine (such as dispatch rules engine 130) for a global gateway according to one illustrative embodiment. Fig. 6A As shown, the operation begins with receiving a request from a request source computing device, wherein the request specifies an identity for which access to the associated requested data is to be provided (step 601). The dispatch rule engine of the global gateway performs a lookup operation to determine whether there is an existing dynamic dispatch rule in the dynamic dispatch rule database that matches the identity in the request (step 602). If there is an existing dynamic dispatch rule that matches (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 there is no matching dynamic dispatch rule (step 603; no), the global gateway forwards the request to the next available service instance based on the 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 is received from the service instance to which the request was forwarded (step 606). If a feedback response is received, the feedback response is processed by a feedback interceptor, which extracts the feedback information, which is provided to a dispatch rule generator (step 607). The dispatch rule generator 607 automatically and dynamically generates / updates a dynamic dispatch rule for the specified identity in the original request, which specifies the actual target location of the requested data (step 608). As previously described with respect to Figure 1-Figure 5 As discussed, the actual target location can 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 instance can access the physical location. The feedback agent of the service instance runtime can provide feedback information to the global gateway. If the requested data (e.g. Figure 2-Figure 3 If the token in the data has not been received by the global gateway, the global gateway continues to wait for the data to be returned.

[0082] Thus, if the requested data (eg, token) is received, which may occur with or without having received a previous asynchronous feedback response, the requested data is forwarded to the original requester, ie, the request source computing device (step 609). The operation then terminates.

[0083] Figure 6B is a flow chart outlining an example operation of a service instance enhanced with a feedback agent according to one illustrative embodiment. Figure 6B As shown, the operation begins when the service instance receives a request (or call) from the global gateway to access data corresponding to a specified identity (step 610). When the service instance is running, it determines the data corresponding to the specified identity in the request by querying the backend service instance database (step 611), and then sends a request for the target location of the data to the global account management service (step 612). When the service instance is running, it receives the target location from the global account management service and determines whether the request needs to be dispatched to another service instance (step 613). If not (step 613; no), the service instance performs an operation to obtain the requested data from the 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), that is, 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 that specifies the identity in the original request, the target location returned by the global account management service, and other context information, such as the method used and the context path (step 616). The feedback response is sent asynchronously to the global gateway for generating / updating dynamic dispatch rules for the identity (step 617). The operation then terminates.

[0085] As can be clearly seen from the above description, the present invention can be a specially configured computing system, which is configured with hardware and / or software, which are themselves specially configured to implement the specific mechanisms and functions described herein; a method implemented by a specially configured computing system; and / or a computer program product, which contains software logic, which is loaded into a computing system to specially configure the computing system to implement the mechanisms and functions described herein. Whether described as a system, a method or a computer program product, it should be understood that the illustrative embodiments described herein are specifically directed to improved computing tools and methods implemented by the improved computing tools. Specifically, the improved computing tools of the illustrative embodiments specifically provide a dispatching rule engine for a global gateway infrastructure, which includes one or more computing devices that execute applications and services for processing identity and account management (IAM) across multiple different data storage boundaries. The improved computing tool implements mechanisms and functions, such as automatic and dynamic dispatching rule generation and execution for dispatching requests to target locations based on data storage boundaries, which operations and functions cannot be actually performed by humans, whether completely separated from the technical environment or with the assistance of the technical environment (such as psychological processes, etc.). The improved computing tool provides practical application of the method, at least because the improved computing tool is able to reduce computing 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 expensive operations for locating the physical target storage location of data associated with the identity specified in the data access request.

[0086] Figure 7 700 is an example diagram of an example computing environment in which aspects of the illustrative embodiments may be provided. Computing environment 700 includes an example of an environment for executing at least some of the computer code involved in executing the method of the present invention, such as by Figure 1 Similarly, the computing devices in the computing environment 700 may be configured to provide feedback agents, such as Figure 1 The feedback agents 143 and 153 in are configured to operate with the dispatch rules engine 130 of the global gateway 120 according to one or more illustrative embodiments described above.

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

[0088] Computer 701 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running 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, the execution of the computer-implemented method may be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of computing environment 700, the detailed discussion focuses on a single computer, particularly computer 701, to keep the presentation as simple as possible. Computer 701 may be located in the cloud, even if it is not in the cloud. Figure 7 On the other hand, except to any extent that can be indicated with certainty, there is no requirement that computer 701 be in the cloud.

[0089] Processor set 710 includes one or more computer processors of any type known now or developed in the future. Processing circuit 720 can be distributed over multiple packages, for example, multiple coordinated integrated circuit chips. Processing circuit 720 can implement multiple processor threads and / or multiple processor cores. Cache 721 is a memory located in (one or more) processor chip packages, and is generally used for data or code that should be available for fast access by threads or cores running on processor set 710. Cache memory is generally organized into multiple levels according to relative proximity to the processing circuit. Alternatively, some or all of the caches for the processor set may be located "off chip". In some computing environments, processor set 710 may be designed to work with qubits and perform quantum computing.

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

[0091] Communications fabric 711 is the signaling pathways that allow the various components of computer 701 to communicate with each other. Typically, the fabric is made of switches and conductive pathways, such as those that make up a bus, a bridge, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0092] Volatile memory 712 is any type of volatile memory now known or developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In computer 701, volatile memory 712 is located in a single package and internal to computer 701, but alternatively or additionally, volatile memory can be distributed over multiple packages and / or located externally relative to computer 701.

[0093] Permanent storage device 713 is any form of non-volatile storage device for computers known now or developed in the future. The non-volatility of the storage device means that the stored data is maintained regardless of whether the computer 701 is powered and / or directly powered to the permanent storage device 713. Permanent storage device 713 can be a read-only memory (ROM), but usually at least a portion of the permanent storage device allows writing data, deleting data, and rewriting data. Some familiar forms of permanent storage devices include disks and solid-state storage devices. Operating system 722 can take several forms, such as various known proprietary operating systems or operating systems of open source portable operating system interface types using a kernel. The code included in frame 200 is generally included in at least some of the computer codes involved in performing the method of the present invention.

[0094] The peripheral device set 714 includes a collection of peripheral devices of the computer 701. The data communication connection between the peripheral devices and other components of the computer 701 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection by a cable (such as a universal serial bus (USB) type cable), a plug-in type connection (e.g., a secure digital (SD) card), a connection through a local area communication network, and even a connection through a wide area network (such as the Internet). In various embodiments, the UI device set 723 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smart watches), keyboards, mice, printers, touchpads, game controllers, and tactile devices. The storage device 724 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. The storage device 724 can be permanent and / or volatile. In some embodiments, the storage device 724 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where it is necessary for computer 701 to have a large amount of storage (e.g., where computer 701 locally stores and manages a large database), the 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 IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

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

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

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

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

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

[0100] Some further explanation of virtualized computing environments (VCEs) will now be provided. A VCE can be stored as an "image". A new active instance of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user space instances (called containers). From the perspective of the programs running in them, these isolated user space instances typically behave like real computers. Computer programs running on a normal operating system can utilize all of the resources of the computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

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

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

[0103] It should be understood that once the computing device is configured in one of these ways, the computing device becomes a special-purpose computing device that is specifically configured to implement the mechanisms of the illustrative embodiments, rather than a general-purpose computing device. In addition, as described below, implementation of the mechanisms of the illustrative embodiments improves the functionality of the computing device and provides useful and specific results that facilitate automatic and dynamic dispatch rule generation / update and execution to perform more efficient and less computationally and network traffic costly request dispatches to service instances in consideration of data storage boundaries established by government or organizational regulations and / or policies.

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

[0105] A data processing system suitable for storing and / or executing program codes will include at least one processor that is directly or indirectly coupled to a memory element via a communication bus (e.g., a system bus). The memory element may include a local memory, a bulk memory, and a cache memory that are used during the actual execution of the program code, which provides temporary storage of at least some program codes in order to reduce the number of times that code must be obtained from the bulk memory during execution. The memory may be of various types, including but not limited to ROM, PROM, 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 the system directly or through intervening wired or wireless I / O interfaces and / or controllers, etc. I / O devices can take many different forms besides conventional keyboards, displays, pointing devices, etc., such as, for example, communication devices coupled through wired or wireless connections, including but not limited to smart phones, tablet computers, touch screen devices, voice recognition devices, etc. Any known or later developed I / O devices are intended to be within the scope of the illustrative embodiments.

[0107] A network adapter may also 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 an intermediate private or public network. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters for wired communications. Network adapters based on wireless communications may also be utilized, including but not limited to 802.11a / b / g / n wireless communication adapters, Bluetooth wireless adapters, and the like. Any known or later developed network adapter is within the spirit and scope of the present invention.

[0108] The description of the present invention has been presented for the purpose of illustration and description, and the description of the present invention is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The embodiments are selected and described in order to best explain the principles of the invention, the practical application, and to enable those of ordinary skill in the art to understand the various embodiments of the invention with various modifications suitable for the intended specific use. The terms used herein are selected in order to best explain the principles of the embodiments, the practical application, or the technical improvements to the technology found in the market, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

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, wherein each data storage boundary is defined by a provision or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological area; 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, wherein the feedback response specifies a target location associated with the second data storage boundary; In response to receiving the feedback response, automatically generating a dynamic dispatch rule specifying the identity and the target location, and storing the dynamic dispatch rule in a dynamic dispatch rule database; and A subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic dispatch rule database, the lookup operation finding a matching dynamic dispatch rule corresponding to the specified identity, and executing the matching dynamic dispatch rule to dispatch the subsequent request directly to a second service instance associated with the target location.

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

3. The method according to claim 1 or 2, wherein: 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; In response to not finding data corresponding to the identity in the backend service instance database, sending, by the first service instance, a target location request to the global account management service for a target location of the data; receiving, by the first service instance, the target location of the data from the global account management service; and The feedback response specifying the target location is sent by a feedback agent of the first service instance to the data processing system.

4. The method according to claim 3, 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.

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

6. The method according to claim 1, wherein: Processing the subsequent second request includes: 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 of the plurality of data storage boundaries corresponding to the identity as a second data storage boundary; transmitting the second request to the second service instance, wherein the second service instance is associated with the second data storage boundary; Receiving the data requested by the second request based on processing the second request at the second service instance to obtain the data requested by the second request from the target location; and Based on the data received from the target location, a response is transmitted to the requesting computing device that sent the second request.

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

8. The method according to claim 1, wherein: The identity specified in the first request is an API key corresponding to the data requested to be accessed by the first request, and wherein the data includes personally identifiable data of one or more accounts in a cloud computing environment, wherein the personally identifiable data of the one or more accounts is restricted to be stored within corresponding data storage boundaries of the multiple 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, and the global gateway computing system operates in conjunction with multiple different service instances across multiple data storage boundaries.

10. The method according to claim 9, wherein: The multiple different service instances are regional identity and access management (IAM) cloud service instances.

11. A computer program product comprising a computer-readable storage medium having a computer-readable program stored therein, wherein the computer-readable program, when executed on a computing device, causes 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, wherein each data storage boundary is defined by a provision or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological area; 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, receiving a feedback response from the first service instance, wherein The feedback response specifies a target location associated with the second data storage boundary; In response to receiving the feedback response, automatically generating a dynamic dispatch rule specifying the identity and the target location, and storing the dynamic dispatch rule in a dynamic dispatch rule database; as well as A subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic dispatch rule database, the lookup operation finding a matching dynamic dispatch rule corresponding to the specified identity, and executing the matching dynamic dispatch rule to dispatch the subsequent request directly to a second service instance associated with the target location.

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

13. The computer program product according to claim 11 or 12, wherein: 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; In response to not finding data corresponding to the identity in the backend service instance database, sending, by the first service instance, a target location request to the global account management service for a target location of the data; receiving, by the first service instance, the target location of the data from the global account management service; and The feedback response specifying the target location is sent by a feedback agent of the first service instance to the data processing system.

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. The computer program product according to one of claims 11 to 14, further comprising: Dispatching the first request to the second service instance by the first service instance; Receiving, by the first service instance from the second service instance, the data requested for access in the first request; generating a response to the first request based on the received data; as well as The response is sent to a requesting computing device that sent the first request.

16. The computer program product according to one of claims 11 to 15, wherein: Processing the subsequent second request includes: 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 of the plurality of data storage boundaries corresponding to the identity as a second data storage boundary; transmitting the second request to the second service instance, wherein the second service instance is associated with the second data storage boundary; Receiving the data requested by the second request based on processing the second request at the second service instance to obtain the data requested by the second request from the target location; and Based on the data received from the target location, a response is transmitted to the requesting computing device that sent the second request.

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

18. The computer program product according to one of claims 11 to 17, wherein: The identity specified in the first request is an API key corresponding to the data requested to be accessed by the first request, and wherein the data includes personally identifiable data of one or more accounts in a cloud computing environment, wherein the personally identifiable data of the one or more accounts is restricted to be stored within corresponding data storage boundaries of the multiple data storage boundaries.

19. The computer program product according to one of claims 11 to 18, wherein: The data processing system is a global gateway computing system of a cloud computing environment, and the global gateway computing system operates in conjunction with multiple different service instances across multiple data storage boundaries.

20. An apparatus comprising: at least one processor; and at least one memory coupled to the at least one processor, wherein the at least one memory comprises instructions that, when executed by the at least one processor, cause 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, wherein each data storage boundary is defined by a provision or policy that restricts data storage of one or more particular types of data to computing devices within a specified physical or network topological area; 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, wherein the feedback response specifies a target location associated with the second data storage boundary; In response to receiving the feedback response, automatically generating a dynamic dispatch rule specifying the identity and the target location, and storing the dynamic dispatch rule in a dynamic dispatch rule database; and A subsequent second request specifying the identity is processed at least by performing a lookup operation in the dynamic dispatch rule database, the lookup operation finding a matching dynamic dispatch rule corresponding to the specified identity, and executing the matching dynamic dispatch rule to dispatch the subsequent request directly to a second service instance associated with the target location.

Images