Abstract:
According to one aspect of the present disclosure, a method and technique for facilitating the exchange of information between interconnected computing entities is disclosed. The method includes: receiving from a client, by a workload manager, a workload unit of data in need of processing by the client; initiating by the workload manager a persistent storage of the workload unit of data received from the client; without waiting for the initiated storage of the workload unit of data to complete, sending by the workload manager the workload unit of data to a plurality of compute nodes; and responsive to receiving a result of a processing of the workload unit of data by one of the plurality compute nodes, canceling processing by the workload manager of the workload unit of data by a remainder of the plurality of compute nodes.

Description:
TECHNICAL FIELD 
     The present disclosure generally relates to methods and systems for facilitating the exchange of information between communicating entities and specifically relates to methods and systems for facilitating the exchange of information between interconnected processors in environments requiring high performance and high reliability, such as distributed computing environments and message-oriented middleware environments. 
     BACKGROUND 
     Users of distributed computing environments, message-oriented middleware environments, and other computer processes wherein information is exchanged between communicating entities continue to demand higher performance without sacrificing process reliability. For example, a user of a distributed computing environment, wherein a client sends out workload and expects results, may require a 5 ms or less round trip workload latency in an environment with thousands of compute nodes and clients. In the traditional store-and-forward approach, a server receives the client&#39;s workload and forwards the workload to compute nodes in the distributed computing environment. But before forwarding the workload, the server stores the workload in nonvolatile memory and sends an acknowledgement to the client. User performance requirements, however, are often unattainable with the traditional store-and-forward approach because the total system performance can never exceed the maximum performance of the storage operation. Because the storage operation is often the lowest performing operation in the system, a new approach is needed to meet higher performance and reliability requirements. 
     BRIEF SUMMARY 
     Disclosed herein are embodiments of a method and system for facilitating the exchange of information between interconnected processors, specifically a source and a target, in environments requiring high performance and high reliability, such as distributed computing environments and message-oriented middleware environments. In an exemplary embodiment, the source sends input to the target and expects output from the target in return. A manager in communication with both the source and the target receives the input from the source and initiates a storage of the input in nonvolatile memory. Rather than wait for completion of the initiated storage, the manager concurrently forwards the input to the target. If the manager receives output from the target before completion of the input storage, the manager cancels the input storage because it is no longer needed to ensure system reliability. Upon receiving output from the target, the manager initiates a storage of the output in nonvolatile memory. Rather than wait for completion of the initiated storage, the manager concurrently forwards the output to the source. If the manager receives acknowledgement from the source that the target output has been received before completion of the output storage, the manager cancels the output storage because it is no longer needed to ensure system reliability. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram depicting a prior art system for facilitating the exchange of information between communicating entities; 
         FIG. 2  is an activity diagram depicting a prior art process for facilitating the exchange of information between communicating entities; 
         FIG. 3  is a block diagram depicting a representative system for facilitating the exchange of information between communicating entities utilizing an asynchronous persistent store protocol; 
         FIG. 4  is an activity diagram depicting a representative process for facilitating the exchange of information between communicating entities utilizing an asynchronous persistent store protocol; 
         FIG. 5  is a block diagram depicting a representative system for facilitating the exchange of information between a client and multiple compute nodes in a distributed computing environment utilizing an asynchronous persistent store protocol. 
     
    
    
     DETAILED DESCRIPTION 
     Various aspects of a method and system for facilitating the exchange of information between communicating entities utilizing an asynchronous persistent store protocol according to the present disclosure are described. It is to be understood, however, that the following explanation is merely exemplary in describing aspects of the present disclosure. 
       FIG. 1  is a block diagram depicting a prior art system for facilitating the exchange of information between a source and a target, wherein the source sends input to the target and expects output from the target in return. In this system, source  100  communicates with target  190  over a communications pathway, such as an electrical circuit or a telecommunications network. Source  100  sends input  110  to target  190  and expects output  170  from target  190  in return. Manager  115 , in communication with both source  100  and target  190 , receives input  110  from source  100 . To ensure reliability should manager  115  experience a failure during the communication cycle, manager  115  stores input  120  received from source  100  in persistent store  125 . Once the input has been reliably stored, manager  115  acknowledges  130  to source  100  that the input has been received. Should manager  115  experience a failure at this point, manager  115  can retrieve the stored input from persistent store  125  and continue the process in a manner that is transparent to source  100 . 
     After storing the input received from source  100 , manager  115  forwards input  140  to target  190 . Once target  190  has received the input and performed any required processing, manager  115  receives output  150  from target  190 . To ensure reliability should manager  115  experience a failure during the communication cycle, manager  115  stores output  160  received from target  190  in persistent store  125 . Once the output has been reliably stored, should manager  115  experience a failure, manager  115  can retrieve the stored output from persistent store  125  and continue the process in a manner that is transparent to both source  100  and target  190 . After storing the output received from target  190 , manager  115  forwards output  170  to source  100 . Once manager  115  receives acknowledgement  180  from source  100  that source  100  has received the target output, the communications cycle is complete. 
       FIG. 2  is an activity diagram depicting a prior art process for facilitating the exchange of information between a source and a target, wherein the source sends input to the target and expects output from the target in return. In this process, a manager in communication with both the source and the target receives  210  input from the source. To ensure reliability should the manager experience a failure during the communication cycle, the manager stores  220  the input received from the source in nonvolatile memory. Once the input has been reliably stored, the manager acknowledges  230  to the source that the input has been received. Should the manager experience a failure at this point, the manager can retrieve the stored input and continue the process in a manner that is transparent to the source. 
     After storing the input received from the source, the manager forwards  240  the input to the target. Once the target has received the input and performed any required processing, the manager receives  250  output from the target. To ensure reliability should the manager experience a failure during the communication cycle, the manager stores  260  the output received from the target in nonvolatile memory. Once the output has been reliably stored, should the manager experience a failure, the manager can retrieve the stored output and continue the process in a manner that is transparent to both the source and the target. After storing the output received from the target, the manager forwards  270  the output to the source. Once the manager receives acknowledgement  280  from the source that the source has received the target output, the communications cycle is complete and the manager waits  290  for further input from the source. 
       FIG. 3  is a block diagram depicting a new system for facilitating the exchange of information between a source and a target, wherein the source sends input to the target and expects output from the target in return. In this embodiment, source  300  communicates with target  390  over a communications pathway, such as an electrical circuit or a telecommunications network. Source  300  sends input  310  to target  390  and expects output  370  from target  390  in return. Manager  315 , in communication with both source  300  and target  390 , receives input  310  from source  300 . To ensure reliability should manager  315  or source  300  experience a failure during the communication cycle, manager  315  initiates a storage  320  of the input received from source  300  in persistent store  325 . Rather than wait for completion of the initiated input storage, manager  315  immediately forwards input  340  to target  390 . Alternatively, manager  315  may forward input  340  simultaneously with initiating the storage  320  or manager  315  may forward input  340  before initiating the storage  320 . 
     In this embodiment, once target  390  has received the input and performed any required processing, manager  315  receives output  350  from target  390 . To ensure reliability should manager  315  or source  300  experience a failure during the communication cycle, manager  315  initiates a storage  360  of the output received from target  390  in persistent store  325 . Rather than wait for completion of the initiated output storage, manager  315  immediately forwards output  370  to source  300 . Alternatively, manager  315  may forward output  370  simultaneously with initiating the storage  360  or manager  315  may forward output  370  before initiating the storage  360 . Once manager  315  receives acknowledgement  380  from source  300  that source  300  has received the target output, the communications cycle is complete. 
     In an alternative embodiment not depicted in  FIG. 3 , once target  390  has received the input and performed any required processing, source  300  receives output  350  from target  390 . 
     When previously initiated input storage  320  completes and the input has been reliably stored, manager  315  acknowledges  330  to source  300  that the input has been received. Should source  300  experience a failure at this point, source  300  need not resend input  310  after recovery and manager  315  can continue the process despite the failure of source  300 . Should manager  315  experience a failure at this point, manager  315  can retrieve the stored input from persistent store  325  and continue the process in a manner that is transparent to source  300 . Reception of output  350  from target  390  before completion of the previously initiated input storage  320  obviates the need for storage of the input; consequently, manager  315  in this instance can abort  355  the input storage. 
     When previously initiated output storage  360  completes and the output has been reliably stored, should manager  315  experience a failure, manager  315  can retrieve the stored output from persistent store  325  and continue the process in a manner that is transparent to both source  300  and target  390 . Should source  300  experience a failure after receiving output  370  but before sending output acknowledgement  380 , manager  315  can again provide output  370  to source  300  by either retrieving the stored output from persistent store  325  or by resending input  340  to target  390 . Reception of output acknowledgement  380  from source  300  before completion of the previously initiated output storage  360  obviates the need for storage of the output; consequently, manager  315  in this instance can abort  385  the output storage. 
     One embodiment of the system described by  FIG. 3  takes place in a message-oriented middleware environment. In this embodiment, source  300  is a requesting client, target  390  is a responding client, manager  315  is a message transfer agent, input  310  is a request, and output  350  is a response. Requesting client  300  communicates with responding client  390  over a telecommunications network such as the Internet or a local area network. Requesting client  300  sends request  310  to responding client  390  and expects response  370  from responding client  390  in return. Message transfer agent  315 , in communication with both requesting client  300  and responding client  390 , receives request  310  from requesting client  300 . To ensure reliability should message transfer agent  315  or requesting client  300  experience a failure during the communication cycle, message transfer agent  315  initiates a storage  320  of the request received from requesting client  300  in persistent store  325 . Rather than wait for completion of the initiated request storage, message transfer agent  315  immediately forwards request  340  to responding client  390 . Alternatively, message transfer agent  315  may forward request  340  simultaneously with initiating the storage  320  or message transfer agent  315  may forward request  340  before initiating the storage  320 . 
     Message transfer agent  315  then receives response  350  from responding client  390 . To ensure reliability should message transfer agent  315  or requesting client  300  experience a failure during the communication cycle, message transfer agent  315  initiates a storage  360  of the response received from responding client  390  in persistent store  325 . Rather than wait for completion of the initiated response storage, message transfer agent  315  immediately forwards response  370  to requesting client  300 . Alternatively, message transfer agent  315  may forward response  370  simultaneously with initiating the storage  360  or message transfer agent  315  may forward output  370  before initiating the storage  360 . Once message transfer agent  315  receives acknowledgement  380  from requesting client  300  that requesting client  300  has received the responding client response, the communications cycle is complete. 
     When previously initiated request storage  320  completes and the request has been reliably stored, message transfer agent  315  acknowledges  330  to requesting client  300  that the request has been received. Should requesting client  300  experience a failure at this point, requesting client  300  need not resend request  310  after recovery and message transfer agent  315  can continue the process despite the failure of requesting client  300 . Should message transfer agent  315  experience a failure at this point, message transfer agent  315  can retrieve the stored request from persistent store  325  and continue the process in a manner that is transparent to requesting client  300 . Reception of response  350  from responding client  390  before completion of the previously initiated request storage  320  obviates the need for storage of the request; consequently, message transfer agent  315  in this instance can abort  355  the request storage. 
     When previously initiated response storage  360  completes and the response has been reliably stored, should message transfer agent  315  experience a failure, message transfer agent  315  can retrieve the stored response from persistent store  325  and continue the process in a manner that is transparent to both requesting client  300  and responding client  390 . Should requesting client  300  experience a failure after receiving response  370  but before sending response acknowledgement  380 , message transfer agent  315  can again provide response  370  to requesting client  300  by either retrieving the stored response from persistent store  325  or by resending request  340  to responding client  390 . Reception of response acknowledgement  380  from requesting client  300  before completion of the previously initiated response storage  360  obviates the need for storage of the response; consequently, message transfer agent  315  in this instance can abort  385  the response storage. 
     Another embodiment of the system described by  FIG. 3  takes place in a distributed computing environment. In this embodiment, source  300  is a client, target  390  is a compute node, manager  315  is a workload manager, input  310  is a workload unit, and output  350  is a result. Client  300  communicates with compute node  390  over a telecommunications network such as the Internet or a local area network. Client  300  sends workload unit  310  to compute node  390  and expects result  370  from compute node  390  in return. Workload manager  315 , in communication with both client  300  and compute node  390 , receives workload unit  310  from client  300 . To ensure reliability should workload manager  315  or client  300  experience a failure during the communication cycle, workload manager  315  initiates a storage  320  of the workload unit received from client  300  in persistent store  325 . Rather than wait for completion of the initiated workload unit storage, workload manager  315  immediately forwards workload unit  340  to compute node  390 . Alternatively, workload manager  315  may forward workload unit  340  simultaneously with initiating the storage  320  or workload manager  315  may forward workload unit  340  before initiating the storage  320 . 
     In this embodiment, workload manager  315  then receives result  350  from compute node  390 . To ensure reliability should workload manager  315  or client  300  experience a failure during the communication cycle, workload manager  315  initiates a storage  360  of the result received from compute node  390  in persistent store  325 . Rather than wait for completion of the initiated result storage, workload manager  315  immediately forwards result  370  to client  300 . Alternatively, workload manager  315  may forward result  370  simultaneously with initiating the storage  360  or workload manager  315  may forward result  370  before initiating the storage  360 . Once workload manager  315  receives acknowledgement  380  from client  300  that client  300  has received the compute node result, the communications cycle is complete. 
     In an alternative embodiment not depicted in  FIG. 3 , client  300  receives result  350  from compute node  390 . 
     When previously initiated workload unit storage  320  completes and the workload unit has been reliably stored, workload manager  315  acknowledges  330  to client  300  that the workload unit has been received. Should client  300  experience a failure at this point, client  300  need not resend workload unit  310  after recovery and workload manager  315  can continue the process despite the failure of client  300 . Should workload manager  315  experience a failure at this point, workload manager  315  can retrieve the stored workload unit from persistent store  325  and continue the process in a manner that is transparent to client  300 . Reception of result  350  from compute node  390  before completion of the previously initiated workload unit storage  320  obviates the need for storage of the workload unit; consequently, workload manager  315  in this instance can abort  355  the workload unit storage. 
     When previously initiated result storage  360  completes and the result has been reliably stored, should workload manager  315  experience a failure, workload manager  315  can retrieve the stored result from persistent store  325  and continue the process in a manner that is transparent to both client  300  and compute node  390 . Should client  300  experience a failure after receiving result  370  but before sending result acknowledgement  380 , workload manager  315  can again provide result  370  to client  300  by either retrieving the stored result from persistent store  325  or by resending workload unit  340  to compute node  390 . Reception of result acknowledgement  380  from client  300  before completion of the previously initiated result storage  360  obviates the need for storage of the result; consequently, workload manager  315  in this instance can abort  385  the result storage. 
       FIG. 4  is an activity diagram depicting a new process for facilitating the exchange of information between a source and a target, wherein the source sends input to the target and expects output from the target in return. In this exemplary embodiment, a manager in communication with both the source and the target receives  410  input from the source. To ensure reliability should the manager or the source experience a failure during the communication cycle, the manager initiates  420  a storage in nonvolatile memory of the input received from the source. Rather than wait for completion of the initiated input storage, the manager immediately forwards  440  the input to the target. Alternatively, the manager may forward  440  the input simultaneously with initiating  420  the storage or the manager may forward  440  the input before initiating  420  the storage. 
     In this embodiment, once the target has received the input and performed any required processing, the manager receives  450  output from the target. To ensure reliability should the manager or the source experience a failure during the communication cycle, the manager initiates  460  a storage in nonvolatile memory of the output received from the target. Rather than wait for completion of the initiated output storage, the manager immediately forwards  470  the output to the source. Alternatively, the manager may forward  470  the output simultaneously with initiating  460  the storage or the manager may forward  470  the output before initiating  460  the storage. Once the manager receives acknowledgement  480  from the source that the source has received the target output, the communications cycle is complete and the manager waits  490  for further input from the source. 
     In an alternative embodiment not depicted in  FIG. 4 , once the target has received the input and performed any required processing, the source receives output from the target. 
     When the input storage previously initiated  420  completes  425  and the input has been reliably stored, the manager acknowledges  430  to the source that the input has been received. Should the source experience a failure at this point, the source need not resend the input after recovery and the manager can continue the process despite the failure of the source. Should the manager experience a failure at this point, the manager can retrieve the stored input and continue the process in a manner that is transparent to the source. Reception  450  of the output from the target before completion of the input storage previously initiated  420  obviates the need for storage of the input; consequently, the manager in this instance can abort  455  the input storage. 
     When the output storage previously initiated  460  completes  465  and the output has been reliably stored, should the manager experience a failure, the manager can retrieve the stored output and continue the process in a manner that is transparent to both the source and the target. Should the source experience a failure after receiving the output but before sending the output acknowledgement, the manager can again provide the output to the source by either retrieving the stored output from the persistent store or by resending the input to the target. Reception  480  of the output acknowledgement from the source before completion of the output storage previously initiated  460  obviates the need for storage of the output; consequently, the manager in this instance can abort  485  the output storage. 
     A preferred embodiment of the present disclosure is shown in  FIG. 5 , which is a block diagram depicting a representative system for facilitating the exchange of information between client  500  and multiple compute nodes  590   a - 590   n  in a distributed computing environment. In this system, client  500  comprises a client Software Development Kit (SDK)  505 . Client  500  communicates through client SDK  505  with multiple compute nodes  590   a - 590   n  over a telecommunications network such as the Internet or a local area network. In the distributed computing environment, client  500  sends out workload unit  510  for processing and expects result  570  in return. Workload manager  515 , in communication with both client  500  and multiple compute nodes  590   a - 590   n , receives workload unit  510  from client  500  and determines which compute node or nodes will receive workload unit  510 . This determination may be based on the physical location of the compute nodes, on the availability of the compute nodes, on the capabilities of the compute nodes, or on some other criteria. In some cases only one compute node will be selected to receive workload unit  510 , while in other cases more than one compute node will be selected to receive workload unit  510 . 
     To ensure reliability should workload manager  515  or client  500  experience a failure during the communication cycle, workload manager  515  initiates a storage  520  of the workload unit received from client  500  in persistent store  525 . Rather than wait for completion of the initiated workload unit storage, workload manager  515  immediately forwards workload units  540   a - 540   n , duplicates of workload unit  510 , to selected compute nodes  590   a - 590   n . Alternatively, workload manager  515  may forward workload units  540   a - 540   n  simultaneously with initiating the storage  520  or workload manager  515  may forward workload units  540   a - 540   n  before initiating the storage  520 . Workload manager  515  then receives result  550   a  from compute node  590   a , the first compute node to complete the processing of the workload unit. In some embodiments, once workload manager  515  receives result  550   a  from compute node  590   a , workload manager  515  may cancel processing of the workload unit on the remaining compute nodes. In other embodiments, workload manager  515  may ignore all results received after first result  550   a  is received or take some other action. 
     To ensure reliability should workload manager  515  or client  500  experience a failure during the communication cycle, workload manager  515  initiates a storage  560  of the result received from compute node  590   a  in persistent store  525 . Rather than wait for completion of the initiated result storage, workload manager  515  immediately forwards result  570  to client  500 . Alternatively, workload manager  515  may forward result  570  simultaneously with initiating the storage  560  or workload manager  515  may forward result  570  before initiating the storage  560 . Once workload manager  515  receives acknowledgement  580  from client  500  that client  500  has received the compute node result, the communications cycle is complete. 
     When previously initiated workload unit storage  520  completes and the workload unit has been reliably stored, workload manager  515  acknowledges  530  to client  500  that the workload unit has been received. Should client  500  experience a failure at this point, client  500  need not resend workload unit  510  after recovery and workload manager  515  can continue the process despite the failure of client  500 . Should workload manager  515  experience a failure before persisting the workload unit, client SDK  505  will reconnect to workload manager  515  upon recovery and resend the workload unit to workload manager  515 . Should workload manager  515  experience a failure after persisting the workload unit, workload manager  515  can retrieve the stored workload unit from persistent store  525  and continue the process in a manner that is transparent to client  500 , including resending the workload unit to selected compute nodes  590   a - 590   n  if necessary. Reception of result  550   a  from compute node  590   a  before completion of the previously initiated workload unit storage  520  obviates the need for storage of the workload unit; consequently, workload manager  515  in this instance can abort  555  the workload unit storage. 
     When previously initiated result storage  560  completes and the result has been reliably stored, should workload manager  515  experience a failure, workload manager  515  can retrieve the stored result from persistent store  525  and continue the process in a manner that is transparent to both client  500  and compute nodes  590   a - 590   n . Should client  500  experience a failure after receiving result  570  but before sending result acknowledgement  580 , workload manager  515  can again provide result  570  to client  500  by either retrieving the stored result from persistent store  525  or by resending workload units  540   a - 540   n  to compute nodes  590   a - 590   n . Reception of result acknowledgement  580  from client  500  before completion of the previously initiated result storage  560  obviates the need for storage of the result; consequently, workload manager  515  in this instance can abort  585  the result storage. 
     While various embodiments of a method and system for facilitating the exchange of information between communicating entities utilizing an asynchronous persistent store protocol according to the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. Moreover, the above advantages and features are provided in described embodiments, but shall not limit the application of the claims to processes and structures accomplishing any or all of the above advantages. 
     Additionally, the section headings herein are provided for consistency with the suggestions under 37 CFR  1 . 77  or otherwise to provide organizational cues. These headings shall not limit or characterize the invention(s) set out in any claims that may issue from this disclosure. Specifically and by way of example, although the headings refer to a “Technical Field,” the claims should not be limited by the language chosen under this heading to describe the so-called technical field. Further, a description of a technology in the “Background” is not to be construed as an admission that technology is prior art to any invention(s) in this disclosure. Neither is the “Brief Summary” to be considered as a characterization of the invention(s) set forth in the claims found herein. Furthermore, any reference in this disclosure to “invention” in the singular should not be used to argue that there is only a single point of novelty claimed in this disclosure. Multiple inventions may be set forth according to the limitations of the multiple claims associated with this disclosure, and the claims accordingly define the invention(s), and their equivalents, that are protected thereby. In all instances, the scope of the claims shall be considered on their own merits in light of the specification, but should not be constrained by the headings set forth herein.