RELIABLE REQUEST-RESPONSE MESSAGING OVER A REQUEST-RESPONSE TRANSPORT CROSS-REFERENCE TO RELATED APPLICATIONS [0001] N/A BACKGROUND OF THE INVENTION 1. The Field of the Invention [0002] This invention relates to systems, methods, and computer program products for communicating messages reliably using a request-response transport. 2. Background and Relevant Art [0003] As computerized systems have increased in popularity, so did the needs to distribute files and processing resources of computer systems in networks both large and small. In general, computer systems and related devices communicate information over a network for a variety of reasons, for example, to exchange personal electronic messages, sell merchandise, provide account information, and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with sharing data and resources on a network have also increased. [0004] Generally, there are a number of different mechanisms and protocols for distributing files and resources between two or more computer systems. For example, messages can be sent from one computer system to one or more other computer systems in a manner that does not necessarily require the other computer systems to respond. An example of this might be connectionless protocols, such as might be used with sending electronic mail messages, or streaming certain content to other computers using a user datagram protocol ("UDP"). Other methods for sharing files or resources can include use of connection-oriented protocols, such as those using a transmission control protocol ("TCP"). Connection-oriented communication typically involves establishing a connection through a series of requests and responses, and by sharing certain connection state information. Data sent to and received from the computers usually has some element that associates the transmitted data with the connection. [0005] Connection-oriented communication has a number of advantages that distinguish it from connection-less communication for certain applications. For example, connections initiated using TCP provide a number of functions for ensuring that all the data have been received at one end, as well as a certain amount of error correction. For example, a sending computer can send a packet that indicates it is the first of 20 packets. After the receiving computer receives all 20 packets in the connection session, it submits an acknowledgement (or "ack") to the sending computer system to indicate that all 20 packets were received. In some cases, the receiving computer system may even send an ack for each packet that it has received. In the case of using a reliable messaging ("RM") mechanism, if the sending computer system does not receive an ack for each packet, or an ack for all 20 packets, the sending computer system may send the entire message again, or may even resend individual packets to the receiving computer as necessary. [0006] As such, a number of different framing protocols, such as Hypertext Transfer Protocol ("HTTP") and File Transfer Protocol ("FTP") are each layered on top of connection-oriented transport protocols to take advantage of one or more of these aforementioned attributes. For example, when a client computer uses HTTP to retrieve information, the client computer establishes a TCP connection with the web server and sends an HTTP request for a resource, such as an HTML file or an image, or request that the web server takes a certain action, for example, in the case of online commerce where the client may ask the web server to purchase a song online and send it to the client. The web server receives the request and provides a corresponding response, which may include the contents of the requested file. After receiving the requested files, or when the client computer decides that the communication with the web server is completed, the client computer shuts down the TCP connection. As such, the client does not need to be addressable from the service's standpoint. For example, the client can be behind a Network Address Translation (NAT) server, or utilize an HTTP Proxy to bridge the connection across a firewall. Another benefit is that the requests and the responses are easily correlated - each response correlates to the request that preceded it. [0007] Despite these and other advantages of request-response mechanisms, there is generally no particular way for a requesting or responding computer system to know that the information was transferred successfully. For example, a request may have reached the server, and the server may have produced a response, but the response was lost due to an HTTP Proxy error. Therefore, it is common in a conventional request-response mechanism for the requesting computer system to retransmit the request where no response has been received from the other computer system. For example, conventional web browsers often provide a "refresh" button that can be used to retry the HTTP request when a web page fails to load, In some cases, such as with a simple request for an Internet web page, repeating a seemingly failed request will not ordinarily have a detrimental effect. In other cases, such as with non-idempotent operations, repeating a seemingly failed request, or retransmitting a message that appears not to have been sent properly can have an aggregated effect, which may be detrimental. For example, a client computer might retransmit a money transfer request to a bank server due to no response from the bank server to indicate that the original money transfer was successful. The absence of a response does not necessarily indicate that the request was not received or processed. For example, the request might have been received and processed, but the response was lost due to a temporary network disconnection, or an HTTP Proxy failure. The bank might therefore double the amount of the money transfer upon retrying the request, though this was not intended by the client. [0008] Difficulties such as these can be particularly acute in connections where the responding computer system (e.g., a bank server) cannot communicate directly with the requesting computer system (e.g., client bank customer) to let it know of the status of the request. For example, the client computer system might be communicating anonymously in the connection, or might be behind a firewall, or might be subject to a network address translation ("NAT") service. In cases such as these, typically only the client, or requesting, computer system can initiate the communication. This can create difficulties for the responding computer system (e.g., a network server) in the event where it might be desirable to send receipt acknowledgements and response retransmissions to the requestor. In particular, there is presently no efficient mechanism in conventional request-response protocols for ensuring reliable message transfer between two or more computer systems, particular such that does not aggregate the effect of messages where such an effect should not be aggregated, and that allows messages to be processed only in a particular order as desired. [0009] Accordingly, systems, methods, and computer program products that ensure reliable request-response mechanisms would be an advantage in the art. In particular, an advantage can be realized with request-response mechanisms that allow efficient request and response messages, and corresponding acknowledgements of the same, between a requesting and responding computer system of a network connection. Furthermore, an advantage can be realized with efficient request-response mechanisms that can be implemented whether the address of the requesting computer can be identified, in a connection where the address is difficult or impossible to determine, or and in cases where such address impossible to connect to from the serverBRIEF SUMMARY OF THE INVENTION [0010] The present invention solves one or more of the foregoing problems in the prior art with systems, methods, and computer program products configured to ensure reliable messaging in a request-response environment. In particular, implementations of the present invention relate in part to specific request and response mechanisms that place constraints on a responding computer system to process messages sent by a requesting computer system only in a manner that is intended. [0011] For example, one method from a requesting computer system perspective includes establishing an end-to-end connection with a responding computer system. In one implementation, the end-to-end connection is established with a connection contract that indicates how processing is to occur at the responding computer system. The method also includes sending a first message to the responding computer system, where the first message includes a first identifier. The method from the requesting computer system also includes receiving a response message from the responding computer system. [0012] In addition, when all request and response messages have been appropriately acknowledged, the method from the requesting computer system perspective also includes sending a connection termination message to the responding computer system. In one implementation, the termination message can include a termination message identifier, and an acknowledgement that all the response messages sent by the responding computer system have been received. Thereafter, the end-to-end connection is terminated when the requesting computer system receives a termination response message that relates to the termination message identifier. [0013] By contrast, a method from the responding computer system perspective includes accepting an end-to-end connection with the requesting computer system. In one implementation, this also involves a contract that directs the way in which received messages will be processed. The method from the responding computer system perspective also includes receiving a first message from the requesting computer system, where the first message includes a first identifier. The responding computer system then sends to the requesting computer a response message. [0014] After all the appropriate response messages have been received by the requesting computer system, the responding computer system receives a connection termination message from the requesting computer system. The termination message will typically include a termination message identifier, and an acknowledgement from the requesting computer system that the all the response messages were received. The responding computer system then sends a termination response message that relates to the termination message identifier. Accordingly, both the requesting and responding computer systems acknowledge receipt of specific messages in the end-to-end connection. [0015] Additional features and advantages of exemplary implementations of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of such exemplary implementations. The features and advantages of such implementations may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features will become more fully apparent from the following description and appended claims, or may be learned by the practice of such exemplary implementations as set forth hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS [0016] In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: [0017] Figure 1 illustrates a request-response series in accordance with the present invention in which messages sent by a requesting computer system are appropriately acknowledged by the responding computer system; [0018] Figure 2 illustrates a request-response series in accordance with the present invention in which at least one response message from the responding computer system fails; [0019] Figure 3 illustrates a request-response series in accordance with the present invention in which at least one request message sent by the requesting computer system fails; [0020] Figure 4 illustrates a method from the requesting computer perspective and from the responding computer perspective for communicating messages and responses, and exchanging acknowledgements in a reliable request-response fashion in accordance with the present invention; and [0021] Figure 5 illustrates a suitable computing environment for practicing one or more implementations of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0022] The present invention extends to systems, methods, and computer program products configured to ensure reliable messaging in a request-response environment. In particular, implementations of the present invention relate in part to specific request and response mechanisms that place constraints on a responding computer system to process messages sent by a requesting computer system only in a manner that is intended. [0023] As will be understood from the present specification and claims, one aspect of the invention relates to establishing an end-to-end connection between a requesting computer system and a responding computer system that uniquely identifies messages from both computer systems. Another aspect of the invention relates to sending request messages to the responding computer system that are followed up with a response messages from the responding computer system. The responding computer system acknowledges request messages from the requesting computer system, and the requesting computer system acknowledges response messages from the responding computer system. A further aspect of the invention relates to terminating the communication in a way that also implements a termination acknowledgment message from the responding computer system. [0024] For example, Figure 1 illustrates a request-response series in accordance with the present invention in which all messages sent by requesting computer system 100 are appropriately acknowledged by the responding computer system 105, and vice versa. In general, the end-to-end connection described herein can be layered on top of any type of network connection that provides for request-response interaction, such as TCP and the like, upon which are layered request-response framing protocols such as HTTP, and so on. There are, of course, other request-response transport and framing protocols that can be practiced in accordance with the present invention. [0025] In any event, Figure 1 shows that requesting computer system 100 initiates an end-to-end connection by sending a connection initiation request message 110 "Create Sequence[Offer=A]" to the responding computer system 105. This end-to-end connection can persist over one or more underlying network connections, such that there could be one or more transport connections between the requesting computer system 100 and responding computer system 105 at the same time, distinguished using the end-to-end connection identifiers. The request message 110 includes an identification "A" that will be used by responding computer system 105 for all the messages in the end-to-end connection. Figure 1 also shows that responding computer system 105 accepts the connection with a response 120 "Create SequenceResponsefB]" for the established connection. Response message 120 includes identification "B", which will be used by requesting computer system 100 for all messages it sends in the established end-to-end connection. [0026] When, or before, establishing an end-to-end connection between the requesting computer system 100 and responding computer system 105, the two computers can also set up a connection "contract". For example, connection request message 110 can include an identification of a connection contract (not shown), which is agreed to in message 120. The connection contract can include any number of instructions that can be configured for any number of ends. For example, in one implementation, the connection contract requires that each message received by the responding computer system 105 be processed "exactly once", or "not more than once", or "at least once". [0027] In another implementation, the connection contract indicates that processing takes place in an ordered fashion, or only after requesting computer system 100 has acknowledged receipt of all response messages from responding computer system 105. For example, the responding computer system 105 may be required to cache all received messages; and, after all messages have been received (in whatever order) and appropriately acknowledged by requesting computer system 100, responding computer system 105 can then process the received messages in a particular order. Responding computer system 105 would then prepare responses that would be pulled at a later time by the requesting computer system 100. [0028] After the end-to-end connection (and related contract) is established, requesting computer system 100 sends to responding computer system 105 a first message 130 of the end-to-end connection. First message 130 "Sequence[B,l]ID[a]" includes the identifier "B", which was provided by the responding computer system 105 in message 120. Message 130 also includes a sequential number "1" (i.e., "B,l") for first message 130, and a separate first identifier "a". First identifier "a" uniquely identifies message 130 apart from the relative sequence number "1" of first message 130. Upon receiving first message 130, responding computer system sends response message 140 "Sequence[A,l],Ack[Bl-l],RelatesTo[