A bidirectional application programming interface that enables operational action functions in one-way transmission systems.

Abstract

Examples of this disclosure describe systems and methods for bidirectional application programming interfaces (APIs) that enable operational action functions in one-way transmission (OWT) systems. In several examples, a data request is received in a first computing environment of the OWT system, and the data request is associated with a first unidirectional data flow having a transaction identifier. A first policy set associated with the first computing environment is applied to the data request, and this data request is transmitted to a second computing environment of the OWT system. The second computing environment retrieves response data for the data request, and the response data is associated with a second unidirectional data flow having a transaction identifier. A second policy set associated with the second computing environment is applied to the response data, and this response data is transmitted to the first computing environment to fulfill the data request.

Description

Background Art

[0001] Background

[0001] A unidirectional transmission system facilitates unidirectional transmission of data across one or more data boundaries. Due to the unidirectionality of data transmission, a unidirectional transmission system typically provides only limited operational action functions across data boundaries, which means that the transmitting side of the unidirectional transmission system typically cannot track data requests transmitted to the receiving side of the unidirectional transmission system or receive information from the receiving side. Therefore, it can be extremely difficult to ensure the security and integrity of data transmitted or stored by such a system while collecting information regarding system performance and maintenance on the receiving side of the unidirectional transmission system.

[0002]

[0002] The aspects disclosed in the present application are devised with respect to these and other general considerations. Although relatively specific problems may be described, it should be understood that the examples should not be limited to solving the specific problems clarified in the "Background" section or other parts of the present disclosure.

Summary of the Invention

Means for Solving the Problems

[0003] Summary

[0003] Embodiments of the present disclosure describe systems and methods for a bidirectional application programming interface (API) that enables operational action functionality in a one-way transfer (OWT) system. In several examples, a data request from a requester is received in a first computing environment of the OWT system, where the data request is associated with a first unidirectional data flow having a transaction identifier. A first policy set associated with the first computing environment is applied to the data request, and the data request is transmitted to a second computing environment of the OWT system as part of the first unidirectional data flow. The second computing environment retrieves response data for its data request, where the response data is associated with a second unidirectional data flow having a transaction identifier. A second policy set associated with the second computing environment is applied to the response data, and the response data is transmitted to the first computing environment of the OWT system as part of the second unidirectional data flow. The response data is provided to the requester to fulfill the data request.

[0004]

[0004] This “Summary” section is provided to briefly introduce selected concepts, which are further described in the “Detailed Description” section. This “Summary” is not intended to identify any important or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Other aspects, features, and / or advantages of the embodiments are some described in the following description, some of which will become apparent from the description or from practicing this disclosure.

[0005] Brief explanation of the drawing

[0005] An embodiment will be described with reference to the following drawings. [Brief explanation of the drawing]

[0006] [Figure 1]

[0006] An exemplary system for implementing a bidirectional API that enables operational action functionality in the OWT system is shown. [Figure 2]

[0007] This document illustrates an exemplary process flow for fulfilling data requests using a bidirectional API that enables operational action functionality. [Figure 3]

[0008] This example demonstrates how to use a bidirectional API to send and receive data in an OWT system. [Figure 4]

[0009] This is a block diagram illustrating exemplary physical components of a computing device for carrying out aspects of this disclosure. [Figure 5]

[0010] This is a simplified block diagram of an exemplary distributed computing system for carrying out an aspect of the present disclosure. [Modes for carrying out the invention]

[0007] Detailed explanation

[0011] One-way transmission (OWT) systems facilitate the unidirectional transmission of data across one or more data boundaries of an OWT system. An OWT system refers to a computing system, where one or more endpoints are data diodes configured to ensure that data packets can only be transmitted unidirectionally through that computing system. Often, OWT systems are used to protect networks or endpoints from outbound data transmission, malicious inbound data transmission (e.g., viruses and malware), and cyber attacks. As an example, an OWT system facilitates data transmission between computing environments with the same or different security levels (e.g., high security or low security), where at least one of the computing environments is less reliable with respect to the other computing environments. For example, a first computing environment that is reliable with respect to devices in the first computing environment and / or devices in one or more other computing environments may receive data from a second computing environment that is considered less reliable by the first computing environment.

[0008]

[0012] In many cases, a highly trusted environment refers to a system or network where devices, applications, and users are trustworthy, and security measures are in place to establish and maintain that trust. In this type of environment, the devices and / or parties involved, such as devices, software, and users, are frequently authenticated, authorized, and / or adhere to established security policies and best practices. Highly trusted environments typically employ strict access restrictions, encryption, and monitoring to ensure that trust is maintained and minimize the risk of unauthorized access, data breaches, or other security incidents. Devices within a highly trusted environment may be authorized to access or be accessed by other devices based on security techniques implemented by the highly trusted environment (e.g., unique encryption keys, secrets, or other decryption techniques). For example, communications transmitted by a highly trusted environment may be considered trustworthy by other computing environments or devices based on the fact that the highly trusted environment (or its devices) are included in an allow list (e.g., a list of authorized devices and / or computing environments). Alternatively, communications transmitted by a highly trusted environment may be considered trustworthy based on the password or certificate provided with that communications. In some cases, devices in a highly trusted environment do not require authentication to access other devices or to be accessed by other devices. Highly trusted environments generally do not expose the security techniques implemented by the highly trusted environment to other computing environments that the highly trusted environment may consider untrustworthy or unreliable.

[0009]

[0013] In contrast, a low-trust or untrustworthy environment refers to a system or network where devices, applications, and / or users are implicitly untrusted or at high risk of unauthorized access or malicious activity. A low-trust or untrustworthy environment may have limited or no security measures, or may include or be connected to one or more external or uncontrolled devices. Alternatively or additionally, a low-trust or untrustworthy environment refers to an environment in which a device is not considered secure or trustworthy by other devices within and / or outside that low-trust or untrustworthy environment. Because security techniques implemented in a high-trust environment are not exposed in a low-trust or untrustworthy environment, a low-trust or untrustworthy environment may prevent a device in a high-trust environment from accessing or communicating with it without performing various authorization and / or authentication steps that it would not need to perform. For example, an OWT system may span or include multiple computing environments separated by one or more boundaries between computing environments with different levels of trust and / or security.

[0010]

[0014] The data diode in an OWT system ensures unidirectional data packet transmission through the implementation of hardware and / or software components. In one example, the data diode includes a transmit-only network interface card (NIC). The transmit-only NIC sends data to an endpoint, but cannot receive data from the endpoint because the receive pins on the transmit-only NIC's network controller chip are physically disconnected. The transmit-only NIC may also include firmware that keeps the transmit-only NIC's link state always "uplink" (e.g., enable and / or active). In another example, the data diode implements a standard (e.g., commodity) NIC and a Y-splitter cable. The Y-splitter separates data transmission, with the first cable of the Y-splitter connected to the receiver and the second cable of the Y-splitter directed back to the transmitter, thus establishing a Layer 1 link state. In yet another example, the data diode implements one or more field-programmable gate array (FPGA) devices to ensure unidirectional data flow.

[0011]

[0015] Due to the inherent unidirectional nature of data transmission in OWT systems, OWT systems do not provide operational action capabilities that cross the data boundaries of the OWT system. Operational action capabilities, as used herein, refer to the ability to transmit, interact with, or manipulate data in a manner that provides a synchronous experience to the user. For example, a source endpoint sends a synchronous transmission of a first data flow in response to a data request to a destination endpoint, and the destination endpoint sends a corresponding synchronous transmission of a second data flow in response to the data request to the source endpoint. In contrast, an OWT system sends a data request from a source endpoint in a first computing environment (e.g., a low-reliability environment) to a destination endpoint in a second computing environment (e.g., a high-reliability environment). The source endpoint cannot track the data request sent to the second computing environment because it has limited or no visibility into the second computing environment. If the data request is a concurrent request, the source endpoint cannot receive a response to the data request because the OWT system cannot ensure that the response data is sent from the second computing environment to the first computing environment. Therefore, the OWT system treats synchronous data requests as asynchronous data requests for which no response is provided. Because the source endpoint cannot retrieve response data from the destination endpoint, stored and transmitted data, performance, and information related to the maintenance of the OWT system cannot be securely collected unless a collector (or information gathering device) is physically present in the second computing environment. This creates significant obstacles for users outside the second environment (e.g., support teams and administrators) in maintaining the OWT system and managing the data transmitted and stored by the OWT system.

[0012]

[0016] This disclosure provides solutions to the aforementioned obstacles in securely collecting relevant information within an OWT system. Embodiments of this disclosure describe systems and methods for a bidirectional application programming interface (API) that enables secure operational action functions within an OWT system. In several examples, a synchronous data request from a requester is received by a first bidirectional mechanism in a first computing environment of the OWT system. This data request is associated with a first asynchronous unidirectional data flow having a data flow identifier that identifies the data request. In some examples, the transaction identifier is associated with a use case that describes the user's purpose or specific scenario regarding the data request. For example, a first use case may be associated with requesting a first set or type of data, and a second use case may be associated with requesting a second set or type of data. The first bidirectional mechanism facilitates the transmission of the first unidirectional data flow through a first communication environment.

[0013]

[0017] A first set of policies associated with a first computing environment is applied to data requests, thereby ensuring that relevant security policies associated with the transmission of data and data requests through the first computing environment are enforced. The first set of policies includes or represents operations that will be performed on the data during data transmission. Examples of policies within the first set of policies include antivirus scanning policies, password verification policies, data hashing policies, digital signature policies, as well as file type checking and routing policies, code verification policies, content sanitizing policies, schema verification policies, and video transcoding policies. In several examples, the first set of policies is applied to data requests using a first security abstraction engine implemented within the first computing environment. A security abstraction engine refers to a software component that enforces rules or policies regarding data access and functionality, device resources, and network resources. The security abstraction engine is deployable at cloud scale, independent of dedicated or export-controlled hardware, and abstracts customer-specific implementations of security management. The security abstraction engine provides a reliable initial codebase that can be configured to meet the needs of individual customers and uses software-defined networking that is inaccessible to customers or third parties in order to execute unidirectional data flows.

[0014]

[0018] After applying the first policy set, the data request is transmitted to a second computing environment of the OWT system as part of the first unidirectional data flow. The first and second computing environments are separated by at least one security boundary of the OWT system, for example, using boundary protection devices (e.g., gateways, routers, firewalls, guards, and encrypted tunnels). In some examples, a second policy set associated with the second computing environment is applied to the data request, thereby ensuring that the relevant security policies associated with the data and data request transmitted to the second computing environment are enforced. In such examples, the second policy set is applied to the data request using a second security abstraction engine implemented within the second computing environment.

[0015]

[0019] A data request is provided to a second bidirectional mechanism within a second computing environment, completing the first unidirectional data flow. The second bidirectional mechanism retrieves response data for the data request from one or more data sources accessible to the second computing environment as part of an asynchronous second unidirectional data flow. Alternatively, the second unidirectional data flow is initiated after the first unidirectional data flow is completed and the second bidirectional mechanism has retrieved the response data. In either case, the transaction identifier of the first unidirectional data flow is assigned to or associated with the second unidirectional data flow. In some examples, at least one of the data sources resides in a computing environment outside the second computing environment, such as a third computing environment within the OWT system or a computing environment outside the OWT system. In at least one example, a third policy set associated with the second computing environment is applied to the response data to ensure that relevant security policies associated with the transmission of data and data requests through the second computing environment are enforced. The third policy set is applied to the response data using a third security abstraction engine implemented within the second computing environment.

[0016]

[0020] Response data is transmitted to the first computing environment of the OWT system as part of a second unidirectional data flow. In some examples, a fourth policy set associated with the first computing environment is applied to the response data to ensure that the relevant security policies associated with the data and data requests transmitted to the first computing environment are enforced. In such examples, the fourth policy set is applied to the response data using a fourth security abstraction engine implemented within the first computing environment. The response data is provided to a first bidirectional mechanism within the first computing environment, completing the second unidirectional data flow. The first bidirectional mechanism then fulfills the data request by providing the response data to the requester based on the transaction identifier. For example, the first bidirectional mechanism matches the transaction identifier in the data request with the transaction identifier in the response data to identify that the response data is related to the data request. Thus, by utilizing the first and second bidirectional mechanisms within the OWT system, operational action functionality is enabled by effectively providing synchronous command functionality between data boundaries of the OWT system using two asynchronous unidirectional transactions related by a common transaction identifier. Because these operational action features are visible to data requesters, a seamless synchronized user experience is provided.

[0017]

[0021] The operational action function allows response data transmitted between various computing environments to be filtered or modified according to the different security policies and requirements of the requesting computing environment. Due to these different security policies and requirements, the response data may contain different attributes when provided to different devices or components in the requesting computing environment. For example, when a first instance implementing a first set of policies in a computing environment sends a data request, the result is response data containing a user (e.g., employee) record with a globally unique identifier (GUID). When a second instance implementing a second set of policies in the computing environment sends the same data request, the result is response data containing an employee record with a globally unique identifier (GUID) and an email address. When a third instance implementing a third set of policies in the computing environment sends the same data request, the result is response data containing an employee record with the employee's name.

[0018]

[0022] Figure 1 shows an exemplary system for implementing a bidirectional application programming interface (API) that enables operational action functions within an OWT system. System 100 is a combination of interdependent components that interact and integrate to form a whole, as shown in the figure. The components of System 100 may be hardware components or software components (e.g., APIs, modules, runtime libraries) that are implemented on and / or run by the hardware components of System 100. In one example, the components of System 100 are distributed across multiple processing units or computing systems.

[0019]

[0023] In Figure 1, System 100 represents an OWT system for transmitting data between different computing environments. System 100 includes computing environments 102 and 104 and a service environment 116. In several examples, computing environments 102 and 104 are implemented in a cloud computing environment or other type of distributed computing environment and are subject to one or more distributed computing models / services (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Functions as a Service (FaaS)). In some examples, the service environment 116 is implemented locally in one or more of the computing environments 102 and 104. For example, one or more computing devices within computing environments 102 and / or 104 each contain a separate instance of the service environment 116. In other examples, the service environment 116 is implemented separately from one or more of the computing environments 102 and 104. For example, the service environment 116 may be implemented in a cloud computing environment that is remotely accessible via a network such as a private area network (PAN), local area network (LAN), or wide area network (WAN) by the computing environments 102 and / or 104.

[0020]

[0024] Although FIG. 1 is shown to include a particular combination of a computing environment and a device, the scale and structure of the devices and computing environments described herein can vary and may include components additional to or fewer than those illustrated in FIG. 1. Further, the examples in FIG. 1 and subsequent figures are described with respect to data transmission between an OWT system and low-security and high-security computing environments, but these examples are equally applicable to data transmission between systems other than OWT and between computing environments of various (or the same) types and security levels. Further, these examples are equally applicable to data transmission between components of a single device. For example, a bi-directional API can be implemented on a single device having containers (e.g., software data structures for storing data and data objects) with different policies and access privileges to ensure that network traffic received by one of the containers (e.g., a high-security container) cannot be accessed by other of those containers (e.g., a low-security container).

[0021]

[0025] With respect to FIG. 1, computing environment 102 represents a low-security computing environment that is not trusted by computing environment 104 (e.g., devices operating within computing environment 102 are not trusted by devices operating within computing environment 104). In such an example, computing environment 102 can be physically separated from computing environment 104, whereby computing environment 102 is in a first physical location (e.g., a region, building, or room) and computing environment 104 is in a different second physical location. Alternatively, computing environment 102 and computing environment 104 can share the same physical location.

[0022]

[0026] The computing environment 102 includes computing devices 108. Examples of computing devices 108 include data diodes and server devices, such as web servers, file servers, application servers, and database servers. Computing devices 108 receive inputs such as data requests 110 from users or computing devices in or accessible to the computing environment 102. A data request 110 may include or request one or more types of data (e.g., audio data, touch data, text-based data, gesture data, and / or image data), computing instructions (e.g., commands or operations), and / or data items (e.g., documents or files). As one example, a data request 110 may request data stored by system 100 or data relating to one or more components or services of system 100 (e.g., health or performance data). As another example, a data request 110 may cause a report to be generated or a maintenance operation to be performed. Yet another example is that a data request 110 may include a document or file to be stored or processed. A data request 110 is associated with a transaction identifier that identifies the use case, transaction, or source identifier associated with the data request 110 (for example, a computing device 108, a component of computing device 108, or an identifier of the source endpoint that provided the data to computing device 108). The transaction identifier is included in (embedded in or attached to) the data request 110.

[0023]

[0027] In response to receiving the data request 110, the computing device 108 may access the service environment 116. In multiple examples, the service environment 116 provides access to various computing services and resources (e.g., applications, devices, storage, processing power, networking, analytics, intelligence). In FIG. 1, the service environment 116 includes a bidirectional API 120 and a security abstraction engine 122. One or more bidirectional APIs 120 and / or one or more security abstraction engines 122 may operate for each of the computing environments 102 and 104. For example, a first bidirectional API 120 and a first security abstraction engine 122 may be associated with data ingress operations by the computing environment 102 (e.g., data transmission from the computing environment 102 to the computing environment 104), and a second bidirectional API 120 and a second security abstraction engine 122 may be associated with data egress operations by the computing environment 104 (e.g., data transmission from the computing environment 104 to the computing environment 102).

[0024]

[0028] The bidirectional API 120 functions as a front-end layer for sending and retrieving data across multiple computing environments of system 100. The bidirectional API 120 abstracts the data transmission process so that the user sending a data request perceives the data request data flow and the corresponding response data flow as a single bidirectional transaction. Thus, the bidirectional API 120 effectively provides asynchronous command functionality across data boundaries of system 100. In some examples, the bidirectional API 120 provides, or is associated with, a user interface that allows users to generate and send data requests. For example, computing devices 108 and / or 112 may provide a graphical user interface (GUI) that allows the user to specify or select data to be retrieved from one or more data sources accessible to computing environments 102 and / or 104. In other examples, the bidirectional API 120 receives data requests sent to computing devices 108 and / or 112 via different components or devices in computing environments 102 and 104.

[0025]

[0029] The bidirectional API 120 maintains a record of transaction identifiers that identify data requests 110. For example, the bidirectional API 120 may store transaction identifiers in a data structure (e.g., a database or a memory table) that correlates the transaction identifiers with data requests 110, users, user devices, user accounts, and / or user sessions. In several examples, the bidirectional API 120 applies routing information to data requests 110 so that they can be sent across the boundaries of one or more computing environments. Routing information includes Internet Protocol (IP) addresses, Media Access Control (MAC) addresses, Uniform Resource Locators (URLs), and / or device ports. In some examples, the routing information is based on transaction identifiers. For example, transaction identifiers may be stored in a routing table that correlates transaction identifiers with specific destination addresses or data source identifiers. In such examples, the bidirectional API 120 uses the transaction identifier for data request 110 to identify the corresponding destination information in the routing table. The routing information is applied to data requests 110 based on the destination information. The bidirectional API 120 then provides the data request 110 to the security abstraction engine 122 as part of a first unidirectional data flow.

[0026]

[0030] The security abstraction engine 122 is a software engine that abstracts the security controls of hardware components that were previously dedicated solely to policy execution. In several examples, the security abstraction engine 122 applies a set of policies to a data request 110. Applying a first set of policies involves performing one or more operations associated with the first set of policies on the data request 110. Each operation may be a set of executable instructions performed by the security abstraction engine 122, or sequentially or in parallel with other operations. A set of policies may include policies that define the data content and type of data that may be provided to and / or received from computing environments 102 and 104. Such policies may include antivirus scanning, password detection, data hashing, digital signature creation / verification, file type checking and routing, code verification (e.g., verification of source code and compiled code), data sanitization, schema verification (e.g., file schema and data schema verification), and / or video and audio transcoding. In a specific example, a policy set might include a schema validation policy that describes and validates the structure and content of an XML document.

[0027]

[0031] Each of the security abstraction engines 122 may provide the same set of policies. Alternatively, one or more security abstraction engines 122 may apply fewer, more, or different policies than other security abstraction engines 122. For example, a security abstraction engine 122 associated with computing environment 102 may apply a first set or type of policy, and a security abstraction engine 122 associated with computing environment 104 may apply a second set or type of policy. The first set or type of policy may be more or less restrictive than the second set or type of policy. Additionally, a security abstraction engine 122 associated with a first unidirectional data flow (e.g., an ingress data flow) may apply a first set or type of policy, and a security abstraction engine 122 associated with a second unidirectional data flow (e.g., an egress data flow) may apply a second set or type of policy.

[0028]

[0032] In some examples, the security abstraction engine 122 evaluates policies applied to data requests 110 by other components of the system 100. For example, a service environment 116 may further include a policy engine (not shown) different from the security abstraction engine 122. The policy engine is a software engine that applies policies to data sent using the system 100. The policy engine may apply one or more policies from a set of policies to a data request 110, or apply different policies to a data request 110. In such examples, the security abstraction engine 122 evaluates the policies applied by the policy engine. For example, the security abstraction engine 122 may evaluate the digital signature created for each policy or operation applied to the data request 110 by the policy engine. Evaluating the digital signature involves comparing the digital signature (or the attributes of the digital signature) to the digital signature (or the expected attributes of the digital signature) expected for the policy applied by the policy engine to determine whether the digital signature is valid.

[0029]

[0033] The security abstraction engine 122 may include various policy execution components for implementing a policy set. Each of these policy execution components represents a different dedicated hardware device used for policy execution in a conventional policy execution system. In one example, the security abstraction engine 122 implements code processing functions, complex document processing functions, and video processing functions. The code processing function is assigned to process software artifacts, such as software libraries, executable files, software builds, etc. The code processing function verifies that the content contained in the data request 110 is of a specific type (e.g., a type of software artifact) and may perform other functions, such as compiling source code, verifying code, or generating a digital signature for a file. The complex document processing function is assigned to process complex documents, which refer to documents containing document objects other than text and / or images (e.g., charts, tables, macros, and other executable content), such as PDF documents, XML documents, presentation documents, spreadsheet documents, etc. The complex document processing function performs content standardization, such as removing content (e.g., macros and images) from data request 110 and reformatting the content of data request 110. The video processing function is assigned to process video data, such as video files or streams. The video processing function processes the video content (e.g., by changing the aspect ratio, frame rate, color, and other attributes of the video content) and transcodes the content contained in data request 110 using one or more data compression and decompression utilities, such as codecs.

[0030]

[0034] After applying the policy set to the data request 110, the security abstraction engine 122 sends the data request 110 to the computing environment 104 based on the transaction identifier. For example, routing information associated with the transaction identifier may be used to identify one or more devices or locations within the computing environment 104. For example, computing environment 104 represents a computing environment with higher security than computing environment 102. Computing environment 104 includes computing device 112. Examples of computing device 112 include the devices mentioned above with respect to computing device 108. In some examples, computing device 112 is located near computing device 108 (e.g., in the same building or room). For example, computing device 112 and computing device 108 may be located in the same room as the data center, with computing device 108 in a first data rack (e.g., a server rack or data cabinet) and computing device 112 in a second data rack or a different shell within the first data rack. In such examples, computing device 108 and computing device 112 may be directly connected via point-to-point cables. In another example, computing device 112 is installed separately from computing device 108 (for example, in a different building or room).

[0031]

[0035] In Figure 1, computing device 108 provides data request 110 to computing device 112. In another example, security abstraction engine 122 provides data request 110 to computing device 112 or a bidirectional API 120 associated with computing environment 104. In either case, the first unidirectional data flow for data request 110 may terminate when computing device 112 or the bidirectional API 120 associated with computing environment 104 receives the data request 110. Alternatively, the first unidirectional data flow for data request 110 may terminate after computing device 112 or the bidirectional API 120 has performed one or more processing steps related to data request 110. For example, a transaction identifier for data request 110 may be identified and recorded in a temporary memory table.

[0032]

[0036] In response to receiving a data request 110, the computing device 112 or the bidirectional API 120 accesses the datastore 114. In some examples, accessing the datastore 114 initiates, or is part of, a second unidirectional data flow that is separate from but related to, the first unidirectional data flow. The datastore 114 contains various documents, files, applications, services, and / or other data sources. Examples of datastores 114 include directly attached storage devices (e.g., hard drives, solid-state drives, and optical disc drives), network-based storage devices (e.g., storage area network (SAN) devices and network-attached storage (NAS) devices), and other types of memory devices. In Figure 1, the datastore 114 is depicted as being contained within the computing environment 104, but one or more datastores 114 may be located outside the computing environment 104.

[0033]

[0037] The data store 114 provides the computing device 112 or the bidirectional API 120 with response data 124 associated with the data request 110. For example, the response data 124 may contain one or more data items. Alternatively, the response data 124 may contain the completion status (e.g., success, failure, processing) or acknowledgment (e.g., request received) of one or more requested actions associated with the data request 110. The computing device 112 or the bidirectional API 120 associates the response data 124 with the transaction identifier of the data request 110. For example, the transaction identifier is embedded in or appended to the response data 124. The computing device 112 or the bidirectional API 120 then sends the response data 124 to the security abstraction engine 122 as part of a second unidirectional data flow, based on the transaction identifier. For example, the bidirectional API 120 may access a data structure (e.g., a database or memory table) that correlates the transaction identifier with routing information specifying a particular destination address or data source identifier. The bidirectional API 120 applies routing information to the response data 124 so that the response data 124 can be sent to a destination beyond the computing environment 104.

[0034]

[0038] The security abstraction engine 122 may apply the policy set described above to the response data 124 and send the response data 124 to a computing device 108 or a bidirectional API 120 associated with the computing environment 102. In the computing environment 102, the transaction identifier associated with the response data 124 is matched with the transaction identifier of the data request 110. For example, the transaction identifier associated with the response data 124 is identified and used to look up the routing table for the corresponding transaction identifier associated with the data request (e.g., data request 110). Once a matching transaction identifier is identified in the routing table, the response data 124 is provided in response to the data request 110. For example, the response data 124 is provided to the requester of the data request 110 to fulfill the data request 110 and terminate the second unidirectional data flow.

[0035]

[0039] Figure 2 shows an exemplary process flow for fulfilling a data request using a bidirectional API that enables operational action functionality. In several examples, process flow 200 is executed using an OWT system that includes two or more computing environments, e.g., computing environments 202 and 204, each separated by one or more data boundaries of that OWT system. Computing environments 202 and 204 are similar in type and implementation to computing environments 102 and 104 in Figure 1, respectively. For example, computing environment 202 may represent a publicly accessible commercial computing environment, and computing environment 204 may represent a sovereign computing environment that stores data for an entity (e.g., a user, and an organization, or a country), thereby ensuring that the data conforms to local laws or the policies of that entity, and is accessible only to that entity (or specific members authorized by that entity).

[0036]

[0040] In process flow 200, the user interface (UI) 210 of the computing environment 202 receives data requests associated with the computing environment 204. The UI 210 is provided by computing devices within or outside the computing environment 204, such as computing device 108. For example, the UI 210 allows a user to generate and send data requests to retrieve data from computing environments 202 and 204 and / or perform tasks within them. The UI 210 also provides data presentation and manipulation functions (e.g., graphing, reporting, data generation or modification) and may also provide access to one or more data stores. For example, the UI 210 may access a data store containing performance data (e.g., CPU metrics, memory metrics, disk storage metrics, input / output (I / O) operation metrics) about one or more devices, services, or applications accessible to the computing environment 202.

[0037]

[0041] In several examples, UI 210 performs one or more processing steps on a data request. For example, UI 210 associates a data request with a transaction identifier, source identifier, and / or destination identifier that indicate a data transmission use case (e.g., retrieving or sending data from a specific computing environment or a specific type of computing environment, scheduling a task or event, or performing a task for a specific entity). The transaction identifier may be automatically applied to a data request when it is created or received. UI 210 also applies one or more annotations and / or metadata (e.g., source and destination identification and routing information, expected response data type, status information associated with the data request, or the current user's session). For example, UI 210 applies a message wrapper to a data request that includes message header information and routing information for components within computing environments 202 and / or 204.

[0038]

[0042] UI 210 sends a data request to bidirectional API 212, which is functionally similar to bidirectional API 120 in Figure 1. Upon receiving the data request, bidirectional API 212 initiates a first unidirectional data flow for that data request. As part of the first unidirectional data flow, bidirectional API 212 maintains information that correlates the data request with a transaction identifier for that data request. For example, bidirectional API 212 may store a record that correlates the transaction identifier with connection information (e.g., a combination of connection and port) for the device providing UI 210. In some examples, the connection to UI 210 (and / or the corresponding user session) remains open while the data request is being sent to the destination, facilitating a synchronous data transmission experience. In other examples, the connection to UI 210 (and / or the corresponding user session) closes after the data request has been provided to bidirectional API 212, facilitating an asynchronous data transmission experience.

[0039]

[0043] The bidirectional API 212 may assign higher-level routing information to data requests based on transaction identifiers. For example, the bidirectional API 212 may include a data request (or a message wrapper for a data request) within a message wrapper that contains routing information for the destination or components of computing environment 202 or 204. The routing information applied by the bidirectional API 212 may be similar to, or identical to, the routing information applied by the UI 210, thereby leveraging the routing information applied by the UI 210. The bidirectional API 212 sends data requests to security abstraction engines 214, which are functionally similar to security abstraction engine 122 in Figure 1, and security abstraction engines 220, 228, and 234.

[0040]

[0044] The security abstraction engine 214 applies a first policy set to data requests. The first policy set defines the request content (e.g., data content, document type, data request type, and / or task request type) that may be sent from computing environment 202 to computing environment 204. For example, the first policy set may include policies for antivirus scanning, password detection, data hashing, digital signature creation / verification, file type checking and routing, code verification (e.g., verification of source code and compiled code), data sanitization, schema verification (e.g., file schema and data schema verification), and / or video and audio transcoding. By applying the first policy set, the content within a data request may be removed, added, or modified as a result. Alternatively, the data request may be terminated or split into one or more subrequests.

[0041]

[0045] In some examples, the policy engine 216 provides one or more policies from a first set of policies to the security abstraction engine 214. Functionally, the policy engine 216 is similar to policy engines 216, 230, and 236, and is a compliance analyzer and rule engine that provides a user interface for building static rules and policies as well as machine learning (ML) based rules and policies. The policy engine 216 may provide policies to the security abstraction engine 214 according to time intervals (e.g., hourly, daily, or one-off) or based on specified events (e.g., detection of a new data request or restart of a component in the computing environment 202). The security abstraction engine 214 then adds one or more policies provided by the policy engine 216 to a first set of policies stored in or accessible to the security abstraction engine 214. In other examples, the policy engine 216 applies one or more policies from the first set of policies to a data request. For example, the bidirectional API 212 may provide the data request to the policy engine 216 before providing the data request to the security abstraction engine 214. Alternatively, the security abstraction engine 214 may provide the data request to the policy engine 216. In either case, the policy engine 216 applies the policy to the data request and provides the data request to the security abstraction engine 214 for further transmission.

[0042]

[0046] In several examples, the security abstraction engine 214 and / or the policy engine 216 identify a primary policy set that will apply to a data request based on the transaction identifier. For example, a data structure (e.g., a data table, data array, or data mapping) stores the correlation between each transaction identifier, policy set, and / or source identifier. Each transaction identifier in the data structure may be associated with a different use case and a different policy set. The security abstraction engine 214 and / or the policy engine 216 use the transaction identifier in the data request to identify matching transaction identifiers in the data structure. The primary policy set is then identified based on the correlation between the transaction identifier in the data structure and the primary policy set in the data structure.

[0043]

[0047] After applying the first policy set to the data request, the security abstraction engine 214 sends the data request to the computing system 218. The computing system 218 includes one or more computing devices, for example, computing devices 108 and 112 in Figure 1. The computing system 218 sends the data request from the computing environment 202 to the security abstraction engine 220 in the computing environment 204. In some examples, the security abstraction engine 220 applies a second policy set to the data request. The second policy set defines the request content that can be received from the computing environment 202 and / or sent to the bidirectional API 224. The second policy set may include one or more policies or types of policies from the first policy set. The policy engine 222 may provide the security abstraction engine 220 with one or more policies from the second policy set and / or apply the policies to the data request, as previously described with respect to the security abstraction engine 214 and the policy engine 216. In at least one example, the security abstraction engine 220 does not apply the second policy set to the data request.

[0044]

[0048] The security abstraction engine 220 sends the data request to the bidirectional API 224, which is functionally similar to the bidirectional API 212. The bidirectional API 224 unwraps the data request (e.g., removes one or more message wrappers from the data request) and identifies the destination associated with the data request. For example, the data request may point to a data store, application, or service within or accessible by the computing environment 204. The bidirectional API 224 sends the data request to the UI 226, which is functionally similar to the UI 210. The UI 226 accesses the destination identified by the data request to retrieve the requested data or perform (or cause to be performed) the requested action. Once the response data (e.g., the completion status of the requested data or the requested action) is retrieved, the UI 226 performs one or more processing steps on this response data. For example, the UI 226 associates the response data with the transaction identifier associated with the data request. Associating response data with a transaction identifier involves retrieving a data request and applying (e.g., appending or embedding) the transaction identifier to the response data. In some examples, UI 226 applies one or more annotations and / or metadata to the response data and applies a message wrapper to the response data that includes message header information and routing information for components in computing environments 202 and / or 204. In at least one example, the routing information for the response data is selected based on the transaction identifier. For example, UI 226 and / or the bidirectional API 224 may have access to a data structure that stores transaction identifiers and corresponding routing information (e.g., connection and port combinations) for the device providing UI 210.

[0045]

[0049] UI 226 provides response data to the bidirectional API 224. In some examples, the first unidirectional data flow terminates when the bidirectional API 224 receives response data from UI 226. In other examples, the first unidirectional data flow terminates when the bidirectional API 224 receives a data request from the security abstraction engine 220. In either case, the bidirectional API 224 initiates a second unidirectional data flow to provide response data to the requester in fulfilling the data request.

[0046]

[0050] Upon receiving response data, the bidirectional API 224 can utilize the routing information applied by UI 226 by assigning higher-level routing information to the response data based on the transaction identifier as described above. The bidirectional API 224 sends the response data to the security abstraction engine 228. The security abstraction engine 228 applies a third policy set to the response data. The third policy set defines the response content (e.g., data content, document type, and / or response type) that may be sent from computing environment 204 to computing environment 202. For example, the third policy set may include policies that define authorized recipients and authorized data transmission dates / times, in addition to, or instead of, the policies included in the first and / or second policy sets. By applying the third policy set, the content in the response data may be removed, added, or modified. Alternatively, the response data may be deleted or split into one or more sub-responses. The policy engine 230 may provide the security abstraction engine 228 with one or more policies from a third set of policies, and / or apply the policies to the response data, as described above with respect to the security abstraction engine 214 and the policy engine 216.

[0047]

[0051] After applying the third policy set to the response data, the security abstraction engine 228 sends the response data to the computing system 232. The computing system 232 is functionally similar to the computing system 218. The computing system 232 sends data requests from the computing environment 204 to the security abstraction engine 234 in the computing environment 202. In some examples, the security abstraction engine 234 applies a fourth policy set to the response data. The fourth policy set defines the response content that can be received from the computing environment 204 and / or sent to the bidirectional API 212. The fourth policy set may include one or more policies or types of policies from the third policy set. The policy engine 236 may provide the security abstraction engine 234 with one or more policies from the fourth policy set, as previously described with respect to the security abstraction engine 214 and the policy engine 216. In at least one example, the security abstraction engine 234 does not apply the fourth policy set to the response data.

[0048]

[0052] The security abstraction engine 234 sends the response data to the bidirectional API 212. The bidirectional API 212 unwraps the response data request (e.g., removes one or more message wrappers from the response data request) to identify the destination associated with the response data. The response data indicates the user, computing device, or storage location to which the response is being delivered. For example, the response data may indicate connection information about the device providing the UI 210. In some examples, the bidirectional API 212 sends the response data to the UI 210 using an open connection, thereby performing the data request synchronously. For example, the bidirectional API 212 may send the response data to the UI 210 using a connection (and / or user session) that remains open after being used to send a data request from the UI 210 to the bidirectional API 212. In such an example, the bidirectional API 212 may identify the open connection based on a transaction identifier. For example, a transaction identifier in the response data may be matched with a transaction identifier associated with an open connection to identify that the open connection was used to send the response data to the UI 210. In another example, the bidirectional API 212 sends response data to the UI 210, allowing the data request to be fulfilled asynchronously. For example, the bidirectional API 212 opens a new connection with the UI 210 based on routing information regarding the response data, and uses this new connection to send the response data to the UI 210.

[0049]

[0053] UI 210 receives response data from the bidirectional API 212 and provides the response data to the requester of the data request. In some examples, the second unidirectional data flow terminates when UI 210 provides the response data to the requester. In other examples, the second unidirectional data flow terminates when UI 210 receives the response data from the bidirectional API 212. In either case, the use of the first unidirectional data flow and a separate second unidirectional data flow (unlike using a single bidirectional data flow) enables cross-data boundary operational action capabilities in the OWT system.

[0050]

[0054] Having described the systems that may be used by the embodiments disclosed herein, we now provide methods that may be performed by such systems. Method 300 will be described with respect to System 100 in Figure 1 and Process Flow 200 in Figure 2, but the execution of Method 300 is not limited to such examples.

[0051]

[0055] Figure 3 illustrates a method 300 for using a bidirectional API to send and receive data in an OWT system. In several examples, the bidirectional API is implemented in an OWT system that includes multiple computing environments. One or more of the computing environments may differ in terms of security level or physical location. For example, one of the computing environments may be a low-security environment, while others may be a high-security environment. The OWT system may be configured such that the source endpoint and / or destination endpoint of the data transmitted through its OWT are unknown to one or more of the computing environments.

[0052]

[0056] Method 300 begins with operation 302, where a data request, e.g., data request 110, is received by a first bidirectional API, e.g., bidirectional API 120. Receiving the data request at the first bidirectional API initiates a first unidirectional data flow. The first bidirectional API is implemented or provided by a first device, e.g., computing device 108, within a first computing environment in the OWT system, e.g., computing environment 102. In several examples, a data request includes one or more types of data (e.g., audio data, touch data, text-based data, gesture data, and / or image data), computing instructions (e.g., commands or operations), and / or data items (e.g., documents or files). A data request may indicate data to be retrieved or one or more actions to be performed (e.g., scheduling a task, generating a notification, executing a file or a set of commands). A data request is associated with a transaction identifier contained within (e.g., embedded in or appended to) the data request. In some examples, upon receiving a data request, the first bidirectional API applies the transaction identifier to the data request. In other examples, the transaction identifier is applied to the data request before it is received by the first bidirectional API. For example, interfaces used to generate data requests, such as UI 210 and 226, may assign a transaction identifier to the data request as part of generating the data request.

[0053]

[0057] In at least one example, the first bidirectional API maintains records of transaction identifiers by storing them in a first data structure that correlates the transaction identifiers with data requests. The first data structure may also correlate transaction identifiers with use cases, connection information (e.g., IP address and port information for open or closed connections with the first bidirectional API), or source identifiers relating to users (e.g., username or user account number), user devices (e.g., device name or MAC address), or user objects (e.g., containers or storage locations associated with that user). In such an example, the first bidirectional API applies routing information associated with the transaction identifiers to data requests so that data requests can be sent across data boundaries of the OWT system. A transaction identifier may be associated with a use case that specifies the routing information necessary to perform that use case. For example, a use case might specify a source address for the data requester, a destination address for a data store or service that can access the requested data, and / or addresses for one or more intermediate destinations (e.g., addresses for a security abstraction engine, policy engine, computing system, or bidirectional API). In several examples, applying routing information to a data request involves applying a message wrapper to the data request and including the routing information in the message wrapper.

[0054]

[0058] In operation 304, the first policy set is applied to the data request. In several examples, the first bidirectional API provides the data request to the first security abstraction engine, e.g., security abstraction engine 122. The first security abstraction engine identifies the first policy set to apply to the data request based on the transaction identifier. For example, the first security abstraction engine may look for a second data structure that correlates the transaction identifier with the first policy set and / or with a policy engine that provides policies associated with the transaction identifier. The first policy set includes policies that define the data content, file types, and task request types that may be sent from the first computing environment. For example, the first policy set may include policies for antivirus scanning, password detection, data hashing, digital signature generation / verification, file type checking and routing, code verification, data sanitization, schema verification, and / or video and audio transcoding. The first security abstraction engine applies an identified first set of policies to a data request by performing one or more actions associated with the first set of policies for that data request. Each action may be a set of executable instructions that are executed sequentially or concurrently with other actions. In one example, a digital signature is generated for each policy or action to prove that the execution of the policy or action was successful.

[0055]

[0059] In operation 306, the data request is sent to a second computing environment of the OWT system, for example, computing environment 104. In several examples, the first security abstraction engine provides its data request to a first computing system, for example, computing system 218. The first computing system sends the data request to the second computing environment based on routing information. For example, a computing device in the first computing system identifies the transaction identifier or routing information in the message wrapper of the data request. The computing device then sends the data request to a computing device or component in the second computing environment based on the transaction identifier or routing information.

[0056]

[0060] In some examples, the first computing system sends a data request to a second security abstraction engine. The second security abstraction engine identifies a second policy set to apply to the data request based on the transaction identifier, as described above. The second policy set includes policies that define the data content, file types, and task request types that may be received from or sent by the first computing environment. For example, the second policy set may include policies from the first policy set. The second security abstraction engine applies the second policy set to the data request and sends this data request to the second bidirectional API. In other examples, the first computing system sends the data request directly to the second bidirectional API.

[0057]

[0061] In operation 308, the data request is fulfilled. In several examples, the second bidirectional API processes the data request and identifies a destination from which to retrieve the data associated with the data request or to access it to perform a task. Processing the data request involves unwrapping the data request (e.g., removing one or more message wrappers from the data request) and identifying the destination of the data request. The destination may be a storage location, e.g., datastore 114, a service or application, or an interface, e.g., UI 226. In at least one example, one or more destinations associated with the data request are outside the second computing environment. The second bidirectional API accesses the destination and performs one or more operations associated with the data request. As an example, the second bidirectional API performs a search query in a database for a term or document indicated by the data request. As another example, the second bidirectional API causes a service or application to store the data provided in the data request. As yet another example, the second bidirectional API causes a source code file provided in or indicated in the data request to be compiled and / or deployed to a secure environment.

[0058]

[0062] In response to performing an action associated with a data request, the second bidirectional API receives response data associated with the data request from the destination. In several examples, the response data includes one or more data items, references to data items, completion status, and / or other data and metadata about the data request (e.g., data request metrics, data item metadata, changes to the data request). For example, in addition to including a set of documents, the response data may include metadata about the set of documents (e.g., document creation date, document size, document author), a display of one or more documents excluded from the response data, and an explanation for the exclusion of documents (e.g., the requester is not authorized to access that document, the destination or the second computing environment does not allow the document to be sent across the boundary of the second computing environment, the data request was modified during transfer to the second bidirectional API). When the second bidirectional API receives the response data, the first unidirectional data flow ends.

[0059]

[0063] In operation 310, the second bidirectional API processes the response data. In several examples, the second bidirectional API initiates a second unidirectional data flow to provide the response data to the requester by performing one or more processing steps on the response data. For example, the second bidirectional API associates a transaction identifier for the data request with the response data. For example, the transaction identifier may be appended to or embedded within the response data. The second bidirectional API ensures that the response data is transmitted across the data boundaries of the OWT system by applying routing information associated with the transaction identifier to the response data. For example, the second bidirectional API may access a third data structure containing a correlation between the transaction identifier and routing information regarding the destination associated with that transaction identifier. In several examples, applying routing information to the response data includes applying a message wrapper to the response data and including the routing information and / or transaction identifier within the message wrapper.

[0060]

[0064] In operation 312, a third policy set is applied to the response data. In several examples, the second bidirectional API provides the response data to a third security abstraction engine. The third security abstraction engine identifies the third policy set to apply to the response data based on the transaction identifier, as described above. The third policy set includes policies that define the types of data content and files that may be sent from the second computing environment to a particular user or computing environment. For example, the third policy set may define that restricted data (e.g., user medical data) is not permitted to be sent outside the second computing environment, sensitive data (e.g., user demographic data) is permitted to be sent to the first computing environment but not to the third computing environment, and public data (e.g., user usage data) is permitted to be sent to both the first and third computing environments. The third policy set may include policies from the first and / or second policy sets.

[0061]

[0065] In operation 314, the response data is sent to the first computing environment of the OWT system. In several examples, the second security abstraction engine provides the response data to a second computing system, for example, computing system 232. The second computing system sends the response data to the first computing environment based on routing information. For example, a computing device in the second computing system identifies a transaction identifier or routing information in the message wrapper of the response data. The computing device then sends the response data to a computing device or component in the first computing environment based on the transaction identifier or routing information.

[0062]

[0066] In some examples, the second computing system sends response data to a fourth security abstraction engine. The fourth security abstraction engine identifies a fourth policy set to apply to the response data based on the transaction identifier, as described above. The fourth policy set includes policies that define the data content, file types, and task request types that may be received from the second computing environment or sent by the first computing environment. For example, the fourth policy set may include policies from the first, second, and / or third policy sets. The fourth security abstraction engine applies the fourth policy set to the response data and sends the response data to the first bidirectional API. In other examples, the second computing system sends the response data directly to the first bidirectional API.

[0063]

[0067] In operation 316, response data is provided to the source component in fulfilling the data request. In several examples, the first bidirectional API processes the response data to identify the destination associated with the response data. Processing the response data involves unwrapping the response data (e.g., removing one or more message wrappers from the response data) to identify the transaction identifier. The transaction identifier is used to identify the connection information or source identifier associated with the data request. For example, the first bidirectional API uses the transaction identifier to look up matching transaction identifier entities in the first data structure. Matching transaction identifier entities include a combination of connections and ports relating to the source component (e.g., a computing device, service / application, or interface) used to generate and / or send the data request to the first bidirectional API. In one example, the first bidirectional API provides the response data to the source component using a connection that remained open while the data request was being sent to the second computing environment. In this example, providing the response data to the source component using an open connection facilitates a synchronous data transmission experience. In other examples, the first bidirectional API opens a new connection with the source component using connection information. For example, the first bidirectional API might use the IP address listed in the connection information for the source component. However, the first bidirectional API could also open a new connection with the source component using a different boat associated with the source component. In this example, providing the response data to the source component using the new connection facilitates the asynchronous data transmission experience. Once the response data is provided to the source component, the second unidirectional data flow ends.

[0064]

[0068] Figures 4-5 and their related descriptions provide a discussion of various operating environments in which the embodiments of this disclosure may be implemented. However, the devices and systems shown and discussed in relation to Figures 4-5 are for illustrative and explanatory purposes only, and naturally, a number of computing device configurations may be used to implement the embodiments of this disclosure described herein.

[0065]

[0069] Figure 4 is a block diagram showing the physical components (e.g., hardware) of a computing device 400 in which embodiments of the present disclosure may be implemented. The computing device components described below may be suitable for the aforementioned computing devices and systems. In a basic configuration, the computing device 400 includes at least one processing system 402 and a system memory 404. Depending on the configuration and type of the computing device, the system memory 404 may include volatile storage (e.g., random access memory (RAM)), non-volatile storage (e.g., read-only memory (ROM)), flash memory, or any combination of these memories.

[0066]

[0070] The system memory 404 includes an operating system 405 and one or more program modules 406 suitable for running software applications 420, for example, one or more components supported by the system described herein. The operating system 405 may, for example, be suitable for controlling the operation of a computing device 400.

[0067]

[0071] Furthermore, embodiments of this disclosure may be implemented in connection with a graphics library, another operating system, or any other application program, and are not limited to any particular application or system. This basic configuration is shown in Figure 4 by the component within the dashed line 408. The computing device 400 may have other features or functions. For example, the computing device 400 may also include other data storage devices (removable and / or non-removable), such as magnetic disks or optical disks. Such additional storage is shown in Figure 4 by the removable storage device 407 and the non-removable storage device 410.

[0068]

[0072] As described above, numerous program modules and data files may be stored in system memory 404. When executed on a processing system 402 including one or more processors, program module 406 (e.g., application 420) may execute processes including those described herein. Other program modules that may be used in accordance with the embodiments of this disclosure may include email and contact applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided application programs, and the like.

[0069]

[0073] Furthermore, embodiments of the present disclosure may be implemented in electronic circuits including discrete electronic elements, packages or integrated electronic chips including logic gates, circuits utilizing microprocessors, or on a single chip including electronic elements or a microprocessor. For example, embodiments of the present disclosure may be implemented via a system-on-a-chip (SOC), in which case each or many of the components shown in Figure 4 may be integrated into a single integrated circuit. Such an SOC device may include one or more processing systems / units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned into") a chip substrate as a single integrated circuit. When operating via an SOC, the functions described herein relating to the ability of a client to switch protocols may be performed via application logic integrated on a single integrated circuit (chip) together with other components of the computing device 400. Embodiments of the present disclosure may also be implemented using other techniques capable of performing logical operations such as AND, OR, and NOT, including mechanical, optical, fluidic, and quantum techniques. In addition, embodiments of the present disclosure may be implemented in a general-purpose computer or in any other circuit or system.

[0070]

[0074] The computing device 400 may also include one or more input devices 412, such as a keyboard, mouse, pen, voice input device, touch or swipe input device, etc. It may also include output devices 414, such as a display, speaker, printer, etc. The devices described above are examples, and other devices may be used. The computing device 400 may include one or more communication connections 416, which enable communication with other computing devices 450. Examples of suitable communication connections 416 include radio frequency (RF) transmitters, receivers, and / or transceiver circuit configurations, Universal Serial Bus (USB), parallel and / or serial ports.

[0071]

[0075] As used herein, the term "computer-readable medium" may include computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, or program modules. System memory 404, removable storage device 407, and non-removable storage device 410 are all examples of computer storage media (e.g., memory storage). Computer storage media include RAM, ROM, electrically erasable ROM (EEPROM), flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other products that can be used to store information and that the computing device 400 can access. Any of these computer storage media may be part of the computing device 400. Computer storage media do not include carrier waves or other propagating or modulated data signals.

[0072]

[0076] Communication media include any information transmission medium, which may be implemented by computer-readable instructions, data structures, program modules, or modulated data signals, such as other data in a carrier wave or other transmission mechanism. The term “modulated data signal” may describe a signal having one or more features that are set or modified in a manner that encodes information in the signal. For example, communication media may include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0073]

[0077] Figure 5 shows one aspect of the architecture of a system for processing data received by a computing system from a remote source, such as a personal computer 504, a tablet computing device 506, or a mobile computing device 508, as described above. The content displayed on the server device 502 may be stored in different communication channels or other types of storage. For example, various documents may be stored using a directory service 522, a web portal 524, a mailbox service 526, an instant messaging store 528, or a social networking site 530.

[0074]

[0078] The input evaluation service 520 may be used by a client communicating with the server device 502, and / or the input evaluation service 520 may be used by the server device 502. The server device 502 may provide data to client computing devices, such as a personal computer 504, a tablet computing device 506, and / or a mobile computing device 508 (e.g., a smartphone), and from there through the network 515. For example, the computing system described above may be embedded in a personal computer 504, a tablet computing device 506, and / or a mobile computing device 508 (e.g., a smartphone). Any of these embodiments of the computing device may retrieve content from the data store 516, in addition to receiving graphical data that can be used for pre-processing in a graphics sending system or post-processing in a receiving computing system.

[0075]

[0079] As can be seen from this disclosure, an example of the technology described herein relates to a system including a processing system and memory connected to the processing system, wherein the memory, when executed, includes computer executable instructions that perform operations including receiving a data request at a first bidirectional application programming interface (API) in a first computing environment of a one-way transmission (OWT) system, the data request being associated with a transaction identifier; applying a first policy set to the data request using a first security abstraction engine; transmitting the data request to a second computing environment of the OWT system; receiving response data associated with the data request from the second computing environment; and providing response data in response to the data request based on the transaction identifier.

[0076]

[0080] In other examples, the techniques discussed herein include accessing first data at a first bidirectional application programming interface (API) in a first computing environment of a one-way transmission (OWT) system, the first data being associated with a transaction identifier; applying a first policy to the first data using a first policy engine in the first computing environment; transmitting the first data to a second bidirectional API in a second computing environment of the OWT system, the first and second computing environments being separated by a data boundary of the OWT system; receiving second data associated with the first data by the second bidirectional API; applying a second policy to the second data using a second policy engine in the second computing environment; and providing the second data to the first computing environment.

[0077]

[0081] In other examples, the techniques discussed herein relate to a one-way transmission (OWT) environment, which includes a processing system and a memory containing computer executable instructions that, when executed, receive first data at a bidirectional application programming interface (API) in a first computing environment of a one-way transmission (OWT) system, the first data being associated with a transaction identifier and representing a first unidirectional data flow; apply a first policy set to the first data using a first policy engine based on the transaction identifier; transmit the first data to a second computing environment of the OWT system; receive second data associated with the first data, the second data representing a second unidirectional data flow; apply a second policy set to the second data, the first policy set being different from the second policy set; transmit the second data to the first computing environment; and provide the second data to the first computing environment.

[0078]

[0082] Aspects of this disclosure have been described, for example, with respect to block diagrams and / or operation diagrams of methods, systems, and computer program products according to aspects of this disclosure. The functions / operations described within a block may be performed in an order other than that shown in any flowchart. For example, depending on the functions / actions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may be executed in reverse order.

[0079]

[0083] The descriptions and illustrations of one or more embodiments provided herein are not intended to limit or restrict in any way the scope of the claimed disclosure. The embodiments, examples, and details provided herein are considered sufficient to transfer ownership and enable others to manufacture and use the best mode of the claimed disclosure. The claimed disclosure should be construed as being not limited to any embodiments, examples, or details provided herein. It is intended to generate embodiments having a particular set of features by selectively including or excluding various features (both structural and methodological), whether illustrated and described in combination or individually. A person skilled in the art who has received the descriptions and illustrations of the application will be able to conceive of modifications, improvements, and alternative embodiments that fall within the spirit of a broader embodiment of the overall inventive concept embodied herein and do not deviate from the broader scope of the claimed application.

Claims

1. System (100), Processing system (402), The processing system (402) includes a memory (404) connected to it, and when the memory (404) is executed, Receiving a data request at a first bidirectional application programming interface (API) in a first computing environment of a one-way transmission (OWT) system, wherein the data request is associated with a transaction identifier, (302) Applying the first policy set to the data request using the first security abstraction engine (304), (306) Sending the data request to the second computing environment of the OWT system, Receiving response data associated with the data request from the second computing environment (314), Based on the transaction identifier, provide the response data in response to the data request (316), A system (100) that includes computer executable instructions that perform an operation including the following.

2. The aforementioned operation is, In response to receiving the data request in the second computing environment, the second bidirectional API in the second computing environment is activated. The second bidirectional API retrieves the response data associated with the data request (308), Applying a second policy set to the response data using a second security abstraction engine (310), Transmitting the response data to the first computing environment (314), The system (100) according to claim 1, further comprising:

3. The aforementioned first computing environment is The aforementioned second computing environment does not trust it, When the data request is within the second computing environment, the data request cannot be tracked. The system (100) according to claim 1.

4. The system (100) according to claim 1, wherein the transaction identifier indicates a use case for the data request, and the use case describes at least one of user objectives or routing information for the data request.

5. The first bidirectional API is, The correlation between the aforementioned transaction identifiers, A first connection between the first bidirectional API and the source component, the first connection used to provide the data request to the first bidirectional API. The system (100) according to claim 1, which stores [something].

6. The first connection remains open while the response data is being retrieved from the second computing environment. The first bidirectional API uses the first connection to provide the response data to the source component, thereby facilitating synchronous data transmission of the data request and the response data. The system (100) according to claim 5.

7. The first connection is closed when the first bidirectional API receives the data request from the source component. The first bidirectional API, in response to receiving the response data, opens a second connection with the source component. The first bidirectional API uses the second connection to provide the response data to the source component, thereby facilitating asynchronous data transmission of the data request and the response data. The system (100) according to claim 5.

8. Receiving the data request via the first bidirectional API (302) means The first bidirectional API applies routing information to the data request based on the transaction identifier, wherein the routing information indicates a route to the second computing environment or a destination within the second computing environment. Applying a message wrapper to the data request, wherein the message wrapper includes routing information; The system (100) according to claim 1, including the system described in claim 1.

9. The system (100) according to claim 1, wherein the first policy set defines at least one of data content, file types, or task request types that are permitted to be transmitted from the first computing environment to the second computing environment.

10. Sending the aforementioned data request to the second computing environment (306) is, The data request is transmitted to a third security abstraction engine in the second computing environment, wherein the third security abstraction engine Data content, File type, or Types of task requests permitted to be received from the first computing environment or transmitted by the second computing environment To transmit, which specifies at least one of the following: Before providing the response data to the second bidirectional API, the third security abstraction engine applies the third policy set to the data request (312), The system (100) according to claim 2, including the above.

11. Retrieving response data (308) This involves removing the message wrapper from the aforementioned data request to create an unwrapped data request, The second bidirectional API identifies the destination indicated by the unwrapped data request, The destination performs an action to receive the response data, The system (100) according to claim 2, including the above.

12. The system (100) according to claim 2, wherein the second policy set defines at least one of the data content or file types that are permitted to be transmitted from the second computing environment to the first computing environment.

13. Transmitting the response data to the first computing environment (314) The second security abstraction engine transmits the response data to the first bidirectional API. The system (100) according to claim 2, including the above.

14. Providing the response data in response to the data request (316) The first bidirectional API includes providing the response data to an interface used to send the data request to the first bidirectional API, the interface being implemented within the first computing environment. The system (100) according to claim 1.

15. Method (300), Accessing first data in a first bidirectional application programming interface (API) within a first computing environment of a one-way transmission (OWT) system, wherein the first data is associated with a transaction identifier (302), Applying the first policy to the first data using the first policy engine in the first computing environment (304), Transmitting the first data to a second bidirectional API in the second computing environment of the OWT system, wherein the first computing environment and the second computing environment are separated by the data boundary of the OWT system (306), The second bidirectional API receives the second data associated with the first data (308), Applying the second policy to the second data using the second policy engine in the second computing environment (312), Providing the second data to the first computing environment (314), A method including (300).

16. The first data mentioned above indicates the task to be performed within the second computing environment. The second data mentioned above indicates the completion status of the task. The method according to claim 15 (300).

17. The method according to claim 15 (300), wherein the second bidirectional API associates the transaction identifier with the second data so that the second data can be transmitted to the first computing environment.

18. The method according to claim 15 (300), wherein the first policy identifies the transaction identifier by matching it with a corresponding transaction identifier stored in a data structure, and the data structure correlates the corresponding transaction identifier with the first policy.

19. The second policy prevents unauthorized data from being transmitted from the second computing environment to the first computing environment. The first policy is different from the second policy. The method according to claim 15 (300).

20. One-way transmission (OWT) environment (200), Processing system (402), It is memory (404), and when executed, Receiving first data via a bidirectional application programming interface (API) in a first computing environment of a one-way transmission (OWT) system, wherein the first data is associated with a transaction identifier and represents a first unidirectional data flow (302), Based on the transaction identifier, the first policy engine is used to apply the first policy set to the first data (304), Transmitting the first data to the second computing environment of the OWT system (306), Receiving a second data associated with the first data, wherein the second data represents a second unidirectional data flow (308), Applying a second policy to the second data, wherein the first policy is different from the second policy (312), Transmitting the second data to the first computing environment (314), Providing the second data to the first computing environment (316), Memory (404) containing computer executable instructions that perform operations including, A one-way transmission (OWT) environment (200) including [unclear text].

Images