用于鲁棒通信的方法和系统与流程

1.本发明涉及交易数据处理系统领域。本发明涉及一种用于在客户机与服务器之间进行鲁棒通信以执行交易的方法，以及在客户机装置和服务器计算机中执行的相应方法。


背景技术：

2.交易系统中的一个问题是参与的计算机之间的通信并不总是可靠。例如，在客户机为移动装置的情况下，随着客户机的位置的变化，可能会暂时失去通信。如果在交易(例如商品订购或货币交易)期间发生这种情况，至关重要的是确保客户机和与其通信的服务器都得到相同的交易结果。此外，客户机可能会认为服务器尚未收到订单，并通过用户操作或负责该订购的软件过程再次触发了该订单。这可能导致同一交易的多次执行。


技术实现要素：

3.因此，本发明的目的是创建一种用于在最初提到的类型的客户机和服务器之间进行鲁棒通信的方法，以解决上述问题。
4.这些目的通过根据本发明的用于客户机和服务器之间的鲁棒通信的方法来实现。
5.在一个实施例中，用于本文描述的方法的计算机程序产品可加载到构成本文描述的客户机装置或服务器计算机的数字计算机或计算机系统的内部存储器中，并且包括使得客户机装置或服务器计算机的一个或多个处理器分别执行该方法的各个步骤的计算机可执行指令。在另一个实施例中，计算机程序产品包括其上记录有计算机可执行指令的计算机可读介质。所述计算机可读介质优选地是非暂时性的；即，是有形的。在又一个实施例中，计算机程序被体现为可再现的计算机可读信号，并且因此可以以这种信号的形式被发送。
6.根据本发明的其他方面，其他实施例是显而易见的。方法发明的特征可以与装置发明的特征相结合，反之亦然。
附图说明
7.下面将参考附图中示出的示例性实施例更详细地解释本发明的主题，附图示意性地示出了：
8.图1在成功交易的情况下，客户机装置和服务器计算机以及它们之间交互的序列图；
9.图2在交易不成功的情况下，客户机装置和服务器计算机以及它们之间交互的序列图。
10.在附图标记列表中以汇总形式列出了附图中使用的附图标记及其含义。原则上，图中相同的部分具有相同的附图标记。
具体实施方式
11.图1示意性地示出了用于在客户机1和服务器2之间进行鲁棒通信以执行交易的方
法的序列图。客户机装置1和服务器计算机2都是计算机化的装置，通常包括数字数据处理单元。典型地，客户机装置1包括用于与另一数据处理装置进行通信的用户接口和/或通信接口。
12.所述方法包括以下步骤：
13.·
客户机基于用户输入，确定(11)交易详情；
14.在实施例中，客户机是在由用户控制的装置上运行的软件应用，其中交易请求是基于用户输入生成的。该交易可以是例如购买或转移商品或资金的订单(例如“订购两个苹果”)。在实施例中，客户机由在另一上下文中执行交易的软件控制。
15.所述方法还包括以下步骤：
16.·
客户机生成(12)并向服务器发送交易请求21，该交易请求21包括交易的详情和标识该交易的交易uuid；
17.客户机存储该交易uuid，并在以后的步骤中将附有该uuid的输入消息与该uuid标识的交易相关联。
18.生成该请求的步骤(12)可能已经涉及与服务器的交互，例如检查要订购的商品是否可供应，或者用户的帐户是否有足够的资金来支付该商品。这可以称为业务逻辑建立。在某些情况下，业务逻辑建立可以包含uuid。
19.通常，可以使用业务逻辑设置来确保交易的服务器侧部分具有所有必需的资源，以最大化最终交易请求21的成功。这是可选的，因为并非每个用例都依赖于它。
20.例如，业务逻辑设置可以用于维护交易的服务器侧会话。在电子商务服务器的情况下，这可以是向(与uuid关联的)购物车中添加一个或多个商品，这样最终的购买请求就不会出现缺货的情况。在这种情况下，业务逻辑设置将把库存商品预留给购物车。交易请求21将会最终结帐。
21.在已经检查了这样的应用侧或业务侧条件并且在一定程度上准备好从业务侧执行交易之后，客户机生成交易请求21。
22.该方法还包括以下步骤：
23.·
客户机在向服务器发送交易请求21后，等待第一超时时间段(13)，以等待服务器发送的交易确认请求22；
24.·
可选地，可以是这种情况，在等待时，客户机
25.o不被允许再发送具有同一uuid的交易请求；
26.·
服务器，在接收到交易请求21后，生成(31)并向客户机发送交易确认请求22，该交易确认请求22包括交易uuid；
27.生成交易确认请求22的步骤(31)可以涉及完整的业务逻辑建立。服务器存储和跟踪交易uuid，并将它与服务器侧稍后生成的交易结果相关联。如上所述，在已经通过较早的交互被完成的部分业务逻辑设置的实施例中，可以在生成交易确认请求22之前对应用或业务侧进行最终检查。
28.例如，如果不是所有服务器侧资源都可用于进行处理，则服务器可以拒绝交易请求21。例如，如果我们想向帐户x支付2000美元，而我们自己的帐户中没有足够的资金。
29.在业务应用的上下文中看到，使得发送交易确认请求22的步骤与从业务或应用侧建立交易有关。其余步骤用于协调客户机装置1和服务器计算机2，以确保在处理步骤33中
仅执行一次交易，并确保客户机装置1和服务器计算机2都被正确告知执行结果。
30.客户机接收交易确认请求22的事实使客户机知道交易请求21没有在传输中丢失。这进一步意味着，客户机可以确信服务器来负责完成交易，并且客户机可以简单地等待最终结果。如下所示，最终结果可以是交易成功或中止。
31.在实施例中，发送交易确认请求22由客户机发起。例如，它是由轮询服务器的客户机触发。或者，客户机监视服务器的相应状态，并且在检测到该状态的改变时，获取交易确认请求22，这涉及到发送交易确认请求22的服务器。
32.该方法还包括以下步骤：
33.·
如果在第一超时时间段到期之前接收到包含该交易uuid的交易确认请求22，则客户机生成(14)并发送包含该交易uuid的交易确认响应23，随后等待(15)来自服务器的包含该交易uuid的交易结果消息24，并且在等待时
34.o不能中止该交易；
35.·
如果在第一超时时间段到期之前没有接收到交易确认请求22，则客户机中止与该交易uuid相关联的客户机侧交易请求处理；
36.在实施例中，客户机对于同一订单发送具有不同的第二交易uuid的另一个交易请求21，并且通过等待(13)第一超时时间段以等待具有第二交易uuid的交易确认请求22来开始针对该第二交易uuid的相同处理。
37.该方法还包括以下步骤：
38.·
如果在中止客户机侧交易请求处理后，接收到交易确认请求22，则客户机不响应服务器，或者向服务器发送中止消息；
39.·
向客户机发送交易确认请求22后，服务器等待(32)第二超时时间段，以等待客户机发送的交易确认响应23；
40.在客户机发送交易确认响应23之前，客户机总是可以自由地中止交易。如果要中止，它可以简单地通过不发送交易确认响应23来将其传达给服务器，这将使得服务器在第二个超时时间段到期后中止。或者，它可以通过向服务器发送中止消息来将其传达给服务器。在这两种情况下，服务器都将中止与该交易uuid对应的服务器侧交易。
41.在发送交易确认响应23之后，客户机不能自由决定了。它必须等待服务器侧处理的结果。这将是交易结果消息24或服务器侧交易中止消息25。交易结果消息通常是最终结果，即提交或中止。
42.该方法还包括以下步骤：
43.·
如果在第二超时时间段到期之前接收到交易确认响应23，则服务器处理(33)该交易并将该交易结果消息24发送给客户机；
44.处理(33)交易通常涉及提交在前一阶段，例如在生成(31)交易确认请求22时，和/或在先前的交互步骤中建立的服务器后端交易。
45.在实施例中，发送交易结果消息24是由客户机发起的。例如，它是由轮询服务器的客户机触发的。或者，客户机监视服务器的相应状态，并且在检测到该状态的改变时，获取交易结果消息24，这涉及到发送交易结果消息24的服务器。
46.该方法还包括以下步骤：
47.·
如果在第二超时时间段到期之前没有接收到交易确认响应23，则服务器中止
(34)服务器侧交易处理，并且将包括该交易uuid的服务器侧交易中止消息25发送给客户机；
48.中止(34)服务器侧交易处理涉及中止由服务器侧交易所需的后端处理或交易。
49.该方法还包括以下步骤：
50.·
如果接收到服务器侧交易中止消息25，则客户机中止(17)客户机侧交易请求处理；
51.·
如果接收到交易结果消息24，则客户机处理(16)交易结果消息24。
52.如上面针对交易确认请求22和交易结果消息24所解释的，由接收实体发起发送消息的类似过程也可以在其他消息的发送中使用。例如，对于交易确认响应23，和/或服务器侧交易中止消息25等。
53.总之，用于在客户机1和服务器2之间进行鲁棒通信以执行交易的方法包括以下步骤：客户机1通过交易请求21发起将由服务器计算机2执行的交易，等待(13)来自服务器计算机2的交易确认请求22；以及当接收到该响应时，发送交易确认响应23。在发送交易确认响应23之后，客户机装置1不能随意中止交易，而是被迫等待，并接受来自服务器计算机2的交易结果消息24，或者在服务器侧失败的情况下，接受服务器侧交易中止消息25。
54.在发送交易请求21并等待交易确认请求22之后，不允许客户机发送具有同一交易uuid的另一个交易请求21。这样可以防止服务器多次执行该交易。然而，如果客户机不确定交易请求21是否已经到达服务器，则即使在接收交易确认请求22的超时时间段之前，客户机也可以为同一订单发送具有一个不同交易uuid的另一交易请求21。如果随后具有第一uuid的交易确认请求22确实到达，则客户机可以中止该第一交易。或者，如果客户机随着时间的推移接收到两个交易uuid的交易确认请求22，则可以通过发送相应的交易确认响应23并中止另一个交易来选择其中一个继续。
55.通常，客户机和服务器中与交易uuid相关联的所有消息和状态均由该uuid标识。根据所描述的方法，几个交易可以被并行处理，每个交易由具有相应交易uuid的消息控制。
56.在客户机侧上的处理(16)交易结果的步骤之后，客户机可以向服务器发送包括该交易uuid的接收消息26。此后，服务器知道客户机知道交易处理的结果，因此服务器可以忘记该交易。
57.尽管已经在当前实施例中描述了本发明，但是应当清楚地理解，本发明不限于此，而是可以在权利要求的范围内以其他方式被不同地体现和实践。