Nested Request-Response Protocol Network Communication

Abstract

The controller computing device may include one or more processors and a memory including controller data representative of the capabilities of the controller computing device. The one or more processors may be configured to send a controller request including the controller data to the agent computing device over a first instance of a request-response protocol. The controller computing device may then receive an agent request from the agent computing device over a second instance of the request-response protocol. The agent request may include agent data representative of the capabilities of the agent computing device. The controller computing device may store the agent data in memory and send a controller response to the agent computing device over the second instance of the request-response protocol confirming receipt of the agent request. The controller computing device may then receive an agent response from the agent computing device over the first instance of the request-response protocol confirming receipt of the controller request.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 579,964, filed January 20, 2022, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] The remote network management platform may be in the form of a hosted environment that provides application platform as a service (aPaaS) services to users, particularly operators of managed networks such as enterprises. Such services may be in the form of web-based portals and / or software applications that may be accessed by the enterprise and its users, both internal and external, through a computing instance of the remote network management platform.

[0003] In a managed network environment, managing the services and interfaces of a remote network management platform typically involves the coordination and maintenance of software applications and associated data across multiple computing devices and systems. One aspect of this coordination and maintenance relates to version control and updates that help promote compatibility among the network devices on which the services are executed, provided, and consumed. Summary of the Invention

[0004] Exemplary embodiments herein provide systems and methods for enhancing the coordination and maintenance of versions and / or updates of software applications and data across multiple computing devices and systems of a managed network. More specifically, when an application or service is executed between two or more networked computing devices or systems, proper execution may depend, at least in part, on the compatibility of software versions and / or associated data. For example, different update or upgrade schedules between the two or more computing devices may cause incompatibility. To address possible instances of out-of-sync software versions and / or associated data between two or more devices, the devices may detect each other's version status through various communications and take steps to ensure and / or adjust compatibility. Such communications may serve as a form of discovery that allows two or more devices to establish a baseline of compatible application functionality and / or associated data. The communications may involve, for example, the exchange of functional data and / or other indicators of each device's functionality with respect to an identified set of applications or services. A typical scenario for a network-based application may include communication between a client and a server, although other configurations are possible, such as communication between two or more servers or between a controller and an agent.

[0005] In the context of managed networks, and network-based applications generally, communication protocols used to support software applications and associated data are widely adopted and implemented. However, these same protocols can also be a constraint on operations involving the coordination of functions between computing devices and systems responsible for running the software applications and / or using / applying the associated data. More specifically, web-based and other network-based applications may typically communicate instructions and / or data asynchronously by using separate instances of request-response protocols. In the case of an operation such as the coordination of functions of two devices, the asynchronous nature of the processes on the devices may make it difficult for the two devices to determine that an adjustment of their respective functional states was correct and / or successful.

[0006] A common and widely adopted architectural style for non-transactional protocols is the well-known "REST" ("Representational State Transfer") model, and one non-limiting example of a protocol that follows REST is the widely used "Hypertext Transfer Protocol" ("HTTP"). While individual instances of requests and responses are generally well suited to supporting the operation of web- and network-based applications (e.g., with a significant degree of "hard-wiredness" in the case of REST and HTTP), single-instance request-response communication may be inadequate for transactional tasks involved in coordinating functionality. These deficiencies may introduce inefficiencies, such as operational delays, in functionality detection and coordination.

[0007] One approach to addressing the deficiencies of existing, widely adopted protocols may be to design and / or develop new protocols that specifically target the nature of transactions that coordinate the functions of two or more networked computer devices. However, the inventors have recognized that, despite their intent to address the deficiencies of existing protocols, the potentially high barriers to acceptance of replacing an existing, widely adopted, industry-standard communications protocol with an initially unproven new protocol may make such an approach impractical or undesirable. Instead, the inventors have devised a novel technique for ensuring compatible operation by adapting existing request-response protocols to support transactional communications well suited for coordinating and / or synchronizing the functions of networked devices. Thus, the exemplary embodiments herein provide systems and methods for nesting request-response communications that introduce stateful transactions into non-transactional communications.

[0008] Exemplary embodiments herein are described with respect to network-based applications and services executed by two computer devices or systems communicatively coupled by a network or communication system. Network-based applications may include web-based applications, but may also include other types of applications executed in coordination and / or communication between the two computer devices. Non-limiting examples of communicating computer devices include a client and a server, and / or a controller computer device and an agent computer device. In some scenarios, the controller computer device may also be a server, and the agent computer device may also be a client. However, other configurations are possible as well, such as between two servers or network devices, two clients, and other peer-to-peer configurations. For purposes of illustration and by way of example, the two computer devices included in the exemplary embodiment of nested request-response protocol communication are referred to as a controller computer device and an agent computer device. This should not be taken as a limitation on other possible configurations of two or more computer devices.

[0009] Thus, a first exemplary embodiment may include a controller computing device comprising: a memory including controller data representative of capabilities of the controller computing device; and one or more processors configured to: send a controller request to an agent computing device on a first instance of a request-response protocol, the controller request including the controller data; after sending the controller request, receive an agent request from the agent computing device on a second instance of the request-response protocol, the agent request including agent data representative of capabilities of the agent computing device; store at least a portion of the agent data in memory; send a controller response to the agent request to the agent computing device on the second instance of the request-response protocol, the controller response confirming receipt of the agent request; and after sending the controller response, receive an agent response from the agent computing device on the first instance of the request-response protocol, the agent response confirming receipt of the controller request.

[0010] A second exemplary embodiment may include an agent computing device comprising an agent computing device, the agent computing device comprising a memory including agent data representative of capabilities of the agent computing device; and one or more processors configured to: receive a controller request from a controller computing device on a first instance of a request-response protocol, the controller request including the controller data representative of capabilities of the controller computing device; store at least a portion of the controller data in the memory; after receiving the controller request, send an agent request to the controller computing device on a second instance of the request-response protocol, the agent request including at least a portion of the agent data; receive a controller response to the agent request from the controller computing device on the second instance of the request-response protocol, the controller response confirming receipt of the agent request; and after receiving the controller response, send an agent response to the controller computing device on the first instance of the request-response protocol, the agent response confirming receipt of the controller request.

[0011] A third exemplary embodiment may include a method including: sending a controller request from a controller computing device to an agent computing device on a first instance of a request-response protocol, the controller request including controller data representative of capabilities of the controller computing device; after sending the controller request, receiving an agent request at the controller computing device on a second instance of the request-response protocol from the agent computing device, the agent request including agent data representative of capabilities of the agent computing device; storing at least a portion of the agent data in a memory of the controller computing device; sending a controller response to the agent request from the controller computing device on the second instance of the request-response protocol to the agent computing device, the controller response confirming receipt of the agent request; and after sending the controller response, receiving an agent response at the controller computing device from the agent computing device on the first instance of the request-response protocol, the agent response confirming receipt of the controller request.

[0012] In a fourth exemplary embodiment, an article of manufacture may include a non-transitory computer-readable medium having stored thereon program instructions that, when executed by a controller computing device of a computer system, cause the computer system to perform the operations described in the first and / or second exemplary embodiments.

[0013] In a fourth exemplary embodiment, a computer system may include at least one processor as well as a memory and program instructions that may be stored in the memory and that, when executed by the at least one processor, may cause the computer system to perform the operations described in the first and / or second exemplary embodiments.

[0014] In the fifth exemplary embodiment, the system may comprise various means for performing the operations of the first, second and / or third exemplary embodiments, respectively.

[0015] These and other embodiments, aspects, advantages, and alternatives will become apparent to those skilled in the art upon reading the following detailed description, with reference to the accompanying drawings, as appropriate. Moreover, this summary, as well as other descriptions and figures set forth herein, are intended to illustrate embodiments by way of example only, and many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, removed, or otherwise modified while remaining within the scope of the embodiments, as claimed. [Brief description of the drawings]

[0016] [Figure 1] FIG. 2 is a schematic diagram of a computing device according to an exemplary embodiment. [Diagram 2] FIG. 2 is a diagram of a server device cluster in accordance with an exemplary embodiment. [Diagram 3] FIG. 1 illustrates a remote network management architecture according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5A] FIG. 2 illustrates another communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 5B] 1 is a flow chart according to an exemplary embodiment. [Figure 6] FIG. 2 illustrates exemplary device capability data and compatibility configurations for two exemplary devices, according to an exemplary embodiment. [Figure 7] FIG. 1 illustrates an example of a conventional request-response protocol communication between two exemplary devices. [Figure 8]FIG. 2 illustrates an example of a nested request-response protocol communication between two exemplary devices, according to an exemplary embodiment. [Figure 9] 1 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Exemplary methods, apparatus, and systems are described herein. It should be understood that the words "example" and "exemplary" are used herein to mean "serving as an example, instance, or illustration." Any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or features, unless so stated. Thus, other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein.

[0018] Accordingly, the exemplary embodiments described herein are not meant to be limiting in any way. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of functionality into "client" and "server" components can be implemented in many ways.

[0019] Moreover, unless the context indicates otherwise, the features shown in each of the drawings can be used in combination with one another, with the understanding that the drawings should generally be viewed as component aspects of one or more overall embodiments, and that not all of the illustrated features are required for each embodiment.

[0020] Additionally, any recitation of elements, blocks, or steps in the specification or claims is for purposes of clarity, and therefore such recitation should not be construed as requiring or implying adherence to a particular arrangement of those elements, blocks, or steps, or performance in a particular order.

[0021] I. Introduction The following discussion is presented as an example in the context of a large enterprise. It is to be understood that the various principles of architecture and operation of the exemplary embodiments herein are not limited by this exemplary context, nor are the various principles of architecture and operation of the exemplary embodiments limited to application to a large enterprise. Rather, the exemplary embodiments may be applied and / or extended to any usage scenario involving client devices, server devices, and other computing devices capable of implementing services and resources that include common and / or coordinated software and data components.

[0022] Large enterprises are complex entities with many interrelated activities. Some of these can be found across the enterprise, such as human resources (HR), supply chain, information technology (IT), and finance. However, each enterprise also has its own unique activities that provide critical capabilities and / or build competitive advantage.

[0023] To support a wide range of business operations, enterprises typically use off-the-shelf software applications, such as customer relationship management (CRM) and human capital management (HCM) packages. However, custom software applications may also be required to meet the unique requirements of the enterprise. Large enterprises often have dozens or even hundreds of these custom software applications. In contrast, the advantages provided by embodiments herein are not limited to large enterprises, but may be applicable to enterprises of any size or other types of organizations.

[0024] Many such software applications are developed by individual departments within a company. These range from simple spreadsheets to bespoke software tools and databases. However, the proliferation of disconnected, custom software applications has many drawbacks. This negatively impacts a company's ability to operate and grow its business, innovate, and meet regulatory requirements. Without a single system that integrates its subsystems and data, companies may find it difficult to integrate, streamline, and enhance their operations.

[0025] To efficiently generate custom applications, enterprises would benefit from remotely hosted application platforms that eliminate unnecessary development complexity. The goal of such platforms is to reduce time-consuming, repetitive application development tasks, allowing software engineers and other individuals to focus on developing high-value, unique functionality.

[0026] To achieve this goal, the concept of aPaaS (Application Platform as a Service) is introduced to intelligently automate workflows across the enterprise. aPaaS systems are hosted remotely from the enterprise but have access to the enterprise's data, applications, and services through a secure connection. Such aPaaS systems have many advantageous features and characteristics that are believed to improve the enterprise's operations and workflows in terms of IT, HR, CRM, customer service, application development, and security.

[0027] aPaaS systems may support the development and execution of Model-View-Controller (MVC) applications. MVC applications enable efficient code reuse and parallel development by separating the representation of information from the way that information is presented to the user by dividing each functionality into three interconnected parts (model, view, and controller). These applications may be web-based and provide create, read, update, and delete (CRUD) functionality, allowing new applications to be built on a common application infrastructure.

[0028] An aPaaS system may support standardized application components, such as a standardized set of widgets for graphical user interface (GUI) development. In this way, applications built using an aPaaS system have a common look and feel. Other software components and modules may be standardized as well. In some cases, this look and feel can be branded or skinned with a company's custom logo and / or color scheme.

[0029] aPaaS systems may support the ability to configure application behavior using metadata, allowing applications to quickly adapt their behavior to meet specific needs. Such an approach reduces development time and increases flexibility. Additionally, aPaaS systems may support GUI tools that make metadata creation and management easier, reducing metadata errors.

[0030] An aPaaS system may support well-defined interfaces between applications, allowing software developers to avoid unnecessary inter-application dependencies. To this end, an aPaaS system may implement a service layer where data such as persistent state information is stored.

[0031] An aPaaS system may support a rich set of integration capabilities so that applications on the system can interact with legacy and third-party applications. For example, an aPaaS system may support a custom employee training system that integrates with legacy HR, IT, and accounting systems.

[0032] The aPaaS system may support enterprise-level security. Additionally, because the aPaaS system may be hosted remotely, it should also utilize security procedures when interacting with enterprise systems or with third-party networks and services hosted outside the enterprise. For example, the aPaaS system may be configured to detect and identify common security threats by sharing data between parties such as enterprises.

[0033] There may also be other features, functions, and advantages of an aPaaS system. This description is for illustrative purposes and is not intended to be limiting in any way.

[0034] As an example of an aPaaS development process, a software developer may be tasked with creating a new application using an aPaaS system. The developer may first specify a data model that specifies the types of data the application will use and the relationships between each. The developer then inputs (e.g., uploads) the data model via the aPaaS system's GUI. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which are accessible through an object-oriented services layer.

[0035] The aPaaS system can also build a fully functional application with a client-side interface and server-side CRUD logic. This generated application can serve as a basis for the user's further development. Developers do not need to spend a lot of time on the basic functionality of the application, which is convenient. Furthermore, the application can be web-based, so that it can be accessed from any internet-enabled client device. Alternatively or additionally, a local copy of the application can be accessed, for example, when internet service is not available.

[0036] The MVC architecture discussed herein as an example should not be taken as limiting in any way with respect to the exemplary embodiments: other architectural paradigms, such as unidirectional data flow, are possible as well.

[0037] Additionally, aPaaS systems may support a rich set of predefined features that can be added to applications, including search, email, templates, workflow design, reporting, analytics, social media, scripting, mobile output, and support for customized GUIs.

[0038] Such an aPaaS system may represent the GUI in a variety of ways. For example, a server machine in the aPaaS system may generate a representation of the GUI using a combination of HTML and JAVASCRIPT. The JAVASCRIPT may include client-side executable code, server-side executable code, or both. The server machine may send or otherwise provide this representation to the client machine so that the client machine displays it on its screen according to a locally defined look and feel. Alternatively, the representation of the GUI may be in some other form, such as an intermediate form (e.g., JAVA bytecode) that the client machine can use to generate graphical output directly. There are other possibilities.

[0039] Additionally, user interaction with GUI elements, such as buttons, menus, tabs, sliders, checkboxes, toggles, etc., may be referred to as "selecting," "activating," or "actuating," respectively. These terms may be used regardless of whether the interaction with the GUI element is through a keyboard, a pointing device, a touch screen, or another mechanism.

[0040] The aPaaS architecture is particularly effective when integrated with and used to manage an enterprise's network. The following embodiments describe the architecture and functional aspects of an exemplary aPaaS system, as well as respective features and advantages.

[0041] II. Exemplary Computing Device and Cloud-Based Computing Environment 1 is a simplified block diagram illustrating a computing device 100 showing some of the components that may be included on the computing device and configured to operate in accordance with embodiments herein. The computing device 100 may be a client device (e.g., a device that is actively operated by a user), a server device (e.g., a device that provides computing services to client devices), or some other type of computing platform. Some server devices may act as client devices at times to perform certain operations, and some client devices may incorporate server functionality.

[0042] In this example, computing device 100 includes a processor 102, memory 104, a network interface 106, and input / output units 108, all of which may be coupled by a system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripherals (e.g., removable storage, printers, etc.).

[0043] The processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a co-processor (e.g., a mathematical, graphics, or encryption co-processor), a digital signal processor (DSP), a network processor, and / or in the form of an integrated circuit or controller that performs processor operations. In some cases, the processor 102 may be one or more single-core processors. In other cases, the processor 102 may be one or more multi-core processors with multiple independent processing units. The processor 102 may also include a register memory for temporarily storing instructions and associated data to be executed, as well as a cache memory for temporarily storing recently used instructions and data.

[0044] Memory 104 may be any form of computer usable memory, including, but not limited to, random access memory (RAM), read only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact disks (CDs), digital video disks (DVDs), and / or tape storage). Thus, memory 104 represents both a main memory unit and long term storage. Other types of memory include biological memory.

[0045] The memory 104 may store program instructions and / or data on which the program instructions may operate. As an example, the memory 104 may store program instructions on a non-transitory computer-readable medium such that, upon execution by the processor 102, these instructions may perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0046] As shown in FIG. 1, the memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. The firmware 104A may be program code used to boot or start some or all of the computing device 100. The kernel 104B may be an operating system including modules for memory management, processor scheduling and management, input / output, and communication. The kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, network interfaces, ports, and buses) of the computing device 100. The applications 104C may be one or more user space software programs, such as a web browser or email client, as well as any software libraries used by these programs. The memory 104 may also store data used by these and other programs and applications.

[0047] The network interface 106 may be in the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cable or power line, or wide area media, such as Synchronous Optical Networking (SONET) or Digital Subscriber Line (DSL) technologies. The network interface 106 may also be in the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH, Global Positioning System (GPS), or wide area wireless interfaces. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over the network interface 106. Furthermore, the network interface 106 may include multiple physical interfaces. For example, some embodiments of the computing device 100 may include Ethernet, BLUETOOTH, and Wifi interfaces.

[0048] The input / output unit 108 may facilitate user and peripheral interaction with the computing device 100. The input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, etc. Similarly, the input / output unit 108 may include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, the computing device 100 may communicate with other devices, for example, by using a Universal Serial Bus (USB) or a High Definition Multimedia Interface (HDMI) port interface.

[0049] In some embodiments, an aPaaS architecture may be supported by the deployment of one or more computing devices, such as computing device 100. The exact physical location, connectivity, and configuration of these computing devices may not be known and / or important to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed in a variety of remote data center locations.

[0050] Figure 2 illustrates a cloud-based server cluster 200 according to an example embodiment. In Figure 2, the operation of a computing device (e.g., computing device 100) may be distributed among server devices 202, data storage 204, and routers 206, all of which may be connected by a local cluster network 208. The number of server devices 202, data storage 204, and routers 206 in server cluster 200 may depend on the computing tasks and / or applications assigned to server cluster 200.

[0051] For example, server devices 202 may be configured to perform various computational tasks for computer device 100. Thus, computational tasks may be distributed to one or more server devices 202. To the extent that these computational tasks can be performed in parallel, such distribution of tasks may reduce the total time to complete these tasks and return results. For simplicity, both server cluster 200 and individual server devices 202 may be referred to as "server devices." This nomenclature should be understood as an implication that one or more different server devices, data storage devices, and cluster routers may be involved in the operation of a server device.

[0052] Data storage 204 may be a data storage array including a drive array controller configured to manage read and write access to a set of hard disk drives and / or solid state drives. The drive array controller may also be configured, alone or in conjunction with server devices 202, to manage backup or redundant copies of data stored on data storage 204 to protect against drive failure or other types of failure that would prevent one or more server devices 202 from accessing units of data storage 204. Other types of memory besides drives may also be used.

[0053] Router 206 may include network equipment configured to provide internal and external communications to server cluster 200. For example, router 206 may include one or more packet switching and / or routing equipment (including switches and / or gateways) configured to provide (i) network communications between server equipment 202 and data storage 204 via local cluster network 208, and / or (ii) network communications between server cluster 200 and other equipment via communications link 210 to network 212.

[0054] The configuration of router 206 may also be based at least in part on the data communications requirements of server equipment 202 and data storage 204, the latency and throughput of local cluster network 208, the latency, throughput, and cost of communications links 210, and / or other factors that may contribute to the cost, speed, fault tolerance, resilience, efficiency, and / or other design goals of the system architecture.

[0055] As one possible example, data storage 204 may include any form of database, such as a Structured Query Language (SQL) database. In such a database, various types of data structures may store information, including, but not limited to, tables, arrays, lists, trees, and tuples. Furthermore, any database in data storage 204 may be monolithic or distributed across multiple physical devices.

[0056] The server device 202 may be configured to transmit data to and / or receive data from the data storage 204. The transmission and retrieval may be in the form of SQL queries or other types of database queries and the output of such queries, respectively. Similarly, text, images, video, and / or audio may additionally be included. Furthermore, the server device 202 may organize the received data as a representation of a web page or web application. Such a representation may be in the form of a markup language, such as Hypertext Markup Language (HTML), Extensible Markup Language (XML), or some other standardized or proprietary format. Furthermore, the server device 202 may be capable of executing various types of computerized scripting languages, including, but not limited to, Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), JAVASCRIPT, and the like. Computer program code written in these languages ​​may facilitate the provision of web pages to client devices as well as the client devices' interaction with the web pages. Alternatively or additionally, JAVA may be used to facilitate the generation of web pages and / or provide web application functionality.

[0057] III. Exemplary Remote Network Management Architecture 3 illustrates a remote network management architecture according to an example embodiment, which includes three main components: a managed network 300, a remote network management platform 320, and a public cloud network 340, all connected by the Internet 350.

[0058] A. Managed Network Managed network 300 may be, for example, an enterprise network used by an entity for computing and communication tasks as well as storage of data. To this end, managed network 300 may include client devices 302, server devices 304, routers 306, virtual machines 308, firewalls 310, and / or proxy servers 312. Client devices 302 may be embodied by computing devices 100, server devices 304 may be embodied by computing devices 100 or server clusters 200, and routers 306 may be any type of router, switch, or gateway.

[0059] The virtual machine 308 may be embodied by one or more of the computer device 100 and the server cluster 200. In general, a virtual machine is an emulation of a computer system that mimics the functionality (e.g., processor, memory, and communication resources) of a physical computer. A single physical computer system, such as the server cluster 200, can support up to thousands of individual virtual machines. In some embodiments, the virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to the individual virtual machines, as well as performance and error reporting. Enterprises often employ virtual machines to efficiently allocate computing resources as needed. Providers of virtualized computer systems include VMWARE® and MICROSOFT®.

[0060] Firewall 310 may be one or more dedicated routers or server devices that protect managed network 300 from unauthorized attempts to access internal devices, applications, and services while allowing legitimate communications originating from managed network 300. Firewall 310 may also provide intrusion detection, web filtering, virus scanning, application layer gateways, and other applications or services. In some embodiments not shown in FIG. 3, managed network 300 may include one or more virtual private network (VPN) gateways for communicating with a remote network management platform 320 (see below).

[0061] The managed network 300 may also include one or more proxy servers 312. An embodiment of the proxy server 312 may be a server application that facilitates communication and movement of data between the managed network 300, the remote network management platform 320, and the public cloud network 340. In particular, the proxy server 312 may be capable of establishing and maintaining secure communication sessions with one or more computing instances of the remote network management platform 320. Such sessions may enable the remote network management platform 320 to discover and manage aspects of the architecture and configuration of the managed network 300 and its components. In some cases, the proxy server 312 may also assist the remote network management platform 320 to discover and manage aspects of the public cloud network 340 that the managed network 300 uses.

[0062] A firewall such as firewall 310 typically denies all communication sessions coming in via Internet 350 unless such sessions ultimately originate behind the firewall (i.e., a device on managed network 300) and the firewall is explicitly configured to support the sessions. Locating proxy server 312 behind firewall 310 (e.g., by being located within managed network 300 and protected by firewall 310) may allow proxy server 312 to initiate these communication sessions through firewall 310. This may mean that firewall 310 does not need to be specially configured to support incoming sessions from remote network management platform 320, thus avoiding a potential security risk to managed network 300.

[0063] In some cases, managed network 300 may consist of just a few devices and a few networks. In other deployments, managed network 300 may span multiple physical locations and include hundreds of networks and hundreds of thousands of devices. Thus, the architecture shown in FIG. 3 can be scaled up or down by orders of magnitude.

[0064] Furthermore, the number of proxy servers 312 deployed may vary depending on the size, architecture, and connectivity of the managed network 300. For example, each proxy server 312 may be responsible for communicating with a remote network management platform 320 for a portion of the managed network 300. Alternatively or additionally, sets of two or more proxy servers may be assigned to such portions of the managed network 300 to provide load balancing, redundancy, and / or improved availability.

[0065] B. Remote Network Management Platform The remote network management platform 320 is a hosted environment that provides aPaaS services to users, particularly operators of the managed network 300. These services may be in the form of a web-based portal, for example using the web-based technologies mentioned above. This allows users to securely access the remote network management platform 320, for example from the client device 302 or potentially from a client device outside the managed network 300. The web-based portal allows users to design, test, and deploy applications, generate reports, review analytics, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0066] As shown in FIG. 3, the remote network management platform 320 includes four compute instances 322, 324, 326, and 328. Each of these compute instances may represent one or more nodes running a dedicated copy of the aPaaS software and / or one or more database nodes. Flexible placement of servers and databases on physical server equipment and / or virtual machines may be allowed and may change based on the needs of the enterprise. In combination, these nodes may provide a set of web portals, services, and applications available to a particular enterprise (e.g., a fully functional aPaaS system). In some cases, a single enterprise may use multiple compute instances.

[0067] For example, managed network 300 may be an enterprise customer of remote network management platform 320 and may use compute instances 322, 324, and 326. A reason for providing multiple compute instances to a customer may be that the customer desires to independently develop, test, and deploy its applications and services. Thus, compute instance 322 may be dedicated to developing applications associated with managed network 300, compute instance 324 may be dedicated to testing these applications, and compute instance 326 may be dedicated to live operation of the tested applications and services. Computing instances may also be referred to as hosted instances, remote instances, customer instances, or some other designation. Any application deployed to a computing instance may be considered a scoped application in that access to the database within the computing instance may be restricted to specific elements therein (e.g., specific database table(s) or specific rows within one or more database tables).

[0068] For simplicity, this disclosure refers to the configuration of application nodes, database nodes, the aPaaS software running thereon, and the underlying hardware as a "computing instance." Note that users may colloquially refer to the graphical user interface provided thereby as an "instance." However, unless otherwise defined herein, a "computing instance" is a computer system disposed within the remote network management platform 320.

[0069] The multi-instance architecture of the remote network management platform 320 provides several advantages as opposed to traditional multi-tenant architectures. In a multi-tenant architecture, data from different customers (e.g., enterprises) is mixed in a single database. The data of these customers is isolated from each other, but this isolation is enforced by the software that operates the single database. As a result, a security breach in the system affects all of the customers' data, creating additional risks, especially for government, healthcare, and / or financial regulated entities. Furthermore, any database operation that affects one customer may affect all customers that share the database. Thus, in the case of an outage due to a hardware or software error, the outage affects all such customers. Similarly, when a database is upgraded to meet the needs of one customer, the upgrade process makes it unavailable to all customers. Such maintenance windows are often long due to the size of the shared database.

[0070] In contrast, a multi-instance architecture provides each customer with its own database in a dedicated compute instance. This prevents intermingling of customer data and allows for independent management of each instance. For example, if one customer's instance goes down due to an error or upgrade, other compute instances are not affected. Maintenance downtime is limited because the database contains only one customer's data. In addition, the simpler design of a multi-instance architecture allows redundant copies of each customer database and instance to be deployed geographically diversely. This promotes high availability and allows the live version of a customer's instance to be moved when a failure is detected or maintenance is performed.

[0071] In some embodiments, the remote network management platform 320 may include one or more central instances controlled by the entity that operates the platform. Similar to the computing instances, the central instance may include several application and database nodes distributed on several physical server devices or virtual machines. Such a central instance may act as a repository for the computing instances as well as a particular configuration of data that may be shared by at least some of the computing instances. For example, there may be definitions of common security threats that may occur on the computing instances, software packages commonly found on the computing instances, and / or an application store for applications that may be deployed on the computing instances. The computing instances may communicate with the central instance by well-defined interfaces to obtain this data.

[0072] To efficiently support multiple computing instances, remote network management platform 320 may run multiple of these instances on a single hardware platform. For example, when running on a server cluster, such as server cluster 200, the aPaaS system may run virtual machines that allocate different amounts of computing, storage, and communication resources to the instances. However, full virtualization of server cluster 200 is not required, and other mechanisms may provide for isolation of instances. In some examples, each instance may have a dedicated account on server cluster 200 as well as one or more dedicated databases. Alternatively, a computing instance, such as computing instance 322, may span multiple physical devices.

[0073] In some cases, a single server cluster of remote network management platform 320 may support multiple independent enterprises. Additionally, as described below, remote network management platform 320 may include multiple server clusters deployed in geographically diverse data centers to facilitate load balancing, redundancy, and / or high availability.

[0074] C. Public Cloud Networks Public cloud network 340 may be remote server equipment (e.g., multiple server clusters, such as server cluster 200) available for outsourced computing, data storage, communication, and service hosting activities. These servers may be virtualized (i.e., virtual machines). Examples of public cloud network 340 include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to remote network management platform 320, multiple server clusters supporting public cloud network 340 may be deployed in diverse geographic locations for load balancing, redundancy, and / or high availability purposes.

[0075] The managed network 300 may use one or more public cloud networks 340 to deploy applications and services to its clients and customers. For example, if the managed network 300 provides an online music streaming service, the public cloud network 340 may store the music files and provide a web interface and streaming capabilities. In this way, the businesses in the managed network 300 do not need to build and maintain their own servers for these operations.

[0076] The remote network management platform 320 may include modules that expose internal virtual machines and managed services to the managed network 300 through integration with the public cloud network 340. These modules may enable users to request virtual resources, discover allocated resources, and flexibly report to the public cloud network 340. To establish this functionality, a user of the managed network 300 may first open an account with the public cloud network 340 and request a set of related resources. The user may then input the account information into the appropriate modules of the remote network management platform 320. These modules may then automatically discover the manageable resources of the account and provide reports related to usage, performance, and billing.

[0077] D. Communications Support and Other Operations Internet 350 may represent a portion of the global Internet, although Internet 350 may alternatively represent different types of networks, such as private wide-area or local-area packet-switched networks.

[0078] Figure 4 further illustrates the communication environment between managed network 300 and computing instances 322, introducing additional features and alternative embodiments. In Figure 4, all or a portion of computing instances 322 are replicated in both data centers 400A and 400B. These data centers may be geographically separate from one another, perhaps in different cities or different countries. Each data center includes managed network 300 as well as supporting facilities that facilitate communication with remote users.

[0079] In the data center 400A, network traffic to external devices flows through a VPN gateway 402A or a firewall 404A. The VPN gateway 402A may be peered with a VPN gateway 412 of the managed network 300 by a security protocol such as Internet Protocol Security (IPSEC) or Transport Layer Security (TLS). The firewall 404A may be configured to allow access from authorized users, such as the user 414 and the remote user 416, and to deny access to unauthorized users. The firewall 404A allows these users to access the computing instance 322 and possibly other computing instances. The load balancer 406A may be used to distribute traffic among one or more physical or virtual server devices hosting the computing instance 322. The load balancer 406A may simplify user access by hiding the internal configuration of the data center 400A (e.g., the computing instance 322) from client devices. For example, if a computing instance 322 includes multiple physical or virtual computing machines that share access to multiple databases, the load balancer 406A may distribute network traffic and processing tasks among those computing machines and databases so that some computing machines or databases are not significantly busier than others. In some embodiments, a computing instance 322 may include a VPN gateway 402A, a firewall 404A, and a load balancer 406A.

[0080] Data center 400B may have its own versions of the components of data center 400A, such that VPN gateway 402B, firewall 404B, and load balancer 406B may perform the same or similar operations as VPN gateway 402A, firewall 404A, and load balancer 406A, respectively. Additionally, computing instances 322 may exist simultaneously in data centers 400A and 400B, with real-time or near real-time database replication and / or other operations.

[0081] Data centers 400A and 400B as shown in Figure 4 may facilitate redundancy and high availability. In the configuration of Figure 4, data center 400A is active and data center 400B is passive. Thus, data center 400A serves all traffic for managed network 300 while the versions of computing instances 322 in data center 400B are updated in near real-time. Other configurations, such as a configuration in which both data centers are active, may be supported.

[0082] If data center 400A experiences some kind of failure or becomes unavailable to users, data center 400B can take over as the active data center. For example, a Domain Name System (DNS) server that associates the domain name of computing instance 322 with one or more Internet Protocol (IP) addresses of data center 400A may reassociate the domain name with one or more IP addresses of data center 400B. After this reassociation is complete (which may take less than a second or a few seconds), computing instance 322 is made accessible to users by data center 400B.

[0083] FIG. 4 also illustrates possible configurations of managed network 300. As described above, proxy server 312 and users 414 can access compute instance 322 through firewall 310. Proxy server 312 can also access configuration items 410. In FIG. 4, configuration items 410 may represent any or all of client device 302, server device 304, router 306, and virtual machine 308, any applications or services running thereon, as well as relationships between the devices, applications, and services. Thus, the term "configuration item" may be shorthand for any physical or virtual device, any application or service capable of being remotely discovered or managed by compute instance 322, or relationships between discovered devices, applications, and services. Configuration items may be represented in a configuration management database (CMDB) of compute instance 322.

[0084] As mentioned above, VPN gateway 412 may provide a dedicated VPN to VPN gateway 402A. Such a VPN may be useful when there is a large amount of traffic between managed network 300 and compute instance 322, or when security policies suggest or require the use of a VPN between these sites. In some embodiments, any device of managed network 300 and / or compute instance 322 that communicates directly through the VPN may be assigned a public IP address. Other devices of managed network 300 and / or compute instance 322 may be assigned a private IP address (e.g., an IP address selected from the ranges 10.0.0.0-10.255.255.255 or 192.168.0.0-192.168.255.255, abbreviated as subnets 10.0.0.0 / 8 and 192.168.0.0 / 16, respectively).

[0085] IV. EXEMPLARY DEVICE, APPLICATION, AND SERVICE DISCOVERY To manage the devices, applications, and services of the managed network 300, the remote network management platform 320 may initially determine the devices present in the managed network 300, the configurations and operational states of those devices, and the applications and services they provide, as well as the relationships between the discovered devices, applications, and services. As mentioned above, each device, application, service, and relationship may be referred to as a configuration item. The process of defining the configuration items in the managed network 300 is referred to as discovery, and may be facilitated, at least in part, by the proxy server 312.

[0086] For purposes of embodiments herein, an "application" may represent one or more processes, threads, programs, client modules, server modules, or any other software running on a device or group of devices. A "service" may represent advanced functionality provided by multiple applications running on one or more devices acting in conjunction with each other. For example, an advanced web service may include multiple web application server threads running on one device accessing information from a database application running on another device.

[0087] 5A is a logical depiction of how configuration items may be discovered, as well as how information associated with the discovered configuration items may be stored. For simplicity, the remote network management platform 320, the public cloud network 340, and the Internet 350 are not shown.

[0088] 5A, the CMDB 500 and task list 502 are stored in the computation instance 322. The computation instance 322 may send a discovery command to the proxy server 312. In response, the proxy server 312 may send probes to various devices, applications, and services in the managed network 300. These devices, applications, and services may send responses to the proxy server 312, which may then provide information about the discovered configuration items to the CMDB 500 for storage. The configuration items stored in the CMDB 500 represent the environment of the managed network 300.

[0089] The task list 502 represents a list of actions that the proxy server 312 is to perform on behalf of the computation instance 322. Once a detection is made, an entry is made in the task list 502. The proxy server 312 repeatedly queries the task list 502 to obtain the next task therein and executes this task until the task list 502 is empty or another stopping condition is reached.

[0090] To facilitate discovery, a proxy server 312 may be configured with information about one or more subnets in managed network 300 that are reachable by the proxy server 312. For example, the proxy server 312 may be given the IP address range 192.168.0 / 24 as a subnet. The computing instance 322 may then store this information in the CMDB 500 and place tasks in the task list 502 to discover devices at each of these addresses.

[0091] 5A also illustrates the devices, applications, and services in managed network 300 as configuration items 504, 506, 508, 510, and 512. As discussed above, these configuration items represent a set of physical and / or virtual devices (e.g., client devices, server devices, routers, or virtual machines), the applications running on them (e.g., web servers, email servers, databases, or storage arrays), the relationships between them, as well as services that include multiple individual configuration items.

[0092] Placing a task in the task list 502 may trigger or cause the proxy server 312 to initiate detection. Alternatively or additionally, detection may be manually or automatically triggered based on a triggering event (e.g., detection may be initiated automatically once a day at a particular time).

[0093] In general, discovery can take place in four logical stages: scanning, classification, identification, and exploration. Each stage of discovery involves different types of probe messages being sent by the proxy server 312 to one or more devices in the managed network 300. Responses to these probes may be received and processed by the proxy server 312, and a representation of each may be sent to the CMDB 500. Thus, with each stage, more configuration items may be discovered and stored in the CMDB 500.

[0094] During the scan phase, the proxy server 312 may determine the general type of device by probing each IP address within a specified range of IP addresses for open Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP) ports. The presence of such open ports at an IP address indicates that a particular application is running on the device to which that IP address is assigned, which may identify the operating system used by the device. For example, if TCP port 135 is open, the device is likely running a WINDOWS operating system. Similarly, if TCP port 22 is open, the device is likely running a UNIX operating system such as LINUX. If UDP port 161 is open, the device may be otherwise identifiable through Simple Network Management Protocol (SNMP). There are other possibilities. Once the presence of a device and its open ports at a particular IP address is detected, these configuration items are stored in the CMDB 500.

[0095] During the classification phase, the proxy server 312 may further probe each detected device to determine its operating system version. The probes used for a particular device are based on information collected about the device during the scan phase. For example, if a device is found with TCP port 22 open, a set of UNIX-specific probes may be used. Similarly, if a device is found with TCP port 135 open, a set of WINDOWS-specific probes may be used. In either case, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to log on to or access information from the particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to open a Secure Shell (SSH) connection to the particular device and retrieve information about the operating system on the device from a particular location in the file system. Based on this information, the operating system may be determined. As an example, a UNIX® device with an open TCP port 22 may be classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in the CMDB 500 as one or more configuration items.

[0096] During the identification phase, the proxy server 312 may determine specific details about the classified device. The probes used during this phase may be based on information collected about the particular device during the classification phase. For example, if the device is classified as LINUX, a set of LINUX specific probes may be used. Similarly, if the device is classified as WINDOWS 2012, a set of WINDOWS 2012 specific probes may be used. As with the classification phase, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to retrieve information from the particular device, such as basic input / output system (BIOS) information, serial numbers, network interface information, media access control addresses assigned to those network interfaces, IP addresses used by the particular device, etc. This identification information may be stored in the CMDB 500 as one or more configuration items.

[0097] During the discovery phase, the proxy server 312 may determine further details regarding the operational status of the classified device. The probes used during this phase may be based on information collected about the particular device during the classification and / or identification phase. Again, a suitable set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to retrieve additional information from the particular device, such as processor information, memory information, list of running processes (applications), etc. Here again, the detection information may be stored in the CMDB 500 as one or more configuration items.

[0098] Discovery may be performed on network devices such as routers using SNMP. As an alternative or in addition to determining a list of running processes or other application related information, discovery may involve the router determining additional subnets known to it and the operational state (e.g., active, inactive, queue lengths, number of dropped packets, etc.) of the router's network interfaces. The IP addresses of the additional subnets may be candidates for further discovery procedures. Thus, discovery may proceed in an iterative or recursive manner.

[0099] Once discovery is complete, a snapshot representation of each discovered device, application, and / or service is available in CMDB 500. For example, after discovery, operating system versions, hardware configurations, and network configuration details of client devices, server devices, and routers in managed network 300 may be stored, as well as the applications running on them. This collected information may be presented to a user in a variety of ways to allow the user to view the hardware configuration and operational status of devices, as well as the characteristics of services across multiple devices and applications.

[0100] Further, the CMDB 500 may include entries regarding dependencies and relationships between configuration items. More specifically, applications running on a particular server device as well as services that depend on the applications may be represented in this manner in the CMDB 500. For example, a database application may be running on a server device and may be used for a new employee training service as well as a payroll service. Thus, if the server device is taken out of service for maintenance, the employee training service and the payroll service will obviously be affected. Similarly, dependencies and relationships between configuration items may represent services that are affected if a particular router fails.

[0101] Typically, dependencies and relationships between configuration items may be displayed in a web-based interface and represented as a hierarchy, so that adding, modifying, or deleting such dependencies and relationships may be accomplished through this interface.

[0102] Additionally, users of managed network 300 can develop workflows that allow for the execution of specific coordinated actions across multiple discovered devices. For example, an IT workflow could allow a user to change a common administrator password for all discovered LINUX devices in a single operation.

[0103] To allow such discovery to occur, the proxy server 312, the CMDB 500, and / or one or more credential stores may be configured with credentials for one or more of the devices to be discovered. The credentials may include any type of information required to access the devices. These may include user ID / password pairs, certificates, etc. In some embodiments, these credentials may be stored in encrypted fields in the CMDB 500. The proxy server 312 may include decryption keys for these credentials so that the credentials can be used to log on to or access the devices to be discovered.

[0104] 5B illustrates the discovery process as a flow chart. In block 520, a task list in a computing instance is populated with, for example, various IP addresses. In block 522, a scanning phase occurs, whereby the proxy server probes the IP addresses for devices using the IP addresses and attempts to determine the operating systems running on these devices. In block 524, a classification phase occurs, whereby the proxy server attempts to determine the operating system versions of the detected devices. In block 526, an identification phase occurs, whereby the proxy server attempts to determine the hardware and / or software configuration of the detected devices. In block 526, a discovery phase occurs, whereby the proxy server attempts to determine the operational state and applications running on the detected devices. In block 530, further editing of configuration items representing the detected devices and applications can occur. This editing can be automated and / or manual in nature.

[0105] The blocks depicted in Figure 5B are examples. Detection may be a highly configurable procedure, with more or fewer stages possible, and each stage may operate differently. In some cases, one or more stages may be customized or may deviate from the exemplary description above.

[0106] In this manner, the remote network management platform can discover and inventory the hardware, software, and services deployed and provided on the managed network. As described above, this data may be stored as configuration items in the CMDB of the associated computing instance. For example, individual hardware components (e.g., computing devices, virtual servers, databases, routers, etc.) may be represented as hardware configuration items, while applications installed and / or executed thereon may be represented as software configuration items.

[0107] The relationships of software configuration items installed or executed on a hardware configuration item may be in various forms, such as hosting, executing, or depending. Thus, a database application installed on a server device may have a "hosting" relationship with the server device to indicate that the database application is hosted on the server device. In some embodiments, a server device may have a "using" mutual relationship with a database application to indicate that the server device is used by the database application. While these relationships may be discovered automatically using the discovery procedures described above, the relationships may also be configured manually.

[0108] Also, the relationship between a service and one or more software configuration items may take various forms. As an example, a web service may include a web server software configuration item and a database application software configuration item, each installed on a different hardware configuration item. The web service may have a "depends" relationship with both of these software configuration items, while the software configuration item has a "uses" interrelationship with the web service. Services may not be fully determined by a discovery procedure, but instead may rely on service mapping (e.g., probing configuration files and / or performing network traffic analysis to determine service level relationships between configuration items) and possibly some degree of manual configuration.

[0109] Regardless of how it is obtained, relationship information can be beneficial to the operation of a managed network. Among other things, IT personnel can quickly determine where specific software applications are deployed and the configuration items that make up the services. This allows for quick identification of the root cause of a service outage or degradation. For example, if two different services have slow response times, a CMDB query can determine (among other possible actions) that the root cause is high processor utilization in a database application used by both services. IT personnel can then address the database application without wasting time considering the health and performance of other configuration items that make up the services.

[0110] V. Nested Request-Response Protocol Communication A network-based application is an example of a program that operates across two or more computing devices. For example, in the context of a managed network, a typical configuration may include a controller-agent application that may be distributed across two (or more) servers. Other examples include client-server programs, such as web-based applications. Before application programs distributed across two or more servers can communicate, it may first be necessary to establish connections between dependent application components and the servers, including coordinating application features and / or functions. This may entail, for example, the two servers or other computing devices establishing a continuous secure communication channel using a predefined negotiated protocol.

[0111] More generally, proper operation of a distributed application may depend at least in part on synchronization and / or coordination of application program versions installed and / or operating on various communicatively connected computing devices. In accordance with synchronization and coordination, identical and / or compatible versions of software functionality and / or associated application-related data may be operating and / or resident on two or more computing devices involved in a distributed program execution. Unsynchronized program versions and / or incompatible functionality with respect to distributed software may also result, for example, from upgrades of one computing device or system or from the application of a common upgrade at different times.

[0112] Exemplary embodiments are described herein in the context of, by way of example, a controller computing device and an agent computing device configuration. The controller computing device can be a server and the agent computing device can be a client, although other configurations are possible. For example, the controller computing device and the agent computing device can both be networked computing devices or systems, such as servers, or both can be client devices that execute controller and agent components of an application program. In either case, it should be understood that no loss of generality is intended with respect to the exemplary embodiments by considering a controller-agent configuration.

[0113] In typical use cases or other operating scenarios, the controller computing device may initiate a form of feature detection procedure with the agent computing device to ensure that both devices are or can be made to be operationally compatible with respect to one or more application programs. Compatibility may relate to program features and functions and / or associated data. Compatibility of features and functions may be determined, for example, according to version number alignment, and compatibility of associated data may be determined, for example, according to some form of minimum commonality of data definitions on both devices. Compatibility alignment may include other operations, such as, for example, performing configuration initialization operations on one or both devices. Some examples of device feature compatibility are discussed below.

[0114] In discussions herein regarding synchronizing and / or coordinating the capabilities of two or more devices and determining compatibility of capabilities, the term "discovery" and related processes apply somewhat more specifically than discovery described above in the context of remotely managed networks and computing instances. More specifically, in the context of remotely manageable network resources such as devices, applications, and services, discovery more broadly includes processes for learning about the availability, location, and configuration of network resources. In the context of device capabilities, discovery includes processes for learning about compatibility between devices of distributed application programs and associated data. It should also be noted that discovery of capabilities is but one exemplary context in which an exemplary embodiment of a nested request-response protocol may be used.

[0115] As another illustrative example of a typical use case or other operating scenario, software applications may be upgraded at different times between servers in a network, resulting in the controller and agent having different capabilities at each point in time. As a result, existing connections may need to be renegotiated. To use new (e.g., upgraded) capabilities, both the controller and the agent may need to update their connections and ensure that the previously unsupported capabilities can be supported. In traditional asynchronous processing and network communication, a local controller computing device (or simply, a server) may initiate an asynchronous process that sends a request over a network to a remote agent computing device (or simply, another server), which may initiate another asynchronous process. Each of the local and remote processes may run to completion, resulting in a terminal state, e.g., success or error. However, due to the nature of asynchronous processing, one process may complete before the other, and the outcome of one process may depend on the outcome of the other. In some cases, the processes may be highly fault-tolerant. If servers are each independently responsible for creating and enabling connections or for selecting and enabling functions to be used with a connection, it is possible that one server may complete the process successfully while the other terminates with an error state or incomplete information. As a result, one server may have an active connection that may support a particular set of features or functions, while the other server shows the connection in an error state. This inconsistency in state may result in improper operation of distributed applications and / or other erroneous or undesirable functionality.

[0116] A conventional approach to coordinating functions may be to poll a remote server to ascertain the status or progress of a remote asynchronous process. However, this approach may not account for errors that do not indicate a remotely detectable terminal status of success or error, and polling may continue indefinitely. In another example, an asynchronous remote process may include a final step of initializing and establishing a connection while switching the connection state to active. When performed asynchronously and without coordination, one system may perform an initialization process, switch the state to active, and begin use before the other system has completed initialization and is ready to accept commands over the connection. These are just a few examples of the deficiencies of the prior art in the context of managed networks. The problem may be more generally understood in terms of a stateless request-response communication protocol applied to transactional operations between two computing devices.

[0117] A. Exemplary Network Communication Protocol for Distributed Applications In many, and perhaps most, current network-based applications (e.g., web-based applications), communication between application instances or components distributed across different devices is typically supported by separate instances of a stateless request-response communication protocol. A well-known example is HTTP, most of which follow the REST model. These protocols have matured and become widely adopted, and may be the de facto, if not the industry standard, for many applications and / or many managed networks running distributed software applications. Protocols that follow or are compliant with REST are sometimes referred to as "RESTful" protocols.

[0118] For purposes of explanation, the REST architectural model can be understood relative to a client-server model as follows: REST servers can provide access to (web) resources, and REST clients can access and modify the resulting resources. Communication between clients and servers can be supported by "methods", which are typically issued as requests from the client to the server. Acting on the request (e.g., method) can cause the server to send a response, which may include the resources provided in a representation format such as JSON and / or XML.

[0119] In a client-server context, the roles of client and server are associated with an entity that sends a request and an entity that sends a response to the request. However, it is to be understood that the roles of client and server need not be limited to a particular type of device that might normally assume such roles. For example, two typical client devices, such as end-user devices (desktop computers, smartphones, etc.), may participate in a RESTful protocol for a particular distributed application program such that one end-user device acts as a client and the other as a server. Similarly, in the context of some other distributed application program, two typical server devices, such as two servers of a remote network management system, may similarly act as one client and the other as a server. Other configurations are possible as well.

[0120] REST can be implemented using any standard application programming interface (API), with HTTP being perhaps the most common (though not the only possibility). In some embodiments, REST may use only the four methods of HTTP, tabulated below. [Table 1]

[0121] In some embodiments, REST may use additional methods such as PATCH and / or OPTIONS. Other embodiments may use even fewer methods than the four listed here.

[0122] The method may be sent as an HTTP request from a first computing device (e.g., a controller computing device) to a second computing device (e.g., an agent computing device), and the second computing device may respond by sending an HTTP response to the first computing device. Each request-response pair is executed as a separate instance. As mentioned above, the RESTful protocol may be implemented in various types of device pairs, such as client-client or server-server, which may correspond to the example controller-agent configuration considered in the exemplary embodiments herein. The above client-server example is an example of the roles of requester and responder in a request-response protocol and is not intended to be limiting in any way.

[0123] The feature detection procedure may entail stateful transactional communication between the controller computing device and the agent computing device, for which the request-response nature of REST, HTTP, and other similar models and protocols is not well suited. As a result, for many, if not most or all, web-based (and network-based) applications, the feature detection procedure may be subject to limitations that result in delays and / or other performance and / or operational inefficiencies. Accordingly, exemplary embodiments herein provide systems and methods for addressing respective limitations in transactional communication through nesting of request-response protocols. More particularly, the nesting of request-response communication protocols described herein as an example introduces stateful transactional communication into an unowned protocol. This advantageously addresses deficiencies in widely used request-response communication protocols without the need for replacement and / or reinventing the wheel.

[0124] Although the exemplary embodiments herein are presented with a view to addressing shortcomings of request-response communication protocols for capability discovery procedures, it is to be appreciated that the novel and advantageous techniques of nested request-response communication may be applied more generally to any scenario or situation in which a stateless request-response communication protocol imposes constraints on a procedure or process that could be better supported or benefited from stateful transactional communication, and thus the exemplary embodiments herein should not be construed as a limitation with respect to other applications of nested request-response communication.

[0125] Note that individual instances of request-response protocol communication may be described as unidirectional or half-duplex. This description does not negate the bidirectional nature of the request and subsequent response. Rather, it focuses on the stateless nature of the protocol used to communicate between two asynchronous processes. Another characteristic of half-duplex communication in the context of request-response protocol communication between two computational instances (e.g., two computing devices) is that only one of the instances can provide request data to a given request-response instance.

[0126] Before describing an example of conventional operation involving separate instances of request-response communication and an example of nested instances of request-response communication, a simple illustration of the coordination and synchronization of compatibility of features of two devices is provided.

[0127] B. Feature Adjustments and Compatibility FIG. 6 illustrates exemplary device capability data and compatibility configurations for two exemplary devices, according to an exemplary embodiment. As illustrated, a controller computer device 602 may have associated controller capability data 601, and an agent computer device 604 may have associated agent capability data 603. The capability data shown for each device is primarily conceptual illustrative, with capabilities being represented in a literal sense. In practice, the capability data may be in a more abstract form for storage and / or transmission. The literal representation of the capability data in FIG. 6 is not intended as a limitation on the exemplary embodiment. As an example, the capability data for both devices includes a list of user and device data, including at least one data version number, as well as a list of supported applications, including application version numbers.

[0128] The definition of compatible capabilities is considered the intersection of controller capability data 601 and agent capability data 603. This intersection is represented as a type of Venn diagram shown as overlapping and / or synchronizing capabilities 607. As shown, the overlap or intersection produces compatible capability data 605, while capability data excluded from the intersection is shown as controller capability incompatibility data 601-X and agent capability incompatibility data 603-X.

[0129] In the particular illustrative example of FIG. 6, the compatible user data includes "First Name, Last Name," while the middle initial ("MI") and "Reports To," which are part of the agent capability data 603, are excluded. The compatible device data includes "OS" and "Config Version 9.001," while "Config Version 9.104" and "ID" from the controller capability data 601 are excluded. The compatible applications are "UserSetUp Version 3.959," "DeviceSetUp Version 5.700," and "WebDocLib Version 3.2.15," while "UserSetUp Version 4.002" from the controller capability data 601 and "DeviceSetUp Version 5.741" and "WebDocLib Version 3.2.18" from the agent capability data are excluded. For this example, it is assumed that later versions of software applications and data configurations are backward compatible with earlier versions such that two or more computing devices using earlier versions are compatible.

[0130] The exemplary compatibility capability data 605 of Figure 6 may be considered to represent a synchronized capability state of the controller computing device 602 and the agent computing device 604. According to an exemplary embodiment, the synchronized capability state may be achieved by a procedure for capability coordination. As previously discussed, the use of a single instance of a conventional request-response communication protocol may be inefficient and in some cases may not achieve a proper synchronized capability state. An example of a conventional approach will now be described, followed by an exemplary embodiment of nested request-response communication.

[0131] C. Conventional Operation An example of a conventional use of a request-response communication protocol for the coordination of functions is shown in FIG. 7 in the form of a message flow diagram between a controller computing device 702 and an agent computing device 704. The message flow is shown as a generic request-response protocol, which could be implemented, for example, using HTTP or another REST-like protocol. In the message flow diagram, messages are represented by horizontal arrows between the controller computing devices 702 and 704, and time flows downwards in the diagram. Although no specific time scale is suggested, a typical time between a request and an associated response may be, for example, on the order of 1-2 seconds. Longer and / or shorter times are possible as well.

[0132] The basic flow of communication includes separate instances of a request-response message pair. In Figure 7, the separate instances are identified by dashed rectangles 721, 723, 725, and 727. The separate instances of the request-response message pair may also be executed by respective threads of execution on two computing devices. The execution threads are represented by short rectangular segments on the vertical timeline below the controller computing device 702 and the agent computing device 704. Specifically, instance 721 is shown as being executed by thread C7-1 on the controller computing device 702 and thread A7-1 on the agent computing device 704. Similarly, instance 723 is shown as being executed by thread C7-2 on the controller computing device 702 and thread A7-2 on the agent computing device 704, instance 725 is shown as being executed by thread C7-3 on the controller computing device 702 and thread A7-3 on the agent computing device 704, and instance 727 is shown as being executed by thread C7-4 on the controller computing device 702 and thread A7-4 on the agent computing device 704. In other configurations, a single thread on each device may execute all the instances.

[0133] In the illustrated example, at instance 721, the controller computing device 702 sends a controller request message S-701-rqst, which is a controller request including at least a portion of the controller capability data, to the agent computing device 704. Upon receiving S-701-rqst, the agent computing device 704 may invoke a thread A7-1, which may generate and send an agent response message S-107-rsp, which is an agent response acknowledging the controller request message S-701-rqst.

[0134] Also, upon receiving the controller request message S-701-rqst, the agent computing device 704 may perform one or more initialization operations, such as selecting compatible features and setting the state of the connection, as well as one or more operations related to determining the common features, as described above by way of example. Also, as described above, the controller computing device 702 may perform one or more initialization and / or state setting operations, such as informing other application programs that may be running on the controller computing device of the features. Similar processes may be performed on the agent computing device, or at least the controller computing device may assume their execution in conventional operation. However, the controller computing device 702 may not necessarily be able to determine the feature synchronization state of itself and the agent computing device from a single request-response instance 721 alone.

[0135] Continuing with the example of FIG. 7, the controller computing device 702 then determines through successive polling attempts whether the agent computing device 704 has been successful in determining compatible capabilities and in transitioning to the corresponding state. Thus, in instance 723, the poll may include a controller request for status, a controller request message S-703-rqst, followed by an agent response, an agent response message S-703-rsp, that acknowledges the controller request message S-703-rqst with only an indication that action in response to the request is pending, for example. A second poll may include another controller request for status, a controller request message S-705-rqst, followed by another agent response, an agent response message S-705-rsp, that acknowledges the controller request message S-705-rqst, but that may also only indicate that action in response to the request is pending. In this example, after a final Controller request message S-707-rqst to poll for status, the agent computing device responds with an Agent response message S-707-rsp confirming the Agent request message S-707-rqst with an indication that the action is completed and / or status update information.

[0136] This polling approach can be inefficient and / or incur significant delays. In some cases, polling can continue indefinitely or for more than a few cycles. This is indicated in Fig. 7 by the vertical ellipses between the polling instances. One of the main causes of the drawbacks of the conventional approach is the statelessness of the individual instances of the request-response communication protocol and its application to procedures that are transactional in nature. By nesting the request-response instances, statefulness can be introduced into the request-response protocol, thus naturally and efficiently supporting transactions of function coordination, while at the same time preserving existing communication protocols already applied to machine-to-machine communication of distributed applications.

[0137] D. Nesting for enhanced behavior Figure 8 illustrates an example of nested request-response protocol communication between two exemplary devices, according to an exemplary embodiment. Similar to the illustration of Figure 7, the exemplary operation of Figure 8 illustrates a message flow diagram between a controller computing device 802 and an agent computing device 804. The basic format of Figure 8 is the same as Figure 7, with messages represented by horizontal arrows between the controller computing devices 802 and 804, and time flowing downward in the diagram.

[0138] In the example shown in Figure 8, the basic flow of communication includes only two instances of the request-response message pair, with one instance pair 823 nested within another instance pair 821. The two instances of the request-response message pair may be executed largely simultaneously by respective threads of execution on two computing devices. Specifically, instance 821 is shown as being executed by thread C8-1 on the controller computing device 802 and thread A8-1 on the agent computing device 804. In a nested operation, instance 823 is shown as being executed within instance 821 by thread C8-2 on the controller computing device 702 and thread A8-2 on the agent computing device 804.

[0139] In the illustrated example, at instance 821, the controller computing device 802 sends a controller request message S-801-rqst, which is a controller request including at least a portion of the controller capability data, to the agent computing device 804. Upon receipt of S-801-rqst, the agent computing device 804 may invoke a thread A8-1. This thread may perform one or more initialization operations, such as selecting compatible capabilities and setting the state of a connection, as well as one or more operations related to determining the capabilities of the intersection, as described above by way of example. Additionally, thread C8-1 running on the controller computing device 802 may perform one or more initialization and / or state setting operations.

[0140] In contrast to conventional operation, the agent computing device 804 does not immediately send a response to the controller request message S-801-rqst, but instead invokes thread A8-2 simultaneously (e.g., runs in parallel) with thread A8-1. Thread A8-2 may then determine compatibility data, such as compatibility capability data 605 shown in FIG. 6, in step S-803. Thread A8-2 then sends an agent request message S-805-rqst. According to an exemplary embodiment, when the agent request message S-805-rqst is sent while a response to the controller request message S-801-rqst is pending, the agent request message S-805-rqst is effectively nested, which ultimately becomes the request-response pair initiated by the controller request message S-801-rqst. In this manner, state is maintained in both the controller computing device 802 and the agent computing device 804 for the duration.

[0141] The initiation of a second request-response pair with an agent request message S-805-rqst also corresponds to the establishment of an instance pair 823, which is nested in instance pair 821 as described above.

[0142] Upon receiving the agent request message S-805-rqst, the controller computer equipment 802 may invoke a thread C8-2. This thread may synchronize its capabilities with the capabilities of the agent computer equipment 804 reported in the agent request message S-805-rqst by performing one or more operations S-807. The thread C8-2 may then acknowledge the agent request message S-805-rqst by sending a controller response message S-805-rsp to the agent computer equipment 804, thereby acknowledging the synchronization by the controller computer equipment 802 and terminating the instance 823 and the threads A8-2 and C8-2 of the agent computer equipment 804 and the controller computer equipment 802, respectively.

[0143] The agent computer device receiving the controller response message S-805-rsp may then send an agent response message S-801-rsp as an acknowledgement to the controller request message S-801-rqst, thereby acknowledging synchronization by the agent computer device 804 and terminating the instance 821 and threads A8-1 and C8-1 of the agent computer device 804 and the controller computer device 802, respectively.

[0144] The two-threaded implementation of each of the controller computing device 802 and the agent computing device 804 is one possible example and is not intended to be limiting, as other implementations (e.g., single thread) are possible as well. In the illustrated example, the thread A8-1 may block operations such as returning a response to the controller request message S-801-rqst and / or performing other initialization operations. In other embodiments, the operations of the threads A8-1 and A8-2 may be performed by a single thread.

[0145] According to an exemplary embodiment, this nesting approach keeps the first connection established by instance 821 between the controller computing equipment 802 and the agent computing equipment 804 open as long as the second connection established by instance 823 is open. This effectively introduces statefulness throughout the duration of both instances, and the reconciliation of functions can be performed in a single complete transaction. Note that the result of the reconciliation does not necessarily have to be successful synchronization and / or realization of compatible functions. For example, one or the other (or both) of the controller computing equipment 802 and the agent computing equipment 804 may not be able to achieve the functional synchronization state for some reason. However, since the entire procedure is performed within a stateful transaction, any such error condition may be detected as part of the completed transaction, at which point an action related to the failure or error condition may be invoked. However, attempts by the computing equipment to proceed as if the error had not occurred may be avoided or prevented.

[0146] For computer machines or systems that communicate using request-response protocols to execute distributed application programs and / or other forms of multi-component application programs that are configured to operate across two or more computer machines, the nesting techniques described herein, by way of example, allow stateful transactions for the operations required. Coordination of functions as illustrated herein is one example of such operations. Given the widespread deployment of distributed application programs and systems, coupled with the near-ubiquitous use of RESTful protocols (e.g., HTTP) for inter-machine communication in support of distributed applications, the adaptation of these communication protocols to handle stateful transactions provides benefits and advantages both in terms of versatility and flexibility of functionality and practicality and feasibility of implementation and deployment.

[0147] VI. Exemplary Operations Figure 9 is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 9 may be performed by one or more computing devices, such as computing device 100, and / or clusters of computing devices, such as server cluster 200. However, the process may also be performed by other types of devices or device subsystems. For example, the process may be performed by a computing instance of a remote network management platform or a portable computer, such as a laptop or tablet device.

[0148] According to an exemplary embodiment, the exemplary method may be embodied as computer readable instructions stored on a computer readable medium, such as a semiconductor memory, an optical and / or magnetic disk, or other tangible product. In some cases and / or embodiments, the computer readable medium may be non-transitory. The computer readable medium may be adapted to store computer readable instructions in a manner suitable for transport and introduction to one or more computing devices. Additionally or alternatively, the computer readable medium may be accessible (e.g., as an internal memory) by one or more processors of the one or more computing devices to access the instructions and perform operations accordingly. The computer readable instructions, when executed by one or more processors of the one or more computing devices, may cause the one or more computing devices to perform operations of the exemplary method. Thus, one or more computing devices may be considered to be configured to perform the exemplary method.

[0149] The embodiments of Figure 9 may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or described herein.

[0150] According to an exemplary embodiment, in the exemplary method illustrated in Figure 9, a controller computing device may be communicatively coupled to an agent computing device, which may be coupled, for example, via a network or other communications system.

[0151] At block 902, the exemplary method may include sending a controller request from the controller computing device to the agent computing device over a first instance of a request-response protocol. The controller request may include controller data representing capabilities of the controller computing device. An illustrative and non-limiting example of the controller data is the controller capabilities data 601 shown in FIG. 6.

[0152] At block 904, the example method may include receiving an agent request at the controller computing device over a second instance of the request-response protocol from the agent computing device after sending the controller request. The agent request may include agent data representative of capabilities of the agent computing device.

[0153] At block 906, the exemplary method may include storing at least a portion of the agent data in a memory of the controller computing device. One illustrative and non-limiting example of agent data is agent capabilities data 603, also shown in FIG.

[0154] At block 908, the example method may include transmitting a controller response to the agent request from the controller computing device over a second instance of the request-response protocol to the agent computing device. The controller response may follow the request-response protocol because it is considered an acknowledgement of receipt of the agent request.

[0155] Finally, at block 910, the example method may include, after transmitting the controller response, receiving an agent response from the agent computing device over a first instance of a request-response protocol at the controller computing device, which may also follow the request-response protocol because the agent response is considered an acknowledgement of receipt of the controller request.

[0156] According to an exemplary embodiment, the exemplary method may further include receiving the controller request at the agent computing device and storing at least a portion of the controller data in a memory of the agent computing device. Another operation of the exemplary method may further include, in response to receiving the controller request, the agent computing device determining a subset of the capabilities of the agent computing device that are compatible and / or synchronous with the capabilities of the controller computing device, and sending an agent request from the agent computing device to the controller computing device over a second instance of the request-response protocol. The agent request may further include an indication of the determined subset of the capabilities of the agent computing device. One illustrative and non-limiting example of a subset of the capabilities of the agent computing device that are compatible and / or synchronous with the capabilities of the controller computing device is a subset of the agent capabilities data in the compatibility capabilities data 605 shown in FIG. 6.

[0157] Further, according to an exemplary embodiment, at least a portion of the agent data stored in the memory of the controller computing device may include data associated with the determined subset of the capabilities of the agent computing device. Similarly, at least a portion of the controller data stored in the memory of the agent computing device may include data associated with a subset of the capabilities of the controller computing device that corresponds to the subset of the capabilities of the agent computing device. One illustrative and non-limiting example of a subset of the capabilities of the controller computing device that corresponds to the subset of the capabilities of the agent computing device is the subset of the controller capabilities data in the compatibility capabilities data 605 shown in FIG. 6.

[0158] According to an example embodiment, the example method may further include the controller computing device synchronizing a corresponding subset of the capabilities of the controller computing device with the subset of the capabilities of the agent computing device, the synchronization being based on an indication in the agent request.

[0159] According to an exemplary embodiment, the exemplary method may further include receiving the controller response at the agent computing device, and after receiving the controller response at the agent computing device, transmitting the agent response from the agent computing device to the controller computing device over a first instance of the request-response protocol.

[0160] According to an exemplary embodiment, the exemplary method may further include the controller computing device executing, on a first controller execution thread, operations of a first instance of a request-response protocol and on a second controller execution thread, operations of a second instance of the request-response protocol. Similarly, the exemplary method may further include the agent computing device executing, on a first agent execution thread, operations of the first instance of the request-response protocol and on a second agent execution thread, operations of the second instance of the request-response protocol.

[0161] According to an example embodiment, the request-response protocol may be a communication protocol that conforms to and / or is modeled on Representational State Transfer (REST). One non-limiting example of such a protocol is HTTP.

[0162] VII. Conclusion The present disclosure is not limited in terms of the specific embodiments described herein, which are intended to illustrate various aspects. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope thereof. From the foregoing description, functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those described herein, will be apparent to those skilled in the art. Such modifications and variations are also intended to fall within the scope of the appended claims.

[0163] In the above detailed description, various features and operations of the disclosed system, apparatus, and method are described with reference to the accompanying drawings. The exemplary embodiments described herein and in the drawings are not meant to be limiting in any way. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0164] With respect to any or all of the message flow diagrams, scenarios, and flowcharts in the figures, each step, block, and / or communication may represent information processing and / or information transmission according to an exemplary embodiment, as discussed herein. The scope of these exemplary embodiments includes alternative embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of the order shown or described (including substantially simultaneously or in reverse order), depending on the functionality involved. Furthermore, any of the message flow diagrams, scenarios, and flowcharts discussed herein may use more or fewer blocks and / or operations, and some or all of these message flow diagrams, scenarios, and flowcharts may be combined with each other.

[0165] The steps or blocks representing the processing of information may correspond to circuitry that may be configured to perform certain logical functions of the methods or techniques described herein. Alternatively or additionally, the steps or blocks representing the processing of information may correspond to modules, segments, or portions of program code (including associated data). The program code may include one or more instructions executable by a processor to perform certain logical operations or actions in the methods or techniques. The program code and / or associated data may be stored in any type of computer-readable medium, such as a storage device, including a RAM, a disk drive, a solid-state drive, or another storage medium.

[0166] Computer readable media may also include non-transitory computer readable media, such as non-transitory computer readable media that store data for a short period of time, such as register memory and processor cache. Non-transitory computer readable media may further include non-transitory computer readable media that store program code and / or data for a long period of time. Thus, non-transitory computer readable media may include secondary or permanent long-term storage, such as, for example, ROM, optical or magnetic disks, solid-state drives, or compact disk read-only memories (CD-ROMs). Non-transitory computer readable media may also be any other volatile or non-volatile storage system. Non-transitory computer readable media may be considered, for example, computer readable storage media or tangible storage devices.

[0167] Furthermore, steps or blocks depicting one or more information transfers may correspond to information transfers between software and / or hardware modules in the same physical device, although other information transfers are possible between software and / or hardware modules in different physical devices.

[0168] The particular arrangement depicted in the figures should not be construed as limiting in any way. It is understood that other embodiments may show more or fewer elements in a given figure. Further, some of the depicted elements may be combined or omitted. Additionally, an example embodiment may include elements that are not shown in the figures.

[0169] Various aspects and embodiments are disclosed herein, and other aspects and embodiments will be apparent to those of ordinary skill in the art. The various aspects and embodiments disclosed herein are intended to be illustrative and not limiting, with the true scope being indicated by the following claims.

Claims

1. A controller computing device, comprising: a memory containing controller data representative of the functionality of said controller computing device; sending a controller request to an agent computing device over a first instance of a request-response protocol, said controller request including said controller data; receiving an agent request from the agent computing device over a second instance of the request-response protocol after sending the controller request, the agent request including agent data indicative of capabilities of the agent computing device; storing at least a portion of said agent data in said memory; transmitting a controller response to the agent request to the agent computing device over the second instance of the request-response protocol, the controller response confirming receipt of the agent request; receiving an agent response from the agent computing device over the first instance of the request-response protocol after transmitting the controller response, the agent response confirming receipt of the controller request; one or more processors configured to: A controller computer device comprising:

2. the one or more processors: establishing a first thread of execution for operations related to sending the controller request and receiving the agent response; establishing a second thread of execution for operations related to receiving the agent request and transmitting the controller response; The controller computing device of claim 1 , further configured to:

3. the controller request further includes an indication of execution by the agent controller device of an agent action associated with the controller data; 2. The controller computer device of claim 1, wherein said agent request further includes a status of said agent action.

4. 2. The controller device of claim 1, wherein the controller request is configured to cause the agent controller device to determine a subset of the capabilities of the agent computing device that are compatible and / or synchronous with the capabilities of the controller computing device.

5. 2. The controller computing device of claim 1, wherein said agent request further includes an indication of a subset of said capabilities of said agent computing device that are compatible and / or synchronous with said capabilities of said controller computing device.

6. The controller computing device of claim 5 , wherein the at least a portion of the agent data stored in the memory includes data associated with the subset of the capabilities of the agent computing device.

7. the one or more processors:

6. The controller device of claim 5, further configured to synchronize and / or make compatible the corresponding subset of capabilities of the controller computer device with the subset of capabilities of the agent computer device based on the indication in the agent request.

8. 1. An agent computing device, comprising: a memory containing agent data representative of the capabilities of said agent computing device; receiving a controller request over a first instance of a request-response protocol from a controller computing device, the controller request including controller data indicative of a capability of the controller computing device; storing at least a portion of the controller data in the memory; sending an agent request to the controller computing device over a second instance of the request-response protocol after receiving the controller request, the agent request including at least a portion of the agent data; receiving, from the controller computing device, a controller response to the agent request over the second instance of the request-response protocol, the controller response confirming receipt of the agent request; and after receiving the controller response, sending an agent response to the controller computing device over the first instance of the request-response protocol, the agent response confirming receipt of the controller request; one or more processors configured to: An agent computer device comprising:

9. the one or more processors: establishing a first thread of execution for operations related to receiving said controller request and transmitting said agent response; establishing a second thread of execution for operations related to sending the agent request and receiving the controller response; 9. The agent computing device of claim 8, further configured to:

10. the controller request further includes instructions for performance by the agent controller device of an agent action associated with the controller data; the one or more processors are further configured to execute the agent actions; 9. The agent computing device of claim 8, wherein the agent request further includes a status of the agent action.

11. 9. The agent computer device of claim 8, wherein the controller request is configured to cause the agent controller device to determine a subset of the capabilities of the agent computer device that are compatible and / or synchronous with the capabilities of the controller computer device.

12. 9. The agent computer device of claim 8, wherein said agent request further includes an indication of a subset of said capabilities of said agent computer device that are compatible and / or synchronous with said capabilities of said controller computer device.

13. 13. The agent computing device of claim 12, wherein the at least some of the controller data stored in the memory includes data associated with a subset of the functions of the controller computing device that correspond to the subset of the functions of the agent computing device.

14. 13. The agent computer device of claim 12, wherein the indication in the agent request is configured to cause the controller computer device to synchronize and / or make compatible a corresponding subset of the capabilities of the controller computer device with the subset of capabilities of the agent computer device.

15. sending, from a controller computing device, a controller request over a first instance of a request-response protocol to an agent computing device, said controller request including controller data representative of capabilities of said controller computing device; receiving, at the controller computing device, an agent request on a second instance of the request-response protocol from the agent computing device after sending the controller request, the agent request including agent data indicative of capabilities of the agent computing device; storing at least a portion of said agent data in a memory of said controller computing device; transmitting, from the controller computing device, a controller response to the agent request over the second instance of the request-response protocol to the agent computing device, the controller response confirming receipt of the agent request; receiving, at the controller computing device, an agent response over the first instance of the request-response protocol from the agent computing device after transmitting the controller response, the agent response confirming receipt of the controller request; A method comprising:

16. receiving the controller request at the agent computing device; storing at least a portion of said controller data in a memory of said agent computing device; in response to receiving the controller request, the agent computing device determining a subset of capabilities of the agent computing device that are compatible and / or synchronous with the capabilities of the controller computing device; sending, from the agent computing device, the agent request over the second instance of the request-response protocol to the controller computing device; Further comprising:

16. The method of claim 15, wherein the agent request further includes an indication of the determined subset of the capabilities of the agent computing device.

17. the at least some of the agent data stored in the memory of the controller computing device includes data associated with the determined subset of the capabilities of the agent computing device; the at least some of the controller data stored in the memory of the agent computing device includes data associated with a subset of the functions of the controller computing device that corresponds to the subset of the functions of the agent computing device; The method further comprising:

17. The method of claim 16, further comprising: the controller computing device synchronizing the corresponding subset of the capabilities of the controller computing device with the subset of the capabilities of the agent computing device based on the indication in the agent request.

18. receiving the controller response at the agent computing device; after receiving the controller response at the agent computing device, transmitting from the agent computing device, the agent response to the controller computing device over the first instance of the request-response protocol; The method of claim 15 further comprising:

19. said controller computing device executing, on a first controller execution thread, operations of said first instance of said request-response protocol and, on a second controller execution thread, operations of said second instance of said request-response protocol; said agent computing device executing, on a first agent execution thread, operations of said first instance of said request-response protocol and, on a second agent execution thread, operations of said second instance of said request-response protocol; The method of claim 15 further comprising:

20. 16. The method of claim 15, wherein the request-response protocol comprises a communications protocol that conforms to and / or is modeled on Representational State Transfer (REST).

Images