Application integration using interaction patterns

Abstract

The present disclosure relates to controlling communication between various applications or integrating various applications using interaction patterns. Interaction pattern data defining a plurality of roles of an interaction pattern is generated. Each role is associated with a transaction and is either a source or a target of the transaction. The transaction is performed using an application programming interface (API). Based on whether the role is a source or a target of the transaction, the role can be a provider or a consumer of the API. Application consistency data is generated that defines a set of roles implemented by an application. An application is permitted to invoke an API of another application if the application implements a first role and the other application implements 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] This patent application discloses various systems and methods related to integrating applications using interactive modes. Background Technology

[0002] Software in a computer system provides machine-to-machine interfaces, often called Application Programming Interfaces (APIs). Applications can use these APIs to initiate processes or methods in another application. APIs are typically formalized in machine-resolvable formats, such as OpenAPI and Web Services Definition Language (WSDL). However, such specifications only provide the syntax (and some semantics) of messages entering and leaving services that implement the API. When multiple APIs are related in some way (e.g., a service might have to implement two APIs, or a service implementing one API might need to call some other APIs), these API specification methods cannot represent these relationships. Sometimes such multi-API interactions and corresponding behavioral requirements may be specified. However, these are not captured in machine-resolvable definitions and thus may not be used in application logic (e.g., scaffolding or automated multi-API test suites). Service registries typically expose which services can implement APIs on the server side. Unregistered clients are usually potential customers of such APIs. Without client registration, system dependencies cannot be queried, tracked, or controlled. Summary of the Invention

[0003] Therefore, one or more aspects of this disclosure relate to a method for controlling communication between multiple applications, the method being implemented by one or more processors executing one or more computer program instructions such that, when executed, the one or more processors implement a method for generating interaction mode data, which defines multiple roles for each of the multiple interactions. Each role is associated with a transaction executed using another role, wherein the transaction is executed using an application programming interface (API). The method also includes generating application consistency data, which defines a set of roles implemented by the corresponding application for each of the multiple applications. The method further includes generating application instance data, which includes location data of multiple 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 mode data, application consistency data, and application instance data (collectively, "configuration data").

[0004] Another aspect of this disclosure relates to a method for controlling communication between multiple applications, implemented by one or more processors executing one or more computer program instructions, such that, when executed, the one or more processors implement a method at a server to receive a request from a first application among the multiple applications to invoke a specified API associated with a second application among the multiple applications. The method includes obtaining interaction pattern data from a storage system, wherein the interaction pattern data defines each of the multiple interactions using multiple roles, wherein each role is configured to consume an API from another role or provide an API to another role. The method also includes obtaining application consistency data from a storage system, wherein the application consistency data defines a set of roles implemented by the corresponding application for each of the multiple applications. The method further includes the server determining, based on the application consistency data, that the first application is configured to implement a first role and the second application is configured to implement a second role, and that the interaction pattern data indicates that the first role is configured to consume a specified API associated with the second role. The method also includes the server authorizing the first application to invoke the specified API of the second application.

[0005] Another aspect of this disclosure relates to a system for controlling communication between multiple applications in a computer network. The system includes one or more processors configured by machine-readable instructions to: generate interaction pattern data that defines each of the multiple interactions using multiple roles. Each role is associated with a transaction executed using another role, wherein the transaction is executed using an API. The system is also configured to generate application consistency data that defines a set of roles implemented by the corresponding application for each of the multiple applications. The system is further configured to generate application instance data that includes location data of multiple APIs associated with instances of the applications. The system is also configured to control communication between a first application and a second application based on configuration data.

[0006] Another aspect of this disclosure relates to a system for controlling communication between multiple applications in a computer network. The system includes one or more processors configured by machine-readable instructions to: obtain configuration data from a configuration subsystem, the configuration data including interaction mode data, application consistency data, and application instance data. The interaction mode data may define interactions using multiple roles, where each role is either a consumer of an application programming interface (API) or a provider of an API. The application consistency data may define a set of roles implemented 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 also configure a gateway subsystem based on the configuration data to generate network routing data for routing requests from a first application for accessing a specified API associated with a second application to a specified network address associated with the specified API. The system is also configured to control communication between the first and second applications via the gateway subsystem based on the configuration data.

[0007] These and other objects, features, and characteristics of this disclosure, as well as the operation and function of the related elements of the structure and the economy of combination and manufacture of the components, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein similar reference numerals designate corresponding portions in the various figures. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to be construed as limiting the scope of this disclosure. Attached Figure Description

[0008] Figure 1A and 1B Systems for controlling (coordinating or facilitating) communication between applications in a computer network, according to various embodiments, are illustrated.

[0009] Figure 2 Representations of patient data exchange interaction modes according to various embodiments are shown;

[0010] Figure 3 Representations of applications configured to implement roles from various interaction modes are shown according to various embodiments;

[0011] Figure 4 The data structures for generating configuration data according to various embodiments are shown;

[0012] Figure 5 A flowchart is shown, illustrating a method for controlling communication between applications according to various embodiments;

[0013] Figure 6A flowchart is shown, illustrating a method for controlling communication between a first application and a second application according to various embodiments;

[0014] Figure 7 Flowcharts of methods for performing a discovery process according to various embodiments are shown;

[0015] Figure 8 Flowcharts of methods for performing an authorization process according to various embodiments are shown;

[0016] Figure 9 A computer system according to various embodiments for implementing one or more of the above aspects is shown. Detailed Implementation

[0017] As used herein, the singular forms of “a,” “an,” and “the” include plural references unless the context clearly specifies otherwise. As used herein, the term “or” means “and / or” unless the context clearly specifies otherwise. As used herein, the term “quantity” should mean one or more integers (i.e., a plurality).

[0018] In the claims, any reference numerals placed between parentheses should not be construed as limiting the claims. The words "comprising" or "including" do not exclude the presence of elements or steps other than those listed in the claims. In a device claim listing several modules, several of these modules may be embodied in the same hardware. The words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. In any device claim listing several modules, several of these modules may be embodied in the same hardware. Although specific elements are listed in different dependent claims, this does not indicate that these elements cannot be combined.

[0019] Figure 1A A system 100 for controlling (coordinating or facilitating) communication between applications in a computer network is illustrated according to various embodiments. In some embodiments, 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 may host multiple applications (e.g., healthcare-related applications), such as a first application 110a (e.g., a patient planning provider application) and a second application 110b (e.g., a patient urgency stratification application).

[0020] System 100 facilitates communication between applications 110 based on interaction patterns, which define operations to be performed by one or more applications to achieve a common goal. Configuration subsystem 112 can facilitate the generation of configuration data 125 that can be used to control communication between applications. Configuration data 125 includes interaction pattern data 126, which defines interaction patterns based on roles, transactions, application programming interfaces (APIs), and their interdependencies. For example, a role is associated with a transaction performed with another role using an associated API. A role can be a source of a transaction (e.g., a consumer of an API associated with a transaction) or a target of a transaction (e.g., a provider of an API associated with a transaction). Configuration data 125 includes application consistency data 127, which defines a set of roles implemented by an application. In some embodiments, roles implemented by an application can be used to determine which other applications and their associated APIs the application can access. Furthermore, configuration data 125 includes application instance data 128, which specifies location data (e.g., a Uniform Resource Locator (URL) of an endpoint of a server or other computer system that hosts the API) associated with an instance of the application. Typically, configuration data 125 can be used to determine the permitted interactions between applications (e.g., which API of an application can call which APIs of other applications based on defined roles).

[0021] Configuration subsystem 112 also provides a discovery API to locate applications and their associated APIs that are accessible to the applications. Applications can use the discovery API to obtain a list of applications and their associated APIs that are accessible to the applications. In some embodiments, the discovery API uses configuration data 125, such as roles implemented by the applications (e.g., roles implemented by the source application and the target application) and the APIs associated with those roles, to determine the applications and the list of their associated APIs that are accessible to the applications.

[0022] Configuration subsystem 112 also provides an authorization API that application subsystem 118 can use to make authorization decisions if a particular application should accept incoming requests from another application. Furthermore, the authorization API can also inform the requesting application which APIs of a particular application are accessible (based on configuration data 125, such as roles implemented by the application and the APIs associated with those roles). Through this approach, system 100 provides a form of role-based access control, although applied at the application level rather than the user level.

[0023] Gateway subsystem 114 facilitates the generation and configuration of network routing data for routing API access requests from a requesting application to a gateway containing the requested API. Gateway subsystem 114 can act as an intermediary between applications (e.g., receiving an API access request from a requesting application and routing it to the appropriate endpoint with the requested API). Gateway subsystem 114 uses configuration data 125, such as API location data, to generate network routing data. Gateway subsystem 114 can also add tags (e.g., interaction pattern name, source API, source application, target application, or target API) to network traffic passing through gateway subsystem 114 (e.g., application interactions, such as API access requests and responses), which can be used for metering or other analytical purposes.

[0024] Metering subsystem 116 facilitates the collection and aggregation of metering data, which can be used to generate any report with various analytical capabilities. Because interactions via gateway subsystem 114 are tagged / categorized based on labels, reports depicting different kinds of interaction pattern knowledge can be generated. Examples of reports include business reports, financial reports, operational reports, and security reports regarding ecosystem usage. These reports can include analytical capabilities such as the type of interaction patterns used by applications, the number of interactions between a pair of applications, or other such performance metrics associated with the applications.

[0025] The following references at least Figure 1B Additional details about System 100 are described.

[0026] Figure 1BDetailed views of a system 100 for controlling communication between applications in a computer network, according to various embodiments, are shown. 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 via network 150. For example, network 150 can be accessed by any component of system 100 using Transmission Control Protocol and Internet Protocol (“TCP / IP”), User Datagram Protocol (UDP) (e.g., any protocol used in each TCP / IP layer), Hypertext Transfer Protocol (“HTTP”), WebRTC, SIP, and Wireless Application Protocol (“WAP”). In one embodiment, network 150 facilitates communication between components of system 100 or other components using a web browser using HTTP. Various additional communication protocols used to facilitate communication between components of system 100 include, but are not limited to, Wi-Fi (e.g., 802.11 protocol), Bluetooth, radio frequency systems (e.g., 900MHz, 1.4GHz and 5.6GHz communication systems), cellular networks (e.g., GSM, AMPS, GPRS, CDMA, EV-DO, EDGE, 3GSM, DECT, IS136 / TDMA, iDen, LTE or any other suitable cellular network protocol), infrared, BitTorrent, FTP, RTP, RTSP, SSH and / or VoIP.

[0027] Database 130 includes one or more interaction mode databases 132, one or more application consistency databases 134, one or more application instance databases 136, and one or more reporting databases 138. In some embodiments, system 100 includes multiple instances of database 130. However, for simplicity, a single instance of each database 130 is described. For example, as described herein, "interaction mode database 134" refers to a single interaction mode database or multiple interaction mode databases. Each database included in database 130 can be a distributed database, a cloud-based storage database, etc.

[0028] Provider client device 104 interacts with computer system 102 (e.g., to access applications hosted by computer system 102). In some embodiments, provider client device 104 is associated with a provider located in a care facility. As described herein, care facilities include general hospitals, psychiatric hospitals or any other health facility, clinics or community-assisted living communities, or any other type of long-term (e.g., overnight) care facility. Furthermore, the provider can be a doctor, nurse, technician, emergency medical provider, social worker, or family member. Provider client device 104 can be a wearable device and / or one or more mobile computing devices. In some embodiments, provider client device 104 includes a computing device (e.g., a desktop or laptop computer, tablet, or smartphone) assigned to the provider that can execute applications (e.g., one of the applications hosted by computer system 102). In some embodiments, provider client device 104 can also be a computing device capable of executing cloud-hosted applications such as a care provider application (e.g., one of the applications hosted by computer system 102). For example, the care provider application may: receive notifications from computer system 102 indicating the effects of a prescription drug combination. Furthermore, the care provider application may interface directly with an electronic health record (EHR) application (e.g., as an add-on) to provide notification regarding prescription drugs while the care provider is reviewing a patient's EHR records. Alternatively, the care provider application may interface with a reporting database 138, which can be used by the EHR application to access drug data from the EHR application.

[0029] In some embodiments, computer system 102 includes a configuration subsystem 112, a gateway subsystem 114, a metering subsystem 116, and an application subsystem 118. Furthermore, 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, implement operations to be performed, including causing the functions of any subsystems 112-118 to be executed. Computer program instructions may refer to machine-readable instructions stored in memory 122 and automatically executed by processor 120 in response to a request to perform one or more specific functions or both. Memory 122 may include a tangible program carrier, such as a non-transitory computer-readable storage medium.

[0030] In some embodiments, 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 planning provider application) and a second application 110b (e.g., a patient urgency stratification application), as at least referenced Figure 1A As described. Application subsystem 118 can be implemented as one or more servers or other computer systems. Furthermore, application subsystem 118 can be implemented as a cloud-based platform that provides access to one or more applications to multiple tenants (e.g., nursing facilities). In some embodiments, application subsystem 118 can host separate instances of the applications for each tenant. For example, a first set of instances of the first and second applications can be hosted for a first nursing facility (e.g., represented by provider client device 104), and a second set of instances of the first and second applications can be hosted for a second nursing facility (e.g., represented by another provider client device similar to provider client device 104). However, for simplicity, a set of instances for a single nursing facility can be described in the disclosed embodiments. Additionally, some applications can be hosted by one or more servers or other computer systems within the nursing facility's computer network (e.g., in the same computer network as provider client device 104). Applications can provide one or more APIs that another application can use / access / invoke to communicate with the application (e.g., consume data from or provide data to the application).

[0031] In some embodiments, configuration subsystem 112 is configured to generate configuration data 125, which computer system 102 can use to control communication between applications. For example, when a first application 110a, which is being accessed by provider client device 104, requests access to a specified API of a second application 110b, computer system 102 can analyze configuration data 125 to determine whether to allow the first application 110a to access the specified API. Configuration data 125 describes interactions performed by applications based on interaction patterns, roles, transactions, APIs, and their dependencies, which computer system 102 can use to determine how to control communication between applications.

[0032] Configuration subsystem 112 can provide a graphical user interface (GUI) for defining / generating interaction pattern data 126. Users (e.g., application developers) can use the GUI to generate interaction patterns. In some embodiments, generating interaction patterns includes defining multiple roles and configuring them as sources or targets of transactions. In some embodiments, a transaction is a communication path between two roles. A transaction can use one or more APIs to perform operations. Furthermore, if a role is configured as a source of a transaction, that role is a consumer of the API associated with the transaction. If a role is configured as a target of a transaction, that role is a provider of the API associated with the transaction. In some embodiments, if two roles are associated with a transaction, they can communicate with each other. If a first role and a second role must be able to communicate, then both the first and second roles may have to be associated with a transaction. It will be appreciated that a transaction can determine which roles can invoke which other roles.

[0033] As an example, at least refer to Figure 2 A patient data exchange interaction pattern 200 is described. 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 patient data source, patient data receiver, patient data storage device, patient data consumer, patient data location index, or patient data identity consumer. Roles “patient data storage device” 202 and “patient data consumer” 204 ​​are connected to / associated with each other via transaction “data query” 206. Role “patient data consumer” 204 ​​is the source of transaction “data query” 206, and role “patient data storage device” 202 is the target of transaction “data query” 206, meaning that an application implementing role “patient data consumer” 204 ​​can invoke API 212 associated with transaction “data query” 206 of an application implementing role “patient data storage device” 202. Examples of such APIs include: “FHIR-read”, which refers to a read operation on the Fast Healthcare Interoperability Resource (FHIR) interface; or “DICOM-network-read”, which refers to all read operations on the Medical Digital Imaging and Communications (DICOM)-network interface.

[0034] In some embodiments, the interaction pattern may 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 the requirements of the role it depends on, including providing the required APIs. This dependency can be used to extract common functionality into separate roles. As an example, in patient data exchange interaction pattern 200, the role "Location Index" 208 depends on the role "Patient Data Consumer" 204. Roles "Location Index" 208 and "Patient Data Consumer" 204 are associated with transaction "Index-Query" 210, where role "Patient Data Consumer" 204 is the source of transaction 210. In some embodiments, role "Location Index" 208 allows role "Patient Data Consumer" 204 to find which data storage devices have data about a specific patient. By depending on role "Patient Data Consumer" 204, role "Location Index" 208 can also function like role "Patient Data Consumer" 204 and provide or consume the APIs provided or consumed by role "Patient Data Consumer" 204. The role "Location Index" 208 can query one or more data storage devices, such as the role "Patient Data Consumer" 204, and then build an index of the data storage device, which can then be queried / consumed by the role "Patient Data Consumer" 204.

[0035] Configuration subsystem 112 may store interaction pattern data 126 (which includes information about interaction patterns, roles, transactions, and APIs) in a registry or database, such as interaction pattern database 134. In some embodiments, once an interaction pattern is stored in interaction pattern database 134, it can be considered "registered," meaning that the interaction pattern (e.g., its roles and transactions) is available for implementation by an application. Users (e.g., application developers) can use the interaction patterns stored in interaction pattern database 134 to configure applications to implement one or more roles, effectively controlling integration or communication between applications.

[0036] In some embodiments, configuration subsystem 112 also provides a GUI for generating application consistency data 127. Application consistency data 127 describes a set of roles implemented by an application. In some embodiments, configuring an application to implement roles enables the application to consume (e.g., invoke) one or more APIs provided by other applications, or to provide one or more APIs for other applications to consume. As an example, to enable a first application to invoke a specified API of a second application, an interaction pattern database 132 can be searched to identify interaction patterns of a first role and a second role that are respectively the source and destination of a transaction executed using the specified API. The first application can then be configured to implement the first role and the second application can be configured to implement the second role.

[0037] As an example, Figure 3 A GUI 300 is shown displaying various applications and roles implemented by those applications. A configuration subsystem 112 makes all registered interaction patterns (i.e., interaction pattern data 126 from an interaction pattern database 132) useful to users (e.g., application developers) for configuring applications to implement one or more roles. Users can select one or more of these roles to define application interactions accordingly. Figure 3 The GUI 300 illustrates applications configured to implement roles from various interaction modes: a patient urgency stratifier 302, a patient planning provider 304, a questionnaire provider 306, and a care application 308. However, for simplicity, the following paragraphs describe the configuration of the applications regarding roles from the patient data exchange interaction mode 200.

[0038] The application patient urgency stratifier 302 is configured to implement the roles of "patient data storage device" 202 and "patient data consumer" 204 from the patient data exchange interaction mode 200; the application patient plan provider 304 is configured to implement the role of "patient data storage device" 202; the application questionnaire provider 306 is configured to implement the role of "patient data storage device" 202; and the nursing application 308 is configured to implement the role of "patient data location index" 208.

[0039] The aforementioned application consistency data 127 may mean the following in terms of application interaction: (a) the application patient urgency stratifier 302 may call the APIs of the application patient urgency stratifier 302, patient plan provider 304, and questionnaire provider 306 provided by the role "patient data storage device" 202 implemented through the application; and (b) the application patient urgency stratifier 302 may call the API of the nursing application 308 provided by the role "location index" 208 implemented through the nursing application 308; and (c) the nursing application 308 may call the APIs that the application patient urgency stratifier 302 may call, because the role "location index" 208 implemented by the nursing application 308 depends on the role "patient data consumer" 204 implemented by the application patient urgency stratifier 302.

[0040] Although not discussed in detail, the application's patient urgency stratifier 302 is also configured to implement roles from other interaction modes, such as the survey requester role from the survey interaction mode and the referrer role from the patient referral interaction mode. Similarly, the application's patient plan provider 304 is configured to implement roles from other interaction modes, such as the "plan provider" role from the patient referral interaction mode. Similarly, the application's questionnaire provider 306 is configured to implement roles from other interaction modes, such as the "survey provider" role from the survey interaction mode.

[0041] Note that GUI 300 also illustrates the relationships between roles using arrows that depict the transactions associated with the roles. For example, the "Patient Data Consumer" 204 in the application's Patient Urgency Hierarchizer 302 is connected to the role "Patient Data Storage Device" 202, implemented by the application's Patient Urgency Hierarchizer 302, Patient Plan Provider 304, and Questionnaire Provider 306. This indicates that the Patient Urgency Hierarchizer 302 can communicate with the Patient Plan Provider 304 and Questionnaire Provider 306 via an API associated with the transactions connecting these roles. However, when application interactions are defined as transactions and the association between roles is defined as part of the interaction pattern, the user may not necessarily need to associate these roles with transactions.

[0042] After defining application interactions, application consistency data 127 (which includes information about the application and the roles implemented by the application) is stored in application consistency database 134. Application consistency database 134 stores a list of applications configured to implement one or more roles. In some embodiments, application consistency database 134 acts as a "marketplace" where users (e.g., application developers) can search for compatible applications and their ability to integrate with other applications (e.g., based on the roles implemented by the application).

[0043] In some embodiments, configuration subsystem 112 uses one or more data structures to store configuration data 125. Figure 4A data structure for defining / generating / storing configuration data 125 is shown, including interaction mode data 126, application consistency data 127, and application instance data 128. As an example, interaction mode data 126 is stored in an interaction mode database 134 using a first data structure 450. In some embodiments, the data structure includes multiple attributes and relationships defining the data stored using that data structure. The first data structure 450 includes an interaction mode attribute 451, which can specify the name or identifier (ID) and version or other information associated with the interaction mode. A role attribute 452 specifies the name or ID of the role implemented by the interaction mode. Many such roles can be defined for an interaction mode. A transaction attribute 453 specifies the name or ID of a transaction. An API attribute 454 specifies the name and version of an API. In some embodiments, the API name is unique within the application. An option attribute 455 defines one or more characteristics of the API that can be enabled or disabled. As an example, one option could be "sensitive," which enables the API to retrieve content classified as sensitive data or personal data associated with a patient, which would not be retrieved if the option is not set to "sensitive." Furthermore, the options for specifying the API can be optional.

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

[0045] In some embodiments, application consistency data 127 is stored in application consistency database 134 using a second data structure 460. The second data structure 460 includes application attributes 461, which may specify a name or identifier (ID) or other information associated with the application. Role attributes 462 specify the name of a role implemented / supported by the application. Many such roles may be implemented by the application. Option attributes 463 define one or more characteristics of the application that can be enabled to interact with other applications. Furthermore, the option to specify an API may be optional.

[0046] 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 application instance attributes 471, which may specify the application instance's ID or other information. As previously described, in some embodiments, an application instance is a logical instance of an application and may refer to an individual client deployment of the application as well as a configuration tenant at a shared deployment of the application. For example, if an application is deployed for two care facilities, there may be two separate application instances. 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 the location data (e.g., IP address, URL, or other such network address of the endpoint) where the application instance's API is located. The option attribute 473 defines one or more characteristics of the application that can be enabled to interact with other applications. For example, the option attribute may be used to define whether a role implemented by the application is enabled or disabled for a specific instance of the application. Furthermore, specifying API options may be optional. In some embodiments, application instances associated with specific clients are also tagged with group IDs, and this typically allows the application instance to communicate with other application instances having the same group ID.

[0047] Access permission data 480 defines the access permissions of an application. For example, access permission data 480 defines a list of applications that can access a first application, regardless of or regardless of the roles implemented by the first application. In another example, access permission data 480 defines a set of applications that can be accessed by the first application. In yet another example, access permission data 480 defines whether the first application can access a specific role of a second application, regardless of or regardless of whether the first application and the second application implement 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.

[0048] In some embodiments, control communication may include discovering a list of APIs that an application can call, determining whether an application can call a specified API, or an authorization server accepting an incoming API access request from a client device. Configuration subsystem 112 performs configuration analysis to determine how to control communication between applications. For example, as part of the configuration analysis, configuration subsystem 112 may determine, based on the presence of an instance of first application 110a in application instance database 136, that first application 110a is registered in application consistency database 134 to provide some integration capabilities. Next, from application consistency database 134 and using second data structure 460, configuration subsystem 112 may determine that first application 110a is implementing a set of roles from interaction pattern database 132. Next, from interaction pattern database 134 and using first data structure 450, configuration subsystem 112 may determine a first subset of roles as transaction sources and identify APIs associated with these transactions as APIs that can be called by first application 110a. Similarly, configuration subsystem 112 can determine a second subset of roles that are the targets of transactions, and identify the APIs associated with these transactions as APIs to be implemented by the first application 110a for consumption by other applications.

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

[0050] In another example, performing configuration analysis to determine that an instance of the first application 110a can access a specified API associated with the second application 110b may include determining that (a) based on access permission data 480, an instance of the first application 110a is permitted to communicate with an instance of the second application 110b; (b) based on application consistency data 127, the first application 110a is implementing a first role and the second application 110b is implementing a second role; (c) based on application instance data 128, the first role is enabled for an instance of the first application 110a and the second role is enabled for an instance of the second application 110b; (d) based on interaction mode data 126, a transaction is defined between the first role and the second role, wherein 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 as using the API based on interaction mode data 126.

[0051] Configuration subsystem 112 can provide a discovery API, which can be used by applications to determine which APIs can be invoked by the applications. Multiple operations may be involved in the discovery process. As an example, in a first operation, a first application 110a, executed by provider client device 104, may request computer system 102 to provide a list of APIs accessible to the first application 110a. Computer system 102 may return a first response with location details of the endpoint hosting the discovery API (e.g., a server or other computer system). In some embodiments, the first response may include the following details:

[0052] {

[0053] …

[0054] authorization_endpoint: "https: / / iam.hsdp...."

[0055] token_endpoint: "https: / / iam.hsdp.ph.com / ..." ...

[0057] introspect_endpoint:"https: / / cce.ph.com / ... / introspect"

[0058] discovery_endpoint:https: / / cce.ph.com / …

[0059] }

[0060] The authorization endpoint is the endpoint through which the provider client device 104 can authenticate itself to the computer system 102 and obtain an access token from the token endpoint after successful authentication. The discovery endpoint specifies the location of the endpoint hosting the discovery API.

[0061] In the second operation of the discovery process, provider client device 104 may send a request to the discovery endpoint to invoke the discovery API. Provider client device 104 may also provide an access token in the request. The discovery endpoint processes the access token to confirm permission for provider client device 104 to invoke the discovery API and returns a second response to provider client device 104. The second response may include a list of APIs accessible (e.g., invoked) by the first application 110a and APIs to be implemented (e.g., provided) by the first application 110a. In some embodiments, the second response may include a discovery document containing the following information:

[0062]

[0063] In some embodiments, a portion of the second response indicates (a) that the first application 110a is configured to provide / publish / implement APIs for consumption by other applications, and (b) location data of endpoints accessible by these APIs.

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

[0065] In addition, the second response includes a validity indicator (e.g., “exp”), which indicates the expiration date or time of the details provided in the second response. After expiration, the provider client device 104 may have to call the discovery API again to obtain a new list of APIs, which may or may not have changed from the previously obtained list of APIs. In some embodiments, the provider client device 104 may cache the list of APIs in memory associated with the provider client device 104 and refer to the cached list instead of calling the discovery API, thereby saving computational or network resources. However, after the cached list of APIs expires, the provider client device 104 may have to call the discovery API to obtain a new list of APIs.

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

[0067] When a designated endpoint receives a request from provider client device 104 for access to a designated API, the designated endpoint performs checks to determine whether the first application 110a is authorized to access the 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, 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 executing at provider client device 104, the designated endpoint invokes the authorization API at the authorization endpoint using a pair of access tokens, one associated with the designated endpoint and the other received from provider client device 104 (e.g., as described above with at least reference to 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 to permit the instance of the first application 110a to invoke an instance of the second application 110b using access permission data 480. If access permission data 480 indicates that the first application 110a is not allowed to access the second application 110b, the authorization API returns a response to the specified endpoint instructing it to do so, and the specified endpoint may also notify the provider client device 104 that its access to the second application is restricted. However, if access permission data 480 indicates that the first application 110a is allowed 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 allowed to access. In some embodiments, the response from the authorization API may include the following information:

[0068] {

[0069] active:true

[0070] scope:['fhir-read','fhir-read-sensitive']

[0071] client_id:'1234-56-7980'

[0072] group_id:'id x'

[0073] exp:59874327

[0074] }

[0075] In some embodiments, the "Activity" attribute indicates whether the specified endpoint should allow API access requests. The "Scope" attribute indicates a list of APIs that the first application is allowed to access at the specified endpoint. The "Client_id" is a unique identifier for the requesting application (e.g., first application 110a). The "Group_id" attribute indicates the deployment group of the interaction. As described above, in some embodiments, instances are allowed to communicate with other instances within the same group ID. In some embodiments, the group ID indicates a tenant ID in a multi-tenant cloud platform, which may represent a deployment of a specific entity (e.g., a nursing facility). The cloud platform may support deployment of applications for multiple tenants, and each tenant may have a unique group ID, with instances of each tenant's application grouped under the corresponding group ID. The validity indicator "exp" indicates the time value at which the response is valid (and therefore, the response may be cached at the server endpoint to prevent subsequent calls to the authorized API).

[0076] After receiving an authorization response from the authorization endpoint, the designated endpoint can determine whether the specified API requested by the first application 110a is included in the list of APIs based on the authorization response, and if it is included, the first application 110a is permitted to access the specified API.

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

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

[0079] In some embodiments, in a multi-cloud platform setup, the network of gateways can be configured. For example, if one application is in one network zone (e.g., external cloud infrastructure, such as outside a nursing facility's computer network) and another application is in a second network zone (e.g., internal cloud infrastructure, such as within a nursing facility's computer network), the gateway can be placed at the edge of each network zone (e.g., one within the internal cloud infrastructure and the other outside). The gateway is then configured to route external traffic to internal services and vice versa, routing requests from internal services through other proxies to relevant services located elsewhere. In some embodiments, to enable this routing of requests across network zones, applications may have to be identified by the network zone ID in which they are located. Gateway subsystem 114 can then generate network routing data based on the network zone.

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

[0081] As an example, the metering subsystem 116 can analyze tagged access logs to generate reports with any and all sorts of analyses. Examples of reports include usage reports, such as those describing how many interactions of a certain type of interaction pattern occurred (e.g., patient data exchange). Reports can be further categorized based on various parameters, such as the requesting application and the requested application. Reports can also include financial data, such as how many interactions have occurred with a particular endpoint, which can be used in pay-per-use financial models. Reports can also include operational data, such as client and server performance indicators, including availability, response time, etc. Reports can also include security information, such as information about failed requests (e.g., requests for security reasons / unauthorized access), unexpected interactions, or changes in behavior, which is useful for detecting security vulnerabilities.

[0082] As can be seen, configuration data 125 is used to implement various services, including discovery services, authorization services, routing of API access requests, and metering / reporting services.

[0083] Example Flowchart

[0084] Figure 5-8 This is an example flowchart of the processing operations for implementing the various features and functions of the system as described in detail above. The processing operations for each method presented below are intended to be illustrative and not limiting. In some embodiments, for example, the method may be implemented using one or more additional operations not described and / or without one or more of the operations discussed. Furthermore, the order in which the processing operations of these methods are described (and are described below) is not intended to be limiting.

[0085] Figure 5 A flowchart of a method 500 for controlling communication between applications, according to various embodiments, is shown. In operation 502,

[0086] Generate interaction pattern data. As an example, generating interaction pattern data may include defining multiple roles that define interaction patterns and configuring roles as sources or targets of transactions. In some embodiments, one or more APIs are used to execute the transaction. If a role is configured as a source of a transaction, that role is a consumer of the API associated with the transaction. If a role is configured as a target of a transaction, that role is a provider of the API associated with the transaction. In some embodiments, if they are associated with a transaction, the two roles can communicate with each other. For example, if a first role is configured to communicate with a second role, both the first and second roles may have to be associated with the transaction. (At least refer to...) Figure 2 Examples of interaction modes are described. In some embodiments, operation 502 is performed by the same or similar subsystem as configuration subsystem 112, application subsystem 118, or a combination thereof.

[0087] In Operation 504, application consistency data is generated. As an example, generating application consistency data includes configuring an application to implement a set of roles. In some embodiments, configuring an application to implement roles enables the application to consume (e.g., invoke) one or more APIs provided by other applications, or to provide one or more APIs for other applications to consume. For example, to enable a first application to invoke a specified API of a second application, interaction patterns (e.g., from an interaction pattern database) are identified for a first role and a second role, respectively serving as the source and destination of a transaction executed using the specified API, and the first application can be configured to implement the first role and the second application can be configured to implement the second role. (At least refer to...) Figure 3 An example of generating application interactions is described. In some embodiments, operation 504 is performed by the same or similar subsystem as configuration subsystem 112, application subsystem 118, or a combination thereof.

[0088] In operation 506, application instance data is generated. As an example, generating application instance data includes associating application instances with location data of APIs provided by the application. As an example, location data may include the IP address, URL, or other such network address of the endpoint of the API that hosts / locates the application instance. In some embodiments, generating application instance data may also include generating access permission data that defines which application instances are permitted to access which other application instances. In some embodiments, operation 506 is performed by a subsystem that is the same as or similar to configuration subsystem 112, application subsystem 118, or a combination thereof.

[0089] In Operation 508, communication between applications is controlled based on configuration data, which includes interaction mode data, application consistency data, and application instance data. Examples of controlling communication between applications may include discovering a list of APIs that an application can call, determining whether an application can call a specific API, or an authorization server accepting incoming API access requests from client devices, some of which are described below at least relative to... Figure 6-8 The description is provided. In some embodiments, operation 508 is performed by a subsystem that is the same as or similar to the configuration subsystem 112, gateway subsystem 114, application subsystem 118, or a combination thereof.

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

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

[0092] In operation 606, a determination is made based on configuration data to whether a first application is permitted to call a specified API of a second application. In some embodiments, configuration analysis (which involves analyzing configuration data 125 as described above) may be performed to determine whether the first application is allowed to call 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 application consistency data indicates that the first application is configured to implement a first role and the second application is configured to implement a second role, and interaction mode data indicates that the first role is configured to consume a specified API associated with the second role, a determination is made to allow the first application to call the specified API. Therefore, in operation 608, the first application is permitted to call the specified API. However, if configuration data indicates that the first application is not implementing the first role or the second application is not implementing the second role, a determination is made to disallow the first application from calling the specified API. Therefore, in operation 610, the first application is restricted from calling the specified API. In some embodiments, the reason for disallowing the call to the specified API may also be communicated to the first application. In some embodiments, operations 608-610 are performed by the same or similar subsystems as configuration subsystem 112, gateway subsystem 114, application subsystem 118, or combinations thereof.

[0093] Figure 7 A flowchart of a method 700 for performing a discovery process according to various embodiments is shown. 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). In operation 702, a request for a list of APIs accessible to a specified application is received from a specified application.

[0094] In operation 704, configuration data associated with the specified application is retrieved. As an example, configuration data may include interaction mode data, application consistency data, and application instance data. The configuration data can be obtained from database 130.

[0095] In operation 706, a list of APIs accessible to a specified application is determined. In some embodiments, configuration analysis (which involves analyzing configuration data 125 as described above) may be performed to determine the list of APIs that the specified application is allowed to invoke. As an example, (a) a set of roles implemented by the specified application is determined based on application consistency data, (b) a subset of roles configured as sources of one or more transactions and the APIs associated with these transactions are determined based on interaction pattern data, and (c) location data associated with each of the APIs (e.g., the URL of the endpoint hosting the API) is determined from application instance data.

[0096] In Operation 708, a discovery document containing a list of APIs and other information (such as the application associated with the API, location data, or validity indicators) is returned to the specified application.

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

[0098] In operation 804, configuration data associated with the first application is obtained. As an example, the configuration data may include interaction mode data, application consistency data, and application instance data. The configuration data can be obtained from database 130.

[0099] In operation 806, a list of APIs accessible to the first application is determined. In some embodiments, configuration analysis (which involves analyzing configuration data 125 as described above) may be performed to determine the list of APIs that the first application is allowed to invoke. For example, (a) a set of roles implemented by the first application is determined based on application consistency data, (b) a subset of roles configured as sources of one or more transactions and APIs associated with those transactions is determined based on interaction pattern data, and (c) a subset of those APIs hosted by specified endpoints is determined based on application instance data.

[0100] In operation 808, a list of APIs on a specified endpoint accessible by the first application is sent to the specified endpoint. In some embodiments, upon receiving the list of APIs from the authorized endpoint, the specified endpoint may then check whether the specified API requested by the first application is in the list of APIs. If the specified API is in the list, the specified endpoint may grant the first application access to the specified API.

[0101] Figure 9 An example computer system 900 for implementing one or more of the foregoing aspects is illustrated according to various embodiments. The computer system 900 may depict one or more components of a provider client device 104. In some embodiments, the provider client device 104 may exclude one or more components described by the computer system 900. Furthermore, the provider client device 104 may include one or more additional components, and the foregoing is merely illustrative.

[0102] In some cases, multiple instances of computer system 900 may communicate via a network to implement the technology in a distributed manner. In some cases, instances may include mobile computing devices (such as smartphones with cameras) that capture images on which the technology of this patent application operates. In some cases, instances may include server-side instances that perform training and analysis with trained models (e.g., in a microservices architecture or monolithic architecture). Various parts of the systems and methods described herein may include or be executed on one or more computer systems similar to computer system 900. Furthermore, the processes and modules described herein may be executed by one or more processing systems similar to computer system 900.

[0103] Computer system 900 is configured to include one or more processors (e.g., processor 910-1-1510-N), which are 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, the processors may include a single processor or multiple processors (e.g., a distributed processor). The processor may be any suitable processor capable of executing or otherwise performing instructions. The processor may include a central processing unit (CPU) that executes program instructions to perform arithmetic, logical, and input / output operations of computer system 900. The processor may execute code (e.g., processor firmware, protocol stack, database management system, operating system, or a combination thereof) to create an execution environment for the program instructions. The processor may include a programmable processor. The processor may include a general-purpose or special-purpose microprocessor. The processor may receive computer program instructions and data from memory (e.g., memory 920). Computer system 900 may be a single-processor system including one processor (e.g., processor 910a) or a multiprocessor system including any number of suitable processors (e.g., 910-1-1510-N). Multiple processors can be employed to provide parallel or sequential execution of one or more portions of the techniques described herein. Processes such as logical flows described herein can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating corresponding outputs. The processes described herein can be executed by dedicated logic circuits, and the apparatus can also be implemented as dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). Computer system 900 may include multiple computing devices (e.g., a distributed computer system) to implement various processing functions.

[0104] 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. I / O devices may include devices that receive input (e.g., from a patient, provider) or output information (e.g., to a user, provider). I / O devices (e.g., provider client devices) may include, for example, graphical user interfaces presented on a display (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, etc. I / O devices can be connected to computer system 900 via wired or wireless connections. I / O devices can be connected to computer system 900 from remote locations. For example, I / O devices located on a remote computer system can be connected to computer system 900 via a network and network interface 940.

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

[0106] System memory 920 may be configured to store computer program instructions 922 and / or data 924. Computer program instructions 922 may be executed by a processor (e.g., one or more of processors 910-1-1510-N) to implement one or more further embodiments of the technologies described herein. Computer program instructions 922 may include modules of computer program instructions for implementing one or more technologies described herein with respect to various processing modules. Computer program instructions may include computer programs (which are referred to in some 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, including units as standalone programs, modules, components, or subroutines. Computer programs may correspond to files in a file system or may not correspond to files in a file system. Programs may be stored as part of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), a single file dedicated to the program in question, or multiple coordination files (e.g., a file storing one or more modules, subroutines, or portions of code). Computer programs can be deployed to execute on one or more computer processors located at a local site or distributed across multiple remote sites interconnected by a communication network.

[0107] 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. A 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. A 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)), mass storage memory (e.g., CD-ROM and / or DVD-ROM, hard disk drive), etc. Memory 920 may include a non-transitory computer-readable storage medium on which program instructions are stored, which can be executed by a computer processor (e.g., one or more of processors 910-1-1510-N) to cause the operation of the subjects and functions described herein. 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 providing the functions described herein may be stored on a tangible, non-transitory computer-readable medium. In some cases, the entire instruction set can be stored on the medium at the same time, or in other cases, different parts of the instruction can be stored on the same medium at different times.

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

[0109] Embodiments of the techniques described herein can 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 computer systems 900 can provide parallel or sequential processing / execution of one or more portions of the techniques described herein.

[0110] Those skilled in the art will recognize that computer system 900 is merely illustrative and not intended to limit the scope of the techniques described herein. Computer system 900 may include any combination of devices or software capable of performing or otherwise providing the execution of the techniques described herein. For example, computer system 900 may include cloud computing systems, data centers, server racks, servers, virtual servers, desktop computers, laptop computers, tablet computers, server equipment, client devices, mobile phones, personal digital assistants (PDAs), mobile audio or video players, game consoles, in-vehicle computers, or global positioning systems (GPS), or combinations thereof. Computer system 900 may also connect to other devices not illustrated, or may operate as a stand-alone system. Furthermore, the functionality provided by the illustrated components may be combined in fewer components or distributed across additional components in some embodiments. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided, or other additional functionality may be available.

[0111] Those skilled in the art will also recognize that, although various items are described as being stored in memory or in a storage device during use, these items, or portions thereof, can 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 be executed in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or portable item for retrieval by a suitable 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, or via a communication medium such as a network or wireless link. Various embodiments may also include receiving, transmitting, or storing instructions or data implemented according to the foregoing description on a computer-accessible medium. Therefore, this technology can be practiced with other computer system configurations.

[0112] While the description provided above is based on what is currently considered the most practical and preferred embodiment and offers details for illustrative purposes, it should be understood that such details are for that purpose only, and this disclosure is not limited to the explicitly disclosed embodiments, but rather is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that this patent application contemplates that, to the extent possible, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0113] The following examples will help to better understand this technology:

[0114] 1. A method for controlling the interaction between multiple applications based on interaction pattern data, application consistency data, and application instance data.

[0115] 2. The method according to embodiment 1, wherein the interaction mode data includes roles, transactions, APIs, options or role dependencies, wherein the transaction is associated with or connected to at least one pair of roles, and wherein the transaction is executed using an API.

[0116] 3. The method according to embodiments 1-2, wherein the application consistency data includes application data of multiple applications and roles implemented by the applications, wherein the role is one of the roles defined in the interaction mode data.

[0117] 4. The method according to Examples 1-3, wherein, for an instance of an application, the application instance data includes API location data, roles, and options enabled for that instance.

[0118] 5. The method according to embodiment 4, wherein the API location data includes the URL of the endpoint of the hosted API.

[0119] 6. The method according to embodiments 1 and 4, wherein the application instance data includes access permissions between applications.

[0120] 7. The method according to embodiment 6, wherein the access permission is defined as a permission for the first application to access the second application or a set of applications.

[0121] 8. The method according to embodiments 6-7, wherein the access permission defines a set of permissions for applications to access a specific application.

[0122] 9. The method according to embodiments 6-8, wherein the access permission defines permission for the first application to access enabled roles on the second application.

[0123] 10. The method according to embodiments 1-9 further includes: providing a discovery API to enable the application to retrieve accessible APIs on other applications.

[0124] 11. The method according to embodiments 1-10, wherein accessibility to the API associated with the second application is determined based on application license, application consistency, and interaction mode.

[0125] 12. The method according to embodiment 11 further comprises: determining that the API is accessible based on: (a) an instance of a first application (“first application instance”) being allowed to communicate with an instance of a second application (“second application instance”); (b) the first application is implementing a first role and the second application is implementing a second role; (c) enabling the first role for the first application instance and enabling the second role for the second application instance; (d) defining a transaction between the first role and the second role, wherein 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 as using the API.

[0126] 13. The method according to embodiments 1-12 further includes: providing an authorization API to enable the second application to verify the first application's access to the API.

[0127] 14. The method according to Examples 1-13, wherein the verification of access to the API is determined based on the operation described in Example 12.

[0128] 15. The method according to embodiments 1-14 further includes: providing a gateway for routing data between applications.

[0129] 16. The method according to embodiment 15, wherein the gateway is configured based on API location data.

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

[0131] 18. The method according to 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.

[0132] 19. The method according to embodiments 16-18, wherein the gateway is configured to perform authorization logic before forwarding a request from the source application to a target endpoint hosting an API associated with the application.

[0133] 20. The method according to embodiments 16-19, wherein the gateway is configured to record information about data routed between applications for consumption by the metering system.

[0134] 21. The method according to embodiment 20, wherein the log is tagged with interaction pattern data, such as API, transaction, or role.

[0135] 22. The method according to embodiment 15 further includes: providing a plurality of gateways, wherein the gateways form a network topology, wherein each gateway routes data from an application within its network area and routes data to an application within its network area, wherein the gateways transmit data to each other in the network areas.

[0136] 23. The method according to embodiment 22, wherein the network topology includes a mesh network or a star network.

[0137] 24. The method according to embodiments 10 and 15, wherein the location data of the API is replaced with the location data of the gateway instance to insert the gateway into the communication path between the application and the target application having the API that the application has requested access to.

Claims

1. A method for controlling communication between multiple applications and a computer system (102), the computer system including one or more hardware processors (120), the method comprising: Generate interaction pattern data (126), wherein the interaction pattern data defines multiple roles for each of multiple interactions, wherein each role is associated with a transaction performed using another role, wherein the transaction is performed using an application programming interface (API); Generate application consistency data (127), wherein the application consistency data defines a set of roles implemented by the corresponding application for each of the multiple applications; Generate application instance data (128), wherein the application instance data includes location data of multiple APIs associated with instances of applications in the plurality of applications; and The communication between the first application (110a) and the second application (110b) among the plurality of applications is controlled based on the interaction mode data, the application consistency data, and the application instance data.

2. The method of claim 1, wherein, Generating the interaction mode data includes: Associating a first role and a second role among the plurality of roles with a specified transaction, so that the first role and the second role can communicate with each other.

3. The method of claim 2, wherein, Based on the interaction pattern data indicating that the first role is the source of the specified transaction, the first role is a consumer of the API associated with the specified transaction; or Based on the interaction pattern data indicating that the first role is the target of the specified transaction, the first role is a provider of an API associated with the specified transaction.

4. The method according to claim 1, wherein, Generating the application consistency data includes: The first application is configured to implement a first role and the second application is configured to implement a second role, such that the first application can call an API associated with the second application, wherein the interaction mode data indicates that the first role is configured to call the second role to perform a transaction using the API associated with the second application.

5. The method according to claim 1, wherein, Generating the application instance data includes: The location data is configured for the instance of the application by specifying a Uniform Resource Locator (URL) for accessing the multiple APIs.

6. The method according to claim 1, wherein, Controlling the communication between the first application and the second application includes: The server receives a request for a list of APIs accessible by the first application from a client device executing an instance of the first application, wherein the list of APIs is associated with one or more of the plurality of applications. This is determined by the server using the discovery API: (a) A set of roles implemented by the first application based on the application consistency data. (b) A subset of roles from the said 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; and Information about the list of APIs is returned to the client device.

7. The method according to claim 6, wherein, The information includes one or more of the following: Location data associated with each API in the list of APIs; The application ID of the application associated with each API in the list of APIs; and / or A validity indicator that indicates a time period up to when the data provided in the API's list is valid.

8. The method according to claim 7, wherein, The information includes the location data associated with each API in the list of APIs, and the method further includes: The first application uses the location data to call a specified API from the list of APIs, wherein the specified API is associated with the second application.

9. The method according to claim 1, wherein, Controlling the communication between the first application and the second application includes: At the server executing an instance of the second application, a request to invoke a specified API associated with the second application is received from the client device executing an instance of the first application. The server determines whether the first application is permitted to access the second application based on access permissions configured for instances of the multiple applications using an authorization API. In response to determining that the first application is permitted to access the second application, the server determines a set of APIs associated with the second application that can be accessed by the first application, based on the interaction pattern data and the application consistency data. The server grants permission for the first application to call the specified API based on the determination that the specified API is one of the set of APIs.

10. The method according to claim 1, wherein, Controlling the communication between the first application and the second application includes: The discovery API is used to determine information about a set of APIs associated with the second application, which can be accessed by the first application. This information includes the addresses of the set of APIs on a computer network. Configure the gateway subsystem to route requests from the first application for access to a specific API of the second application to a designated address in the computer network.

11. The method according to claim 1, wherein, Controlling the communication between the first application and the second application further includes: A metering subsystem is used to determine information about communication between the first application and the second application, wherein the information includes the type of interaction pattern, the number of interactions with a specified application, or performance metrics associated with the plurality of applications.

12. A method for controlling communication between multiple applications and a computer (102), the computer including one or more processors (120), the method comprising: Receive a request from a first application (110a, 302) among multiple applications to invoke a specified API (212) associated with a second application (110b, 304) among the multiple applications; Interaction mode data (126) and application consistency data (127) are obtained from the storage system (130). The interaction pattern data uses multiple roles to define each interaction in a plurality of interactions, wherein each role is configured to either consume an API from another role or provide the API to another role. The application consistency data defines a set of roles implemented by the corresponding application for each of the multiple applications. Based on the application consistency data and the interaction pattern data, it is determined that the first application is configured to implement a first role (204) and the second application is configured to implement a second role (202), wherein the interaction pattern data indicates that the first role is configured to consume the specified API associated with the second role; and The first application is permitted to call the specified API.

13. A non-transient computer-readable medium (122) comprising computer program instructions that, when executed by one or more processors (120), implement the operation comprising the method according to any one of claims 1 to 12.

14. A system (100) for controlling communication between multiple applications (110) in a computer network (150), the system comprising: One or more processors (120) configured by machine-readable instructions as follows: Generate interaction pattern data (126), wherein the interaction pattern data uses multiple roles to define each interaction in a plurality of interactions, wherein each role is associated with a transaction executed using another role, wherein the transaction is executed using an application programming interface (API). Generate application consistency data (127), wherein the application consistency data defines a set of roles implemented by the corresponding application for each of the multiple applications. Generate application instance data (128), wherein the application instance data includes location data of multiple APIs associated with instances of applications in the plurality of applications, and The communication between the first application (110a) and the second application (110b) among the plurality of applications is controlled based on the interaction mode data, the application consistency data, and the application instance data.

15. The system according to claim 14, wherein, The interaction pattern data is generated by the one or more processors by associating a first role and a second role among the plurality of roles with a specified transaction so that the first role and the second role can communicate with each other.

16. The system according to claim 15, wherein, The processors also configure options for a specified API associated with the specified transaction, wherein the options enable or disable access to portions of the specified API.

17. A system (100) for controlling communication between multiple applications in a computer network (150), the system comprising: One or more processors (120) configured by machine-readable instructions as follows: Configuration data (125) is obtained from the configuration subsystem, the configuration data including: Interaction pattern data (126), wherein the interaction pattern data defines interactions using multiple roles, wherein each role is either a consumer of an application programming interface (API) or a provider of the API. Application consistency data (127), wherein the application consistency data defines a set of roles implemented by the application, and Application instance data (128), wherein the application instance data includes network addresses of multiple APIs associated with an instance of the application; Based on the configuration data, the gateway subsystem (114) is configured as follows: Generate network routing data for routing requests from a first application (110a) to a specified API associated with a second application (110b) to a specified network address associated with the specified API; and Based on the configuration data, the gateway subsystem controls the communication between the first application and the second application.

18. The system according to claim 17, wherein, The one or more processors are configured by machine-readable instructions to: The metering subsystem is configured to determine information about communication between the first application and the second application, wherein the information includes the type of interaction mode, the number of interactions with the first application or the second application, or performance metrics associated with the first application or the second application.

19. The system according to claim 17, wherein, The one or more processors control the communication between the first application and the second application through the following operations: The discovery API of the configuration subsystem is used to determine information about a list of APIs accessible to the first application, wherein the information includes: (a) A set of roles implemented by the first application based on the application consistency data. (b) A subset of roles from the said 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; and Information containing the list of the APIs is returned to the first application.

20. The system according to claim 17, wherein, The one or more processors control the communication between the first application and the second application through the following operations: Receive a request from the client device executing the instance of the first application to invoke a specified API associated with the second application. The authorization API of the configuration subsystem is used to determine whether the first application is permitted to access the second application based on the access permissions configured for the instance of the first application in the configuration subsystem. In response to determining that the first application is permitted to access the second application, a set of APIs associated with the second application that can be accessed by the first application is determined based on the configuration data, and Based on the determination that the specified API is one of the set of APIs, the gateway subsystem permits the first application to call the specified API.

Images