A transaction is a sequence of state changes, which are either all performed or not performed at all. In this regard, a transaction is said to complete if all the state changes in the sequence are performed. If one of the state changes cannot be performed, all the previous state changes that have been performed are undone, i.e. □ restored back to their original state, and the transaction is said to be rolled-back. Systems which are based on the performance of transactions are said to be transactional. An example of a transactional system is where an item is purchased over the Internet. In this case, the transaction, i.e. □ the purchase of the item, involves at least a sequence comprising two state changes: placing an order for the item and debiting the credit card of the purchaser for payment of the item.
A distributed transaction is one in which a state change pertaining to the transaction may be made on a distributed system such as, for example, different computers that are interconnected across a network. A central feature to implementing distributed transactions is that parts of the distributed system, which would be the different computers in the example given earlier of a distributed system, communicate with each other in a reliable manner. By this, it is meant that, for a transaction conducted between entities A and B of a distributed system, if entity A tells entity B running on a different computer that it should make a state change, then entity A should be informed by entity B that the state change has been made or not, for example. In certain applications and/or systems, it is imperative that transactional semantics are completed even if parts of the system that are engaged in the performance of the transaction fail. For example, it would be undesirable if a credit card is debited even though an order is ultimately not placed due to the failure of one of the machines involved in the purchase transaction.
To manage transactions between applications, software known as messaging middleware has been developed. Essentially, such messaging middleware takes over the role of ensuring that data sent from a sending application is received by the destination/receiving application for that data. In the absence of the messaging middleware, the sending and destination applications would each have to be customized to be able to communicate with the other and ensure that the data is reliably delivered. Previously-proposed messaging middleware includes MQ Telemetry Transport (MQTT). MQTT supports the so-called publish-subscribe messaging system whereby, when publication on a specific topic is done by a publishing application, those applications that have subscribed to that topic receive data pertaining thereto.
Reference is now made to FIG. 1 of the accompanying drawings in order to gain a better understanding of how MQTT may be applied in a messaging system using the publish-subscribe model. As can be seen from FIG. 1, an application that publishes on a subscribed topic, such an application being hereinafter referred to as the publisher 1, sends data pertaining to the topic to a broker 6. The broker 6 sends on this data to each application that has registered with the broker 6 to receive data on the topic, such an application being hereinafter referred to as a subscriber. Data delivery from the publisher 1 to the broker 6 is done via a hierarchy of layers underlying thereto. Underlying the publisher 1 is a messaging layer 2 and a transport layer 3, such an arrangement hereinafter being referred to as the publisher stack. Corresponding layers, messaging layer 5 and transport layer 4, are also arranged to underlie the broker 6, such an arrangement hereinafter being referred to as the broker stack. Although not shown in FIG. 1, a subscriber would be implemented in a stack having a composition corresponding to the publisher/broker stack and, like the publisher stack, is coupled to the broker stack via the network layer 7, which is, for example, the Internet.
In the example given in FIG. 1, the messaging layers 2, 5, are implemented with MQTT and the transport layers 3, 4 are implemented with the transmission control protocol (TCP). MQTT removes the need for the different applications such as, for example, the publisher-broker or broker-subscriber, to liaise with each other to ensure data delivery and is chosen on account of offering a simpler mechanism for the reliable delivery of data once to a destination application than previously-proposed messaging middleware. In conjunction with MQTT, TCP is implemented on account of the fact that it offers reliable and in-order delivery of data to a destination application. Specific details pertaining to TCP and/or the different layers underlying the transport layers 3, 4, by way of which data delivery from the publisher 1 to the broker 6 would be known to a skilled person and so shall not be given herein. Such layers are generally depicted as the network layer 7 in FIG. 1.
The MQTT protocol supports different modes of operation that may be chosen in accordance with the different levels of reliability to be implemented in an application. In particular, MQTT offers the possibility of the delivery of data exactly once to a destination application through the use of a so-called four-way handshake, which will be explained with reference being made to the publisher-broker scenario depicted in FIG. 1. For the avoidance of doubt, it is, of course, equally applicable to a broker-subscriber scenario and generally any system in where data is to be transferred from a sending application to a destination application.
Referring to FIG. 1, the four-way handshake would be implemented as follows:                The publisher 1 sends data on a topic to the broker 6;        On receiving the data, the broker 6 sends an indication of reception to the publisher 1;        On receiving the indication of reception, the publisher 1 indicates to the broker 6 that it has received the indication of reception, and        The broker 6 completes the handshake by sending an acknowledgment to the publisher 1.        
The four-way handshake has to be performed because, after the transmission of data from the publisher 1, there are some unknowns to be resolved before the state is restored to a consistent one, i.e. the transaction is said to have occurred. These are:                The publisher 1 does not know if the broker 6 has received the data;        The broker 6 does not know if the publisher 1 knows that it has received the data,        The publisher 1 does not know if the broker 6 knows that it has received the indication of reception.        
After the broker 6 has sent the acknowledgment to the publisher 1, the publisher 1 may resend the indication to the broker 6 that it has received the indication of reception message from the broker 6 without actually resending the data. In an alternative approach, after the broker 6 has sent the acknowledgment message that it has received the data to the publisher 1, the publisher 1 may resend the data and it is up to the broker 6 to deal with the multiple versions of the data.
The approach outlined above has the following inherent problems:    1. The messaging layers act independently of the transport layers. Thus, loss at the network layer may cause retransmission of data both at the transport layer and the messaging layer and the system may fail through, for example, pointless attempts at retransmissions.    2. Control flow is not supported at the messaging layers but only at the transport layers. Thus, if the rate at which data is read by the broker from its corresponding messaging layer is much less than that at which it is sent by messaging layer of the publisher, then the system may become saturated by the multiple retransmission of data that the publisher will perform on account of not having received an acknowledgment from the broker for such data within the predetermined time by which it would expect to have received such acknowledgment.    3. In-order data delivery may be more difficult to achieve. This is because the four-way handshake is completed on receipt of data by the broker before the next data is sent by the publisher. For this, at least four network exchanges may have to be performed, which upper-bounds the throughput of the system. Alternatively, the constraint of performing the handshake may be weakened, in which case delivery out of order may pose problems.    4. Unsuitability of high-volume data-transfer and limitation of the data-transfer rate on account of an acknowledgment message having to be sent for each data packet received by the broker.
The use of a buffer layer between MQTT and TCP is disclosed. However, there is no disclosure of how transactional semantics may be supported by the disclosed system in a manner such that data sent by the sending application to a destination application is not lost in the event of, for example, a system crash.
USPTO Backgrounds
USPTO Backgrounds