Application Integration Using Interaction Patterns

Abstract

The present disclosure relates to using interaction patterns to control communication between or integrate various applications. Interaction pattern data is generated that defines multiple roles of the interaction pattern. Each role is associated with a transaction and is either a source or a target of the transaction. The transaction is performed using an API (Application Programming Interface). Based on whether a role is a source or target of the transaction, the role may be a provider or a consumer of the API. Application suitability data is generated that represents a set of roles performed by applications. An application is allowed to invoke an API of another application if the application performs a first role and the other application performs a second role, and the first role and the second role are, respectively, a source and a target of a transaction performed using the API.

Description

[Technical field]

[0001]

[01] This patent application discloses various systems and methods relating to using interaction patterns to integrate applications. [Background technology]

[0002]

[02] Software in computer systems typically provides machine-to-machine interfaces, called application programming interfaces (APIs). These APIs can be used by one application to initiate a process or method in another application. APIs are typically formalized in machine-parsable formats, such as OpenAPI or Web Services Definition Language (WSDL). However, such specifications only provide the syntax (and partly the semantics) of messages to and from the services that implement the APIs. If multiple APIs are somehow related (e.g., a service may have to implement two APIs, or a service that implements one API needs to call other APIs), these API specification methods cannot represent these relationships. There may be cases where such multi-API interactions, and corresponding behavioral requirements, are specified. However, they are not captured in the machine-parsable definition and therefore cannot be used in application logic (e.g., for scaffolding or automating a multi-API test suite). Service registries typically expose services that can implement the server side of an API. What are typically not registered are the potential clients of such APIs. Without client registration, system dependencies cannot be queried, tracked, or controlled. Summary of the Invention

[0003]

[03] Accordingly, one or more aspects of the present disclosure relate to a method for controlling communication between a plurality of applications. The method is implemented by one or more processors executing one or more computer program instructions. When executed, the one or more processors realize the method for generating, for each of a plurality of interactions, interaction pattern data defining a plurality of roles. Each role is associated with a transaction performed with another role, and the transaction is performed using an API (Application Programming Interface). The method further includes generating, for each application of the plurality of applications, application suitability data defining a set of roles performed by the corresponding application. The method further includes generating application instance data including location data of a plurality of APIs associated with an instance of the application. The method includes controlling communication between a first application and a second application based on the interaction pattern data, the application suitability data, and the application instance data (collectively referred to as "configuration data").

[0004]

[04] Another aspect of the disclosure relates to a method for controlling communication between a plurality of applications. The method is implemented by one or more processors executing one or more computer program instructions. When executed, the one or more processors realize the method in a server, receiving a request from a first application of the plurality of applications to invoke a specified API associated with a second application of the plurality of applications. The method includes obtaining interaction pattern data from a storage system. The interaction pattern data defines each interaction of the plurality of interactions using a plurality of roles, each role consuming an API from or providing an API to another role. The method further includes obtaining application suitability data from the storage system. The application suitability data defines, for each application of the plurality of applications, a set of roles performed by the corresponding application. The method further includes determining, by the server, based on the application suitability data, that the first application performs the first role and the second application performs the second role, the interaction pattern data indicating that the first role consumes the specified API associated with the second role. The method further includes allowing, by the server, the first application to call the specified API of the second application.

[0005]

[05] Yet another aspect of the present disclosure relates to a system for controlling communication between a plurality of applications in a computer network. The system includes one or more processors, the one or more processors configured by machine-readable instructions to generate interaction pattern data defining each interaction of a plurality of interactions using a plurality of roles. Each role is associated with a transaction performed with another role, the transaction being performed using an API. The system is further configured to generate, for each application of the plurality of applications, application suitability data defining a set of roles performed by the corresponding application. The system is further configured to generate application instance data including location data of a plurality of APIs associated with an instance of the application. The system is further configured to control communication between a first application and a second application based on the configuration data.

[0006]

[06] Yet another aspect of the present disclosure relates to a system for controlling communication between multiple applications in a computer network. The system includes one or more processors, the one or more processors configured by machine-readable instructions to obtain configuration data from a configuration subsystem, the configuration data including interaction pattern data, application suitability data, and application instance data. The interaction pattern data defines interactions using multiple roles, each role being a consumer of an application programming interface (API) or a provider of an API. The application suitability data defines a set of roles performed by an application, and the application instance data may include network addresses of multiple APIs associated with an instance of the application. The system may further configure a gateway subsystem to generate network route data for routing a request from a first application to access a specified API associated with a second application to a specified network address associated with the specified API based on the configuration data. The system is further configured to control communication between the first application and the second application via the gateway subsystem based on the configuration data.

[0007]

[07] The above and other objects, features, and characteristics of the present disclosure, as well as the method of operation and function of the associated structural elements, combination of parts, and economies of manufacture will become more apparent from a consideration of the following description and appended claims, taken in conjunction with the accompanying drawings, all of which form a part hereof, and in which like reference numerals represent corresponding parts in the various drawings. It is, however, to be expressly understood that the drawings are for the purpose of illustration and description only and are not intended to define the scope of the present disclosure. [Brief description of the drawings]

[0008] [Figure 1A-1B]

[08] Figures 1A and 1B illustrate systems for controlling (coordinating or facilitating) communications between applications in a computer network, according to various embodiments. [Diagram 2]

[09] FIG. 2 illustrates a representation of a patient data exchange interaction pattern, according to various embodiments. [Diagram 3]

[10] FIG. 3 illustrates a representation of an application configured to perform roles from various interaction patterns, according to various embodiments. [Figure 4]

[11] FIG. 4 illustrates a data structure used to generate configuration data, according to various embodiments. [Diagram 5]

[12] FIG. 5 illustrates a flowchart of a method for controlling communication between applications, according to various embodiments. [Figure 6]

[13] FIG. 6 illustrates a flowchart of a method for controlling communication between a first application and a second application according to various embodiments. [Figure 7]

[14] Figure 7 illustrates a flowchart of a method for performing a discovery process, according to various embodiments. [Figure 8]

[15] FIG. 8 illustrates a flowchart of a method for implementing an approval process, according to various embodiments. [Figure 9]

[16] FIG. 9 illustrates a computer system for performing one or more of the above aspects, according to various embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009]

[17] As used herein, the singular forms "a," "an," and "the" include plural references unless the context clearly contradicts otherwise. As used herein, the term "or" means "and / or" unless the context clearly contradicts otherwise. As used herein, the term "number" means an integer number equal to or greater than one (i.e., a plurality).

[0010]

[18] In the claims, reference signs between parentheses shall not be interpreted as limiting the claims. The word "comprises" or "including" does not exclude the presence of other elements or steps than those listed in a claim. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The word "a" or "an" does not exclude the presence of a plurality of such elements. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that several elements are recited in mutually different dependent claims does not indicate that a combination of these elements cannot be used.

[0011]

[19] Figure 1A illustrates a system 100 for controlling (coordinating or facilitating) communication between applications in a computer network, according to various embodiments. In some embodiments, the system 100 includes a configuration subsystem 112 (e.g., one or more servers or other computer systems), a gateway subsystem 114 (e.g., one or more servers or other computer systems), a metering subsystem 116 (e.g., one or more servers or other computer systems), and an application subsystem 118 (e.g., one or more servers or other computer systems). The application subsystem 118 can host multiple applications (e.g., healthcare-related applications), such as a first application 110a (e.g., a patient program provider application) and a second application 110b (e.g., a patient severity stratification application).

[0012]

[20] The system 100 facilitates controlling communication between applications 110 based on interaction patterns that define actions taken by one or more applications to achieve a common goal. The configuration subsystem 112 can facilitate generation of configuration data 125 that can be used in controlling communication between applications. The configuration data 125 includes interaction pattern data 126 that defines interaction patterns in terms of roles, transactions, application programming interfaces (APIs), and their interdependencies. For example, a role is associated with a transaction that is performed with another role using the associated API. A role can be a source of a transaction (e.g., a consumer of an API associated with the transaction) or a target of a transaction (e.g., a provider of an API associated with the transaction). The configuration data 125 includes application suitability data 127 that defines a set of roles performed by an application. In some embodiments, the roles performed by an application can be used to determine other applications and their associated APIs that the application can access. Additionally, configuration data 125 includes application instance data 128, which specifies location data for APIs associated with an instance of an application (e.g., a uniform resource locator (URL) for an endpoint, such as a server or other computer system, that hosts the API). In general, configuration data 125 may be used in determining permitted interactions between applications (e.g., which APIs of an application can call which APIs of other applications based on defined roles).

[0013]

[21] The configuration subsystem 112 also provides a discovery API to find applications accessible by an application and the APIs associated with those applications. An application can use the discovery API to obtain a list of applications accessible by the application and the APIs associated with those applications. In some embodiments, the discovery API can use configuration data 125, such as the roles performed by the application (e.g., the roles performed by the source application and the target application) and the APIs associated with those roles, to determine the list of applications accessible by the application and the APIs associated with those applications.

[0014]

[22] The configuration subsystem 112 also provides an authorization API that can be used by the application subsystem 118 to provide an authorization decision on whether a particular application should accept a request from another application. If so, the authorization API can also inform the requesting application which APIs of the particular application it can access (based on configuration data 125, such as the roles performed by the application and the APIs associated with those roles). In this manner, the system 100 provides role-based access control, but at the application level rather than the user level.

[0015]

[23] The gateway subsystem 114 facilitates the generation of network route data and the configuration of gateways to route API access requests from a requesting application to a requested API. The gateway subsystem 114 can act as an intermediary between applications (e.g., receiving API access requests from a requesting application and routing the API access requests to an appropriate endpoint having the requested API). The gateway subsystem 114 generates the network route data using configuration data 125, such as location data of APIs. The gateway subsystem 114 can also add tags (e.g., interaction pattern name, source API, source application, destination application, or destination API) to network traffic (e.g., application interactions such as API access requests and responses) passing through the gateway subsystem 114, which can be used for metering or other analysis purposes.

[0016]

[24] The metering subsystem 116 facilitates the collection and aggregation of metering data, which may be used to generate reports having any of a variety of analytical results. Interactions passing through the gateway subsystem 114 are tagged and categorized based on the tags so that reports can be generated that represent various types of interaction pattern knowledge. Examples of reports include business reports, financial reports, operational reports, and security reports on ecosystem usage. These reports may include analytics such as the types of interaction patterns used by applications, the amount of interaction between pairs of applications, or other such performance metrics associated with applications.

[0017]

[25] Further details of system 100 are described below with reference to at least FIG. 1B.

[0018]

[26] Figure 1B illustrates a detailed diagram of a system 100 for controlling communications between applications in a computer network, according to various embodiments. In some embodiments, system 100 includes a computer system 102 (e.g., one or more servers or other computer systems), a provider client device 104, and a database 130. Although only a single provider client device 104 is shown, system 100 may include multiple provider client devices that are the same as or similar to provider client device 104. Computer system 102, provider client device 104, and database 130 are configured to be operatively coupled to each other such that each of computer system 102, provider client device 104, and database 130 can communicate with each other or with other components, devices, and systems over network 150. For example, network 150 may be accessed by any component of system 100 using Transfer Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP) (e.g., any of the protocols used at each TCP / IP layer), Hypertext Transfer Protocol (HTTP), WebRTC, SIP, and wireless application protocol (WAP). In one embodiment, network 150 facilitates components of system 100 or other components to communicate with each other via a web browser using HTTP.Various additional communication protocols that may be used to facilitate communication between components of system 100 include, but are not limited to, Wi-Fi (e.g., 802.11 protocols), Bluetooth, radio frequency systems (e.g., 900 MHz, 1.4 GHz, and 5.6 GHz communication systems), cellular networks (e.g., GSM, AMPS, GPRS, CDMA, EV-DO, EDGE, 3GSM, DECT, IS-136 / TDMA, iDen, LTE, or any other suitable cellular network protocol), infrared, BitTorrent, FTP, RTP, RTSP, SSH, and / or VOIP.

[0019]

[27] Databases 130 include one or more interaction pattern databases 132, one or more application suitability databases 134, one or more application instance databases 136, and one or more report databases 138. In some embodiments, system 100 includes multiple instances of databases 130. For simplicity, however, a single instance of each of one or more databases 130 is depicted. For example, "interaction pattern database 134" as described herein may refer to a single interaction pattern database or multiple interaction pattern databases. Each of the databases included in databases 130 may be a distributed database, a cloud-based storage database, or the like.

[0020]

[28] The provider client device 104 interacts with the computer system 102 (e.g., to access applications hosted by the computer system 102). In some embodiments, the provider client device 104 is associated with a provider at a care facility. The care facilities described herein include a general hospital, a psychiatric hospital, or any other medical institution, clinic, or community assisted living community, or other type of long-term (e.g., overnight) care facility. Also, the provider may be a doctor, a nurse, a technician, an emergency medical provider, a social worker, or a family member. The provider client device 104 may be a wearable device and / or one or more mobile computing devices. In some embodiments, the provider client device 104 includes a computing device (e.g., a desktop or laptop computer, a tablet, or a smartphone) assigned to the provider that is capable of running an application (e.g., one of the applications hosted by the computer system 102). In some embodiments, the provider client device 104 may also be a computing device that is capable of running a cloud-hosted application (e.g., one of the applications hosted by the computer system 102), such as a care provider application. For example, the care provider application can receive notifications from the computer system 102 indicating the effects of a combination of prescribed medications. Additionally, the care provider application may interface directly (e.g., as an add-on) with an electronic health record (EHR) application (e.g., hosted by the computer system 102) to provide notifications regarding prescribed medications while the care provider is reviewing the patient's EHR. Alternatively, the care provider application may interface with a reports database 138 that can be used by the EHR application to access medication data from the EHR application.

[0021]

[29] In some embodiments, computer system 102 includes configuration subsystem 112, gateway subsystem 114, metering subsystem 116, and application subsystem 118. Additionally, computer system 102 may include one or more processors 120, memory 122, and / or other components. Memory 122 may include computer program instructions that, when executed by processor 120, effect the performance of operations, including the performance of functions of any of subsystems 112-118. Computer program instructions may refer to machine-readable instructions stored in memory 122 and automatically executable by processor 120 in response to a request to perform a particular function or functions, or both. Memory 122 may include a tangible program carrier, such as a non-transitory computer-readable storage medium.

[0022]

[30] In some embodiments, as described with reference to at least FIG. 1A, the application subsystem 118 is configured to host multiple applications (e.g., healthcare-related applications), such as a first application 110a (e.g., a patient program provider application) and a second application 110b (e.g., a patient severity stratification application). The application subsystem 118 may execute as one or more servers or other computer systems. Additionally, the application subsystem 118 may execute as a cloud-based platform, which may provide access to one or more of the applications to multiple tenants (e.g., care facilities). In some embodiments, the application subsystem 118 may host separate instances of the applications for each tenant. For example, a first set of instances of the first and second applications may be hosted for a first care facility (e.g., represented by the provider client device 104), and a second set of instances of the first and second applications may be hosted for a second care facility (e.g., which may be represented by another provider client device similar to the provider client device 104). However, for simplicity, one set of instances for a single care facility may be described in the disclosed embodiments. Additionally, some applications may be hosted by one or more servers or other computer systems within the care facility's computer network (e.g., the same computer network as the provider client devices 104). An application provides one or more APIs that can be used / accessed / invoked by another application to communicate with the application (e.g., consume data from the application or provide data to the application).

[0023]

[31] In some embodiments, the configuration subsystem 112 is configured to generate configuration data 125 that can be used by the computer system 102 to control communication between applications. For example, when a first application 110a being accessed by the provider client device 104 requests access to a specified API of a second application 110b, the computer system 102 can determine whether to allow the first application 110a to access the specified API by analyzing the configuration data 125. The configuration data 125 represents interactions performed by the applications in terms of interaction patterns, roles, transactions, APIs, and application interdependencies. Based on these, the computer system 102 can determine how to control communication between the applications.

[0024]

[32] The configuration subsystem 112 may provide a graphical user interface (GUI) for defining / generating the interaction pattern data 126. A user (e.g., an application developer) may use the GUI to generate the interaction pattern. In some embodiments, generating the interaction pattern includes defining a number of roles and configuring the roles as a source or target of a transaction. In some embodiments, a transaction is a communication path between two roles. A transaction may use one or more APIs to perform an operation. Furthermore, if a role is configured as a source of a transaction, the role is a consumer of the API associated with the transaction. If a role is configured as a target of a transaction, the role is a provider of the API associated with the transaction. In some embodiments, when two roles are associated with a transaction, the two roles may communicate with each other. If a first role and a second role must be able to communicate, the first role and the second role may have to be associated with the transaction. It will be appreciated that a transaction may determine which roles can call which other roles.

[0025]

[33] As an example, a patient data exchange interaction pattern 200 is described with at least reference to FIG. 2. In some embodiments, the patient data exchange interaction pattern is an interaction that can be used to exchange patient data between two or more applications. The patient data exchange interaction pattern 200 includes roles such as a patient data source, a patient data sink, a patient data store, a patient data consumer, a patient data location index, or a patient data identity consumer. The role "patient data store" 202 and the role "patient data consumer" 204 are connected / associated by a transaction "data query" 206. The role "patient data consumer" 204 is the source of the transaction "data query" 206, and the role "patient data store" 202 is the target of the transaction "data query" 206. That is, the role "patient data consumer" 204 can call an API 212 associated with the transaction "data query" 206 of the application that executes the role "patient data store" 202. Examples of such APIs include "FHIR-Read", which refers to read operations on the Fast Healthcare Interoperability Resources (FHIR) interface, or "DICOM-Web-read", which refers to all read operations on the Digital Imaging and Communications in Medicine (DICOM)-web interface.

[0026]

[34] In some embodiments, an interaction pattern can also include a dependent role, which is a role that depends on another role. When a role depends on another role, the dependent role inherits all of the requirements of the role on which the dependent role depends, including the provisioning of required APIs. This dependency can be used to extract common functionality into separate roles. As an example, in the patient data exchange interaction pattern 200, the role "location index" 208 depends on the role "patient data consumer" 204. The role "location index" 208 and the role "patient data consumer" 204 are associated with the transaction "index query" 210, and the role "patient data consumer" 204 is the source of the transaction 210. In some embodiments, the role "location index" 208 allows the role "patient data consumer" 204 to find which data stores have data about a particular patient. By relying on role “patient data consumer” 204, role “location index” 208 may also function like role “patient data consumer” 204 ​​and provide or consume APIs that role “patient data consumer” 204 ​​provides or consumes. Role “location index” 208 may query one or more data stores like role “patient data consumer” 204 ​​and then build an index of the data stores, which may then be queried / consumed by role “patient data consumer” 204.

[0027]

[35] The configuration subsystem 112 can store the interaction pattern data 126 (including information about interaction patterns, roles, transactions, and APIs) in a database, such as a registry or interaction pattern database 134. In some embodiments, once an interaction pattern is stored in the interaction pattern database 134, the interaction pattern is considered "registered," meaning that the interaction pattern (e.g., the roles and transactions of the interaction pattern) is available to be performed by an application. A user (e.g., an application developer) can configure an application to perform one or more roles using the interaction patterns stored in the interaction pattern database 134. This effectively controls the integration or communication between the applications.

[0028]

[36] In some embodiments, the configuration subsystem 112 also provides a GUI for generating application suitability data 127. The application suitability data 127 represents a set of roles performed by an application. In some embodiments, configuring an application to perform a role allows the application to consume (e.g., call) one or more APIs provided by other applications or to provide one or more APIs for consumption by other applications. As an example, to enable a first application to call a specified API of a second application, the interaction pattern database 132 may be searched to identify an interaction pattern having a first role and a second role that are a source and a target, respectively, of a transaction performed using the specified API. The first application may then be configured to perform the first role, and the second application may be configured to perform the second role.

[0029]

[37] As an example, FIG. 3 shows a GUI 300 displaying various applications and roles performed by the applications. The configuration subsystem 112 makes available to a user (e.g., an application developer) all registered interaction patterns, i.e., interaction pattern data 126 from the interaction pattern database 132, and allows the user to configure the application to perform one or more roles. The user may select one or more of the roles and define the application interaction accordingly. The GUI 300 in FIG. 3 shows an application Patient Severity Stratifier 302, an application Patient Program Provider 304, an application Questionnaire Provider 306, and a Care Application 308 configured to perform roles from various interaction patterns. However, for simplicity, in the following paragraphs, the configuration of the application with respect to roles from the Patient Data Exchange interaction pattern 200 is described.

[0030]

[38] The application Patient Severity Stratifier 302 is configured to perform the role “Patient Data Store” 202 and the role “Patient Data Consumer” 204 ​​from the Patient Data Exchange Interaction Pattern 200. The application Patient Programs Provider 304 is configured to perform the role “Patient Data Store” 202. The application Questionnaire Provider 306 is configured to perform the role “Patient Data Store” 202. The Care Application 308 is configured to perform the role “Patient Data Location Index” 208.

[0031]

[39] The above application compatibility data 127 may mean the following regarding application interactions: (a) the application Patient Severity Stratifier 302 can call APIs of these applications provided by the role “Patient Data Store” 202 performed by the application Patient Severity Stratifier 302, the Patient Program Provider 304, and the Questionnaire Provider 306; (b) the application Patient Severity Stratifier 302 can call APIs of the Care Application 308 provided by the role “Location Index” 208 performed by the Care Application 308; (c) the role “Location Index” 208 performed by the Care Application 308 depends on the role “Patient Data Consumer” 204 ​​performed by the application Patient Severity Stratifier 302, so the Care Application 308 can call APIs that the application Patient Severity Stratifier 302 can call.

[0032]

[40] Although not described in detail, the application patient severity stratifier 302 is also configured to perform roles from other interaction patterns, such as the survey requester role from the survey interaction pattern and the introducer role from the patient referral interaction pattern. Similarly, the application patient program provider 304 is configured to perform roles from other interaction patterns, such as the “program provider” role from the patient referral interaction pattern. Similarly, the application questionnaire provider 306 is configured to perform roles from other interaction patterns, such as the “survey provider” role from the survey interaction pattern.

[0033]

[41] The GUI 300 also illustrates the associations between roles using arrows that indicate the transactions with which the roles are associated. For example, the "Patient Data Consumer" 204 in the application Patient Severity Stratification 302 is linked to the role "Patient Data Store" 202, which is performed by the application Patient Severity Stratification 302, the application Patient Program Provider 304, and the application Questionnaire Provider 306. This indicates that the Patient Severity Stratification 302 can communicate with the Patient Program Provider 304 and the Questionnaire Provider 306 through APIs associated with the transactions that link these roles. However, because the association between transactions and roles is defined as part of the interaction pattern, the user may not need to associate these roles with transactions when defining the application interactions.

[0034]

[42] After the application interactions are defined, application suitability data 127 (including information about the application and the roles performed by the application) is stored in application suitability database 134. Application suitability database 134 stores a list of applications configured to perform one or more roles. In some embodiments, application suitability database 134 serves as a "marketplace" where users (e.g., application developers) may search for compatible applications and their capabilities to integrate with other applications (e.g., based on the roles performed by the application).

[0035]

[43] In some embodiments, the configuration subsystem 112 uses one or more data structures to store the configuration data 125. FIG. 4 illustrates data structures used to define / generate / store the configuration data 125, including interaction pattern data 126, application suitability data 127, and application instance data 128. As an example, the interaction pattern data 126 is stored in the interaction pattern database 134 using a first data structure 450. In some embodiments, the data structure includes multiple attributes and relationships that define the data stored using the data structure. The first data structure 450 includes an interaction pattern attribute 451, which may specify a name or identification (ID) and a version or other information related to the interaction pattern. The role attribute 452 specifies the name or ID of the role performed by the interaction pattern. Multiple such roles may be defined for an interaction pattern. The transaction attribute 453 specifies the name or ID of the transaction. The API attribute 454 specifies the name and version of the API. In some embodiments, the API name is unique across applications. The options attribute 455 defines one or more features of the API that can be enabled or disabled. As an example, one of the options is "sensitive," which allows the API to retrieve data classified as sensitive or personal data associated with a patient that would not be retrieved if the option was not set to "sensitive." Also, specifying options for an API may be optional.

[0036]

[44] Relationship attributes define relationships between various attributes. As an example, role-transaction relationship attribute 456 defines the relationship between a role and a transaction. For example, a role can be the source or target of an associated transaction. A role's role dependency attribute 457 specifies another role on which the role depends. Transaction API attribute 458 specifies one or more APIs used to perform the transaction. API-options attribute 459 specifies one or more options associated with the API.

[0037]

[45] In some embodiments, application suitability data 127 is stored in application suitability database 134 using a second data structure 460. Second data structure 460 includes application attributes 461, which may specify a name or identification (ID), or other information related to the application. Role attributes 462 specify the names of roles performed / supported by the application. Multiple such roles may be performed by the application. Options attributes 463 define one or more features of the application that may be enabled for interaction with other applications. Also, specifying options for an API may be optional.

[0038]

[46] In some embodiments, application instance data 128 is stored in application instance database 136 using a third data structure 470. The third data structure 470 includes an application instance attribute 471, which may specify an ID or other information of the application instance. As previously mentioned, in some embodiments, an application instance is a logical instance of an application and may refer to an independent customer deployment of an application or a configured tenant in a shared deployment of the application. For example, if an application is deployed for two care facilities, there may be two separate instances of the application. The application instance associated with the first care facility may have a first instance ID and the application instance associated with the second care facility may have a second instance ID. The API location attribute 472 specifies location data (e.g., IP address, URL, or other such network address of the endpoint) of the API of the application instance. The options attribute 473 defines one or more features of the application that may be enabled for interaction with other applications. For example, the options attribute may be used to define whether a role performed by the application is enabled or disabled for a particular instance of the application. Also, specifying options for the API may be optional. In some embodiments, application instances associated with a particular customer are further tagged with a group ID, and typically the application instance can communicate with other application instances that have the same group ID.

[0039]

[47] Permission data 480 defines application permissions. For example, permission data 480 defines a list of applications that can access the first application, regardless of or independent of the role performed by the first application. In another example, permission data 480 defines a group of applications accessible by the first application. In yet another example, permission data 480 defines whether the first application can access a particular role of the second application, regardless of or independent of whether the first application and the second application perform roles associated with a transaction in which the first application is the source of the transaction and the second application is the target of the transaction.

[0040]

[48] ​​In some embodiments, controlling communication may include discovering a list of APIs that an application can call, determining whether an application can call a specified API, or authorizing a server to accept API access requests from a client device. The configuration subsystem 112 performs a configuration analysis to determine how to control communication between applications. For example, as part of the configuration analysis, the configuration subsystem 112 may determine that the first application 110a is registered in the application suitability database 134 as offering some integration capabilities based on the presence of an instance of the first application 110a in the application instance database 136. Then, from the application suitability database 134, using the second data structure 460, the configuration subsystem 112 may determine that the first application 110a is performing a set of roles from the interaction pattern database 132. Then, from the interaction pattern database 134, using the first data structure 450, the configuration subsystem 112 can determine a subset of the first roles that are sources of transactions and determine the APIs associated with these transactions as APIs callable by the first application 110a. Similarly, the configuration subsystem 112 can determine a subset of the second roles that are targets of transactions and determine the APIs associated with these transactions as APIs executed by the first application 110a for consumption by other applications.

[0041]

[49] In some embodiments, a user (e.g., an application developer) may configure one or more endpoints to host APIs with a subset of the second roles and update the location data of those APIs in application instance data 128 (e.g., in API location attribute 472 in third data structure 470 for the instance associated with first application 110a) accordingly.

[0042]

[50] In another example, performing a configuration analysis to determine that an instance of a first application 110a can access a specified API associated with a second application 110b may include (a) determining, based on the access permission data 480, that the instance of the first application 110a is authorized to communicate with the instance of the second application 110b; (b) determining, based on the application suitability data 127, that the first application 110a is performing a first role and the second application 110b is performing a second role; and (c) determining, based on the application instance data 127, that the instance of the first application 110a is authorized to communicate with the instance of the second application 110b. 8, (d) determining that a transaction is defined between the first role and the second role, where the first role is a source of the transaction and the second role is a target of the transaction, based on interaction pattern data 126; and (e) determining that the transaction is defined to use the API, based on interaction pattern data 126.

[0043]

[51] The configuration subsystem 112 provides a discovery API, which may be used by an application to determine APIs that may be called by the application. The process of discovery may include multiple operations. As an example, in a first operation, a first application 110a running by a provider client device 104 may request the computer system 102 to provide a list of APIs accessible by the first application 110a. The computer system 102 may return a first response with details of the location of an endpoint (e.g., a server or other computer system) hosting the discovery API. In some embodiments, the first response may include the following details: { ... authorization_endpoint:“https: / / iam.hsdp....” token_endpoint:“https: / / iam.hsdp.ph.com / ...” ... introspect_endpoint:“https: / / cce.ph.com / ... / introspect” discovery_endpoint:https: / / cce.ph.com / ... }

[0044]

[52] The authorization endpoint is an endpoint where a provider client device 104 can prove its identity to the computer system 102 and obtain an access token from the token endpoint after successful authentication. The discovery endpoint specifies the location of an endpoint that hosts the discovery API.

[0045]

[53] In a second operation of the discovery process, the provider client device 104 can send a request to the discovery endpoint to call the discovery API. The provider client device 104 can also provide an access token in the request. The discovery endpoint processes the access token to verify that the provider client device 104 is authorized to call the discovery API and returns a second response to the provider client device 104. The second response can include a list of APIs that are accessible (e.g., callable) by the first application 110a and a list of APIs that are executed (e.g., provided) by the first application 110a. In some embodiments, the second response can include a discovery document having the following information: { ... self:{ application_id:“1234-23-23-4235” apis:[{ }] ... } applications:[{ application_id:“1234-23-23-4235” name:“human readable name of the application” description:“human readable description of service” apis:[{ pattern:PDX role:Store transaction:fhir-query api:fhir-read base_url:https: / / cce.ph.com / 1234-23-23-4235 / fhir / options:[“sensitive” ] }] }] exp:59874327 }

[0046]

[54] In some embodiments, the self section of the second response indicates (a) the APIs that the first application 110a is configured to provide / expose / execute for consumption by other applications, and (b) location data of the endpoints where those APIs can be accessed.

[0047]

[55] The applications section of the second response provides a list of applications (e.g., "application_id") that may be called by the first application 110a, and the APIs (e.g., "api") associated with those applications. The applications section also includes location data (e.g., "base_URL") of the endpoints where the APIs are hosted by the corresponding applications. In some embodiments, the APIs are tagged with IDs of associated interaction patterns, roles, and transactions (e.g., obtained from the data structures described above).

[0048]

[56] Additionally, the second response also includes an expiration indicator (e.g., “exp”) indicating an expiration date or time for the details provided in the second response. After the expiration date has passed, the provider client device 104 may have to call the discovery API again to obtain a new list of APIs. The new list of APIs may or may not have been modified from the previously obtained list of APIs. In some embodiments, the provider client device 104 may cache the list of APIs in a memory associated with the provider client device 104 and reference the cached list instead of calling the discovery API. This may save computing or networking resources. However, after the expiration date of the cached list of APIs has passed, the provider client device 104 may have to call the discovery API to obtain a new list of APIs.

[0049]

[57] In some embodiments, the discovery API can determine the list of APIs callable by the first application 110a based on the configuration analysis (e.g., analysis of the configuration data 125 using the three data structures 450, 460, and 470). After obtaining the list of APIs from the discovery API, the first application 110a running on the provider client device 104 can select a specified API from the list of APIs and send a request to a specified endpoint hosting the specified API associated with the second application 110b to access the specified API.

[0050]

[58] When the designated endpoint receives a request from a provider client device 104 to access a designated API, the designated endpoint performs a check to determine whether the first application 110a is authorized to access a second application hosted by the server endpoint and whether the first application 110a is authorized to access the designated API of the second application. In some embodiments, the configuration subsystem 112 provides an authorization API that the designated endpoint can use to determine authorization. For example, upon receiving an API access request from the first application 110a running on the provider client device 104, the designated endpoint invokes the authorization API at the authorization endpoint with a pair of access tokens, one of which is associated with the designated endpoint and the other of which is received from the provider client device 104 (e.g., as described above in connection with at least the discovery API). The authorization API processes the access tokens to determine that an instance of the first application 110a is requesting to invoke an instance of the second application. The authorization API then determines whether the instance of the first application 110a is authorized to invoke the instance of the second application 110b using the access permission data 480. If the access permission data 480 indicates that the first application 110a is not authorized to access the second application 110b, the authorization API returns an indication thereof to the designated endpoint, which may further inform the provider client device 104 that its access to the second application is restricted.On the other hand, if the access permission data 480 indicates that the first application 110a is authorized to access the second application 110b, the authorization API returns a response to the specified endpoint indicating a list of APIs that the first application 110a is authorized to access. In some embodiments, the response from the authorization API may include the following information: { active:true scope:['fhir-read','fhir-read-sensitive'] client_id:'1234-56-7980' group_id:'id x' exp:59874327 }

[0051]

[59] In some embodiments, the "active" attribute indicates whether the API access request should be granted by the specified endpoint. The "scope" attribute indicates a list of APIs that the first application can access at the specified endpoint. The "client_id" is a unique identifier of the requesting application (e.g., the first application 110a). The "group_id" attribute indicates the deployment group of the interaction. As noted above, in some embodiments, an instance is allowed to communicate with other instances in the same group ID. In some embodiments, the group ID may indicate a tenant ID in a multi-tenant cloud platform, where the tenant ID may represent a deployment for a particular entity (e.g., a care facility). The cloud platform may support deployment of applications for multiple tenants, where each tenant has a unique group ID, and instances of the application for each tenant are grouped under a corresponding group ID. The validity indicator "exp" indicates a time value for which the response is valid (and thus the time for which the response can be cached at the server endpoint to prevent subsequent calls to the authorization API).

[0052]

[60] After the designated endpoint receives the authorization response from the authorization endpoint, the designated endpoint may determine whether the designated API requested by the first application 110a is included in the list of APIs from the authorization response, and if so, allow the first application 110a to access the designated API.

[0053]

[61] In some embodiments, similar to the discovery API, the authorization API can determine a list of APIs accessible by the first application 110a based on the configuration analysis described above (e.g., analysis of the configuration data 125 using the three data structures 450, 460, and 470).

[0054]

[62] In some embodiments, the gateway subsystem 114 facilitates the generation of network route data and the routing of API access requests from a requesting application to a requested API based on the network route data. The gateway subsystem 114 analyzes the configuration data 125 (e.g., by performing configuration analysis as described above) to determine a list of APIs that an application can call and the location data of the APIs (e.g., the URL of the endpoint hosting the API), and generates the network route data accordingly. The network route data is then used to configure the gateway and route the access request accordingly. For example, when the provider client device 104 accesses a specified API located at a specified endpoint indicated in the discovery document, the discovery endpoint notifies the provider client device 104 to send the request to the gateway subsystem 114, and the gateway subsystem 114 routes the access request to the specified endpoint based on the network route data. In some embodiments, the discovery API may replace the URL of the specified API in the discovery document with the URL of a gateway instance that can route the request from the provider client device 104 to the specified API at the specified endpoint. Thus, when a provider client device 104 accesses the gateway's URL, the gateway may route the API access request to the specified endpoint. The gateway subsystem 114 can be configured using a variety of methods. In some embodiments, the gateway subsystem 114 is configured using the Envoy Proxy configuration API.

[0055]

[63] In some embodiments, in a multi-cloud platform setup, a network of gateways may be configured. For example, if one application is in one network zone (e.g., off-premise cloud infrastructure, such as outside a care facility's computer network) and another application is in a second network zone (e.g., on-premise cloud infrastructure, such as inside a care facility's computer network), a gateway may be placed at the edge of each network zone (e.g., one in the on-premise cloud infrastructure and one outside the on-premise cloud infrastructure). In that case, the gateway is configured to route external traffic to internal services, and vice versa, to route requests from the internal services through other proxies to associated services elsewhere. In some embodiments, to enable routing of such requests across network zones, applications may have to be tagged with the network zone ID in which they are located. In that case, the gateway subsystem 114 may generate network route data based on the network zone.

[0056]

[64] Additionally, in some embodiments, because the gateway subsystem 114 has access to the configuration data 125, the gateway subsystem 114 can determine the interaction patterns, server endpoints, requesting applications, and destination applications / APIs associated with the network traffic passing through the gateway subsystem 114. The gateway subsystem 114 can append tags (e.g., interaction pattern names, source APIs, source applications, destination applications, destination APIs, server endpoints, or other information) to the network traffic (e.g., application interactions such as API access requests and responses) passing through the gateway subsystem 114 to generate tagged access logs. The gateway subsystem 114 can store the tagged access logs in the report database 138.

[0057]

[65] As an example, the metering subsystem 116 can analyze the tagged access logs to generate reports with any of a variety of analytical results. Examples of reports include, for example, usage reports that indicate how many interactions of a particular interaction pattern type (e.g., patient data exchange) occurred. The reports may be further categorized based on various parameters, such as the requesting application and the requested application. The reports may also include financial data, such as how many interactions with a particular endpoint occurred, which can be used for pay-per-use financial models. The reports may also include operational data, such as client and server performance metrics, such as uptime and response time. The reports may also include security information, such as information about failed requests (e.g., due to security reasons / unauthorized requests), unexpected interactions, or behavior changes, which can help detect security breaches.

[0058]

[66] It will be appreciated that various services, including discovery services, authorization services, routing of API access requests, and metering / reporting services, are enabled using configuration data 125.

[0059]

[67] Flowchart example

[0060]

[68] Figures 5-8 are example flowcharts of method operations that may enable various features and functions of the system as described above. The method operations presented below are non-limiting examples only. In some embodiments, for example, a method may be accomplished with one or more additional operations not described and / or without one or more operations that are described. Additionally, the order in which the method operations are illustrated (and described below) is not intended to be limiting.

[0061]

[69] Figure 5 illustrates a flow chart of a method 500 for controlling communication between applications, according to various embodiments. At operation 502, interaction pattern data is generated.

[0062]

[70] As an example, generating interaction pattern data may include defining a plurality of roles for an interaction pattern and configuring a role as a source or target of a transaction. In some embodiments, the transaction is performed using one or more APIs. If a role is configured as a source of a transaction, the role is a consumer of an API associated with the transaction. If a role is configured as a target of a transaction, the role is a provider of an API associated with the transaction. In some embodiments, when two roles are associated with a transaction, the two roles may communicate with each other. For example, if a first role is configured to communicate with a second role, the first role and the second role may need to be associated with the transaction. Examples of interaction patterns are described with at least reference to FIG. 2. In some embodiments, operation 502 is performed by a subsystem that is the same as or similar to configuration subsystem 112, application subsystem 118, or a combination thereof.

[0063]

[71] At operation 504, application suitability data is generated. As an example, generating the application suitability data includes configuring an application to perform a set of roles. In some embodiments, configuring an application to perform a role may enable the application to consume (e.g., call) one or more APIs provided by other applications or provide one or more APIs for consumption by other applications. For example, to enable a first application to call a specified API of a second application, an interaction pattern having a first role and a second role corresponding to a source and target, respectively, of a transaction performed using the specified API may be identified (e.g., from an interaction pattern database). The first application may then be configured to perform the first role and the second application may be configured to perform the second role. An example of application interaction generation is described with at least reference to FIG. 3. In some embodiments, operation 504 is performed by a subsystem that is the same as or similar to configuration subsystem 112, application subsystem 118, or a combination thereof.

[0064]

[72] In operation 506, application instance data is generated. As an example, generating the application instance data includes associating the application instance with location data of APIs provided by the application. As an example, the location data may include IP addresses, URLs, or other such network addresses of endpoints where the APIs of the application instance are hosted / located. In some embodiments, generating the application instance data may also include generating access authorization data that defines which application instances are authorized to access which application instances. In some embodiments, operation 506 is performed by a subsystem the same as or similar to configuration subsystem 112, application subsystem 118, or a combination thereof.

[0065]

[73] At operation 508, communication between applications is controlled based on configuration data including interaction pattern data, application suitability data, and application instance data. Examples of controlling communication between applications include discovering a list of APIs that an application can call, determining whether an application can call a specified API, or authorizing a server to accept API access requests from a client device, some of which are described below in connection with at least Figures 6-8. In some embodiments, operation 508 is performed by a subsystem that is the same as or similar to configuration subsystem 112, gateway subsystem 114, application subsystem 118, or a combination thereof.

[0066]

[74] Figure 6 illustrates a flowchart of a method 600 for controlling communication between a first application and a second application, according to various embodiments. At operation 602, a request to invoke a specified API of the second application is received from the first application. As an example, the request may be received by a specified endpoint (e.g., a server or other computer system in the application subsystem 118) that hosts the specified API. In some embodiments, the first application finds the specified endpoint that hosts the specified API based on a discovery document obtained from a discovery endpoint (which is described below with reference to at least Figure 7). In some embodiments, operation 602 is performed by a subsystem that is the same as or similar to the configuration subsystem 112, the gateway subsystem 114, the application subsystem 118, or a combination thereof.

[0067]

[75] In operation 604, configuration data associated with the first application and the second application is obtained. For example, interaction pattern data and application suitability data are obtained from database 130. As described above, the interaction pattern data may define interactions using roles, transactions, and APIs. A role may consume an API from another role or provide an API to another role. In some embodiments, operation 604 may be performed by an authorization endpoint (e.g., by a server or other computer system in configuration subsystem 112, as described below with reference to at least FIG. 8). Also, as described above, the application suitability data represents a set of roles performed by the application. In some embodiments, operation 602 is performed by a subsystem that is the same as or similar to configuration subsystem 112, gateway subsystem 114, application subsystem 118, or a combination thereof.

[0068]

[76] At operation 606, a determination is made based on the configuration data whether or not to permit the first application to invoke the specified API of the second application. In some embodiments, a configuration analysis (including parsing the configuration data 125 as described above) may be performed to determine whether or not to permit the first application to invoke the specified API of the second application. In some embodiments, at least a portion of operation 606 may be performed by an authorization endpoint. As an example, if the application suitability data indicates that the first application is configured to perform a first role and the second application is configured to perform a second role, and the interaction pattern data indicates that the first role is configured to consume a specified API associated with the second role, then it is determined whether or not to permit the first application to invoke the specified API. Thus, at operation 608, the first application is permitted to invoke the specified API. However, if the configuration data indicates that the first application does not perform the first role or the second application does not perform the second role, then it is determined that the first application is not permitted to invoke the specified API. Thus, in operation 610, the first application is prohibited from invoking the specified API. In some embodiments, the first application may also be notified as to why it is not permitted to invoke the specified API. In some embodiments, operations 608-610 are performed by a subsystem that is the same as or similar to configuration subsystem 112, gateway subsystem 114, application subsystem 118, or a combination thereof.

[0069]

[77] Figure 7 shows a flowchart of a method 700 for performing a discovery process, according to various embodiments. In some embodiments, method 700 is performed using a discovery API of a discovery endpoint (e.g., a server or other computer system in configuration subsystem 112). At operation 702, a request is received from a specified application for a list of APIs accessible by the specified application.

[0070]

[78] At operation 704, configuration data associated with the specified application is obtained. In one example, the configuration data may include interaction pattern data, application suitability data, and application instance data. The configuration data may be obtained from database 130.

[0071]

[79] At operation 706, a determination is made regarding a list of APIs accessible by the specified application. In some embodiments, a configuration analysis (including analyzing configuration data 125 as described above) may be performed to determine a list of APIs that the specified application can call. As an example, (a) a set of roles performed by the specified application is determined based on the application suitability data, (b) a subset of the roles configured as sources of one or more transactions and the APIs associated with those transactions is determined based on the interaction pattern data, and (c) location data associated with each API (e.g., the URL of the endpoint where the API is hosted) is determined from the application instance data.

[0072]

[80] At operation 708, a discovery document having a list of APIs and other information (eg, applications associated with the APIs, location data, or efficacy indicators) is returned to the specified application.

[0073]

[81] Figure 8 illustrates a flowchart of a method 800 for performing an authorization process, according to various embodiments. In some embodiments, method 800 is performed using an authorization API of an authorization endpoint (e.g., a server in configuration subsystem 112 or other computer system). In some embodiments, at method 800 operation 802, an authorization request is received from a designated endpoint for approving an access request from a first application. In some embodiments, the access request is for access to a designated API of a second application hosted by the designated endpoint.

[0074]

[82] At operation 804, configuration data associated with the first application is obtained. In one example, the configuration data may include interaction pattern data, application suitability data, and application instance data. The configuration data may be obtained from database 130.

[0075]

[83] At operation 806, a determination is made regarding a list of APIs accessible by the first application. In some embodiments, a configuration analysis (including analyzing configuration data 125 as described above) may be performed to determine a list of APIs the first application can call. As an example, (a) a set of roles performed by the first application is determined based on the application suitability data, (b) a subset of the roles configured as sources of one or more transactions and the APIs associated with those transactions is determined based on the interaction pattern data, and (c) a subset of those APIs hosted by a specified endpoint is determined from the application instance data.

[0076]

[84] At operation 808, a list of APIs on the designated endpoint accessible by the first application is sent to the designated endpoint. In some embodiments, upon receiving the list of APIs from the authorization endpoint, the designated endpoint may check whether the designated API requested by the first application is included in the list of APIs. If the designated API is in the list, the designated endpoint may allow the first application to access the designated API.

[0077]

[85] Figure 9 illustrates an example computer system 900 for implementing one or more of the above aspects, according to various embodiments. Computer system 900 may represent one or more components of provider client device 104. In some embodiments, one or more components represented by computer system 900 may be excluded by provider client device 104. Additionally, one or more additional components may be included by provider client device 104, by way of example only.

[0078]

[86] In some cases, multiple instances of computer system 900 may communicate over a network and execute the techniques in a distributed manner. In some cases, the multiple instances may include mobile computing devices (e.g., smartphones with cameras) that capture images of the subject on which the techniques of the present patent application operate. In some cases, the instances may include server-side instances (e.g., microservices architecture or monolithic architecture) that perform training and analysis with trained models. Various portions of the systems and methods described herein may include or be executed on one or more computer systems similar to computer system 900. Additionally, the processes and modules described herein may be executed by one or more processing systems similar to that of computer system 900.

[0079]

[87] Computer system 900 is configured to include one or more processors (e.g., processors 910-1 through 910-N) coupled to memory 920, input / output I / O device interface 930, and network interface 940 via input / output (I / O) interface 950. As described herein, a processor may include a single processor or multiple processors (e.g., distributed processors). A processor may be any suitable processor capable of executing or otherwise implementing instructions. A processor may include a central processing unit (CPU) for executing program instructions to perform arithmetic, logical, and input / output operations of computer system 900. A processor may execute code (e.g., processor firmware, protocol stack, database management system, operating system, or combinations thereof) that creates an execution environment for the program instructions. A processor may include a programmable processor. A processor may include a general-purpose or special-purpose microprocessor. A processor may receive computer program instructions and data from a memory (e.g., memory 920). Computer system 900 may be a uniprocessor system including one processor (e.g., processor 910a) or a multiprocessor system including any number of suitable processors (e.g., 910-1 through 910-N). Multiple processors may be used to provide parallel or sequential execution of one or more portions of the techniques described herein. Processes such as logic flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform functions by operating on input data to generate corresponding output. Processes described herein may be implemented by, and apparatus may be implemented as, special purpose logic circuitry, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC).Computer system 900 may include multiple computing devices (eg, a distributed computer system) for performing various processing functions.

[0080]

[88] I / O device interface 930 is configured to provide an interface for connecting one or more I / O devices, such as computer system 102, wearable device 104, and / or provider client device 104, to computer system 900. An I / O device may include a device that receives input information (e.g., from a patient or provider) or output information (e.g., to a user or provider). An I / O device (e.g., a provider client device) may include, for example, a graphical user interface displayed on a display (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), a pointing device (e.g., a computer mouse or trackball), a keyboard, a keypad, a touchpad, a scanning device, a voice recognition device, a gesture recognition device, a printer, an audio speaker, a microphone, or a camera, etc. An I / O device may be connected to computer system 900 via a wired or wireless connection. An I / O device may be connected to computer system 900 from a remote location. For example, an I / O device on a remote computer system may be connected to computer system 900 via a network and network interface 940.

[0081]

[89] The network interface 940 may include a network adapter that provides a connection of the computer system 900 to a network. The network interface 940 may facilitate data exchange between the computer system 900 and other devices connected to the network. The network interface 940 may support wired or wireless communications. The network may include an electronic communications network, such as the Internet, a local area network (LAN), a wide area network (WAN), or a cellular communications network.

[0082]

[90] The system memory 920 may be configured to store computer program instructions 922 and / or data 924. The computer program instructions 922 may be executable by a processor (e.g., one or more of processors 910-1 through 910-N) to perform one or more embodiments of the techniques of the present patent application. The computer program instructions 922 may include modules of computer program instructions for performing one or more techniques described herein with respect to various processing modules. The computer program instructions may include computer programs (known in certain forms as programs, software, software applications, scripts, or code). Computer programs may be written in programming languages, including compiled or interpreted languages, or declarative or procedural languages. Computer programs may include units suitable for use in a computing environment, such as as stand-alone programs, modules, components, or subroutines. A computer program may or may not correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple cooperating files (e.g., a file storing one or more modules, subprograms, or portions of code). A computer program may be deployed to be executed on one or more computer processors that are located locally at one location or distributed across multiple remote locations and interconnected by a communications network.

[0083]

[91] The memory 920 may include a tangible program carrier on which program instructions are stored. The tangible program carrier may include a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium may include a machine-readable storage device, a machine-readable storage substrate, a memory device, or any combination thereof. The non-transitory computer-readable storage medium may include non-volatile memory (e.g., flash memory, ROM, PROM, EPROM, EEPROM memory), volatile memory (e.g., random access memory (RAM), static random access memory (SRAM), synchronous dynamic RAM (SDRAM)), or bulk storage memory (e.g., CD-ROM and / or DVD-ROM, hard drive)), and the like. The memory 920 may include a non-transitory computer-readable storage medium on which program instructions may be stored that are executable by a computer processor (e.g., one or more of processors 910-1 to 910-N) to cause the subject matter and functional operations described herein. A memory (e.g., memory 920) may include a single memory device and / or multiple memory devices (e.g., distributed memory devices). Instructions or other program code for providing the functionality described herein may be stored on a tangible, non-transitory computer-readable medium. In some cases, an entire set of instructions is stored on the medium at the same time, and in some cases, different portions of the instructions may be stored on the same medium at different times.

[0084]

[92] The I / O interface 950 may be configured to coordinate I / O traffic between the processors 910-1-1510-N, the system memory 920, the network interface 940, the I / O devices (e.g., the wearable device 104, the provider client device 104), and / or other peripherals. The I / O interface 950 may perform protocol, timing, or other data conversions to convert data signals from one component (e.g., the memory 920) into a format suitable for use by another component (e.g., the processors 910-1-1510-N). The I / O interface 950 may include support for devices connected via various types of peripheral buses, such as different versions of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.

[0085]

[93] Embodiments of the techniques described herein may be implemented using a single instance of computer system 900, or multiple computer systems 900 configured to host different portions or instances of the embodiments. Multiple processors 900 may provide parallel or sequential implementation / execution of one or more portions of the techniques described herein.

[0086]

[94] Those skilled in the art will appreciate that computer system 900 is merely exemplary and is not intended to limit the scope of the techniques described herein. Computer system 900 may include any combination of devices or software that may implement or otherwise provide performance of the techniques described herein. For example, computer system 900 may include or be a combination of a cloud computing system, a data center, a server rack, a server, a virtual server, a desktop computer, a laptop computer, a tablet computer, a server device, a client device, a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, an in-vehicle computer, or a global positioning system (GPS), and the like. Computer system 900 may also be connected to other devices not shown, or may operate as a stand-alone system. Additionally, functionality provided by the illustrated components may be combined into fewer components or distributed among additional components in some embodiments. Similarly, in some embodiments, functionality of some of the illustrated components may not be provided, or other additional functionality may be available.

[0087]

[95] Those skilled in the art will also appreciate that while various items are illustrated as being stored in memory or storage during use, these items, or portions of items, may be transferred between memory and other storage devices for memory management and data integrity purposes. Alternatively, in other embodiments, some or all of the software components may execute in memory on another device and communicate with the illustrated computer system via computer-to-computer communications. Also, some or all of the system components or data structures may be stored (e.g., as instructions or structured data) on a computer-accessible medium or portable article that is read by an appropriate drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from computer system 900 may be transmitted to computer system 900 via a transmission medium or a signal, such as an electrical, electromagnetic, or digital signal conveyed over a communications medium, such as a network or wireless link. Various embodiments may further include receiving, transmitting, or storing instructions or data executed on a computer-accessible medium in accordance with the above description. Thus, the present technology may be practiced with other computer system configurations.

[0088]

[96] While the description provided above is based on what are presently considered to be the most practical and preferred embodiments and provides details for purposes of illustration, it should be understood that such details are for illustrative purposes only and that the disclosure is not limited to the embodiments shown. To the contrary, the disclosure is intended to cover modifications and equivalent arrangements that fall within the spirit and scope of the appended claims. For example, it should be understood that the present patent application contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

[0089]

[97] The present technology will be better understood with reference to the embodiments enumerated below.

[0090]

[98] 1. A method for controlling interactions between multiple applications based on interaction pattern data, application suitability data, and application instance data.

[0091]

[99] 2. The method of embodiment 1, wherein the interaction pattern data includes roles, transactions, APIs, options, or role dependencies, and the transactions are associated or tied to at least one pair of roles, and the transactions are implemented using the APIs.

[0092]

[0100] 3. The method of embodiments 1-2, wherein the application suitability data includes application data for a plurality of applications and roles performed by the applications, the roles being one of the roles defined in the interaction pattern data.

[0093]

[0101] 4. The method of any one of embodiments 1 to 3, wherein the application instance data includes API location data for an instance of the application, a role, and options that are enabled for that instance.

[0094]

[0102] 5. The method of embodiment 4, wherein the API location data includes a URL of an endpoint that hosts the API.

[0095]

[0103] 6. The method of embodiments 1 and 4, wherein the application instance data includes inter-application access permissions.

[0096]

[0104] 7. The method of embodiment 6, wherein the access permission defines a permission for a first application to access a second application or group of applications.

[0097]

[0105] 8. The method of any one of embodiments 6 to 7, wherein the access permission defines the permission for a group of applications to access a particular application.

[0098]

[0106] 9. The method of any one of embodiments 6 to 8, wherein the access permission defines a permission for the first application to access the enabled role on the second application.

[0099]

[0107] 10. The method of any one of embodiments 1 to 9, further providing a discovery API that enables an application to search for accessible APIs on other applications.

[0100]

[0108] 11. The method of any one of embodiments 1 to 10, wherein the accessibility of the API associated with the second application is determined based on application permissions, application suitability, and interaction patterns.

[0101]

[0109] 12. The method of embodiment 11, further comprising determining that the API is accessible based on: (a) an instance of a first application (the "first application instance") being able to communicate with an instance of a second application (the "second application instance"); (b) the first application performing a first role and the second application performing a second role; (c) the first role being enabled for the first application instance and the second role being enabled for the second application instance; (d) a transaction is defined between the first role and the second role, in which the first role is the source of the transaction and the second role is the target of the transaction; and (e) the transaction is defined to use the API.

[0102]

[0110] 13. The method of any one of embodiments 1-12, further comprising providing an authorization API to enable a second application to authorize access to the API by the first application.

[0103]

[0111] 14. The method of any one of claims 1 to 13, wherein granting access to the API is determined based on the operation of claim 12.

[0104]

[0112] 15. The method of any one of embodiments 1 to 14, further comprising providing a gateway to route data between applications.

[0105]

[0113] 16. The method of embodiment 15, wherein the gateway is configured based on the API location data.

[0106]

[0114] 17. The method of embodiment 16, wherein the gateway restricts routing of data to an API associated with the application, and the routing is determined based on application instance data, access permissions, application suitability data, and interaction pattern data.

[0107]

[0115] 18. The method of embodiment 17, wherein the gateway is configured to route data from the source application to the API if the application has access to the API according to the operation of embodiment 12.

[0108]

[0116] 19. The method of any one of embodiments 16 to 18, wherein the gateway is configured to perform authorization logic before forwarding the request from the source application to a target endpoint that hosts an API associated with the application.

[0109]

[0117] 20. The method of any one of embodiments 16 to 19, wherein the gateway is configured to log information regarding data routed between applications for consumption by the metering system.

[0110]

[0118] 21. The method of embodiment 20, wherein the logs are tagged with interaction pattern data, such as API, transaction, or role.

[0111]

[0119] 22. The method of embodiment 15, further comprising providing a plurality of gateways, the gateways forming a network topology, each gateway routing data from and to applications in the corresponding gateway's network zone, and the gateways communicating data with each other between the network zones.

[0112]

[0120] 23. The method of embodiment 22, wherein the network topology includes a mesh network or a star network.

[0113]

[0121] 24. The method of embodiments 10 and 15, wherein the discovery API inserts the gateway into the communication path between the application and a target application having an API to which the application has requested access by replacing the location data of the API with the location data of an instance of the gateway.

Claims

1. 1. A method for controlling communication between a plurality of applications using a computer system, the computer system including one or more hardware processors, the method comprising: generating interaction pattern data, the interaction pattern data defining, for each interaction of a plurality of interactions, a plurality of roles, each role being associated with a transaction performed with another role, the transaction being performed using an API (Application Programming Interface); generating application suitability data, the application suitability data defining, for each application of a plurality of applications, a set of roles performed by a corresponding application; generating application instance data, the application instance data including location data for a plurality of APIs associated with an instance of an application of the plurality of applications; and controlling communication between a first application of the plurality of applications and a second application of the plurality of applications based on the interaction pattern data, the application suitability data, and the application instance data.

2. The step of generating interaction pattern data includes:

2. The method of claim 1, comprising associating a first role of the plurality of roles and a second role of the plurality of roles with a specified transaction, thereby enabling the first role and the second role to communicate with each other.

3. 3. The method of claim 2, wherein the first role is a consumer of an API associated with the specified transaction based on the interaction pattern data indicating the first role is a source of the specified transaction.

4. 3. The method of claim 2, wherein the first role is a provider of an API associated with the specified transaction based on the interaction pattern data indicating the first role is a target of the specified transaction.

5. The step of generating application suitability data includes:

2. The method of claim 1, comprising configuring the first application to perform a first role and configuring the second application to perform a second role, thereby enabling the first application to invoke an API associated with the second application, wherein the interaction pattern data indicates that the first role invokes the second role to perform a transaction using the API associated with the second application.

6. The step of generating application instance data includes:

2. The method of claim 1, comprising configuring the location data by specifying, for the instance of the application, uniform resource locators (URLs) for accessing the plurality of APIs.

7. The step of controlling communication between the first application and the second application includes: receiving, at a server, from a client device executing an instance of the first application, a request for a list of APIs accessible by the first application, the list of APIs being associated with one or more of the plurality of applications; By the server, using a discovery API, (a) a set of roles to be performed by the first application based on the application suitability data; (b) a subset of roles from the set of roles that are configured as sources of one or more transactions based on the interaction pattern data; and (c) a list of the APIs associated with one or more transactions; determining and returning information to the client device that includes the list of APIs.

8. The method of claim 7 , wherein the information includes location data associated with each API in the list of APIs.

9. The method of claim 7 , wherein the information includes an application ID of an application with which each API in the list of APIs is associated.

10. The method of claim 7 , wherein the information includes a validity indicator indicating an expiration time for which data provided in the list of APIs is valid.

11. The method further comprises:

9. The method of claim 8, further comprising: invoking, by the first application, a specified API from the list of APIs using the location data, the specified API being associated with the second application.

12. The step of controlling communication between the first application and the second application includes: receiving, at a server running an instance of the second application, a request from a client device running an instance of the first application to invoke a specified API associated with the second application; determining, by the server, using an authorization API whether the first application is authorized to access the second application based on access permissions configured for instances of the plurality of applications; determining, by the server, a set of APIs associated with the second application that are accessible by the first application based on the interaction pattern data and the application suitability data in response to determining that the first application is authorized to access the second application; and permitting the first application to call the specified API based on a determination by the server that the specified API is one of the set of APIs.

13. The step of controlling communication between the first application and the second application includes: determining, using a discovery API, information regarding a set of APIs associated with the second application that are accessible by the first application, the information including addresses of the set of APIs within a computer network; and configuring a gateway subsystem to route requests from the first application to access a particular API of the second application to a specified address within the computer network.

14. The step of controlling communication between the first application and the second application further comprises:

2. The method of claim 1, comprising: using a metering subsystem to determine information regarding communications between the first application and the second application, the information including a type of interaction pattern, an amount of interaction with a specified application, or a performance metric associated with the plurality of applications.

15. A computer program product which, when executed by one or more processors, causes the processors to perform the method according to any one of claims 1 to 14.

16. 1. A system for controlling communications between a plurality of applications in a computer network, the system comprising: one or more processors, the one or more processors configured to: generating interaction pattern data, the interaction pattern data defining each interaction of a plurality of interactions using a plurality of roles, each role being associated with a transaction performed with another role, the transaction being performed using an API (Application Programming Interface); generating application suitability data, the application suitability data defining, for each application of a plurality of applications, a set of roles performed by a corresponding application; generating application instance data, the application instance data including location data for a plurality of APIs associated with an instance of an application of the plurality of applications; and controlling communication between a first application of the plurality of applications and a second application of the plurality of applications based on the interaction pattern data, the application suitability data, and the application instance data.

17. 17. The system of claim 16, further comprising: causing the one or more processors to generate the interaction pattern data by associating a first role of the plurality of roles and a second role of the plurality of roles with a specified transaction, thereby enabling the first role and the second role to communicate with each other.

18. 20. The system of claim 17, further causing the one or more processors to configure options of a specified API associated with the specified transaction, the options enabling or disabling access to a portion of the specified API.

19. The one or more processors:

17. The system of claim 16, wherein the application suitability data is generated by configuring the first application to perform a first role and configuring the second application to perform a second role, thereby enabling the first application to invoke an API associated with the second application, and the interaction pattern data indicates that the first role invokes the second role to perform a transaction using the API associated with the second application.

20. The one or more processors: determining a list of APIs accessible by the first application using a discovery API, said determining including: (a) a set of roles to be performed by the first application based on the application suitability data; (b) a subset of roles from the set of roles that are configured as sources of one or more transactions based on the interaction pattern data; and (c) a list of the APIs associated with one or more transactions; determining, and returning information to the first application including the list of APIs.

21. 21. The system of claim 20, wherein the one or more processors further call, from the first application, a specified API from the list of APIs using the location data, the specified API being associated with the second application.

22. 1. A method for controlling communication between a plurality of applications using a computer, the computer including one or more processors, the method comprising: receiving a request from a first application of a plurality of applications to invoke a specified API associated with a second application of the plurality of applications; obtaining the interaction pattern data and the application suitability data from a storage system; The interaction pattern data defines each interaction of a plurality of interactions using a plurality of roles, each role consuming an API from another role or providing an API to another role; The application compatibility data defines, for each application of a plurality of applications, a set of roles performed by the corresponding application; The method further includes determining, based on the application suitability data and the interaction pattern data, that the first application performs a first role and the second application performs a second role, where the interaction pattern data indicates that the first role consumes the specified API associated with the second role. and allowing the first application to call the specified API.

23. A computer program product which, when executed by one or more processors, causes the processors to perform the method of claim 22.

24. 1. A system for controlling communications between a plurality of applications in a computer network, the system comprising: one or more processors, the one or more processors configured to: obtaining configuration data from a configuration subsystem, the configuration data comprising: interaction pattern data, the interaction pattern data defining interactions using a plurality of roles, each role being either a consumer of an API (Application Programming Interface) or a provider of an API; application suitability data, which defines the set of roles performed by the application; and obtaining application instance data including network addresses of a plurality of APIs associated with an instance of the application; configuring a gateway subsystem based on the configuration data; and generating network route data for routing a request from a first application to a specified network address associated with a second application for accessing the specified API; and controlling communication between the first application and the second application through the gateway subsystem based on the configuration data.

25. The one or more processors are configured to:

25. The system of claim 24, further comprising: a metering subsystem configured to determine information regarding communication between the first application and the second application, the information including a type of interaction pattern, an amount of interaction with the first or second application, or a performance metric associated with the first or second application.

26. The one or more processors: determining information including a list of APIs accessible by the first application using a discovery API of the configuration subsystem, said determining including: (a) a set of roles to be performed by the first application based on the application suitability data; (b) a subset of roles from the set of roles that are configured as sources of one or more transactions based on the interaction pattern data; and (c) a list of the APIs associated with one or more transactions; determining, and returning the information including the list of APIs to the first application.

27. The one or more processors: receiving a request from a client device executing an instance of the first application to invoke a specified API associated with the second application; using an authorization API of the configuration subsystem to determine whether the first application is authorized to access the second application based on access permissions configured for an instance of the first application in the configuration subsystem; responsive to determining that the first application is authorized to access the second application, determining a set of APIs associated with the second application that are accessible by the first application based on the configuration data; 25. The system of claim 24, further comprising: based on a determination that the specified API is one of the set of APIs, allowing the first application to call the specified API via the gateway subsystem.

Images