Transaction management method, medium and apparatus for transaction message-based password protocol

Abstract

The application provides a transaction management method, medium and device of a password protocol based on transaction messages, the method comprising: using an application system of a password protocol and a message middleware, executing the password protocol in the application system, steps A and B of the password protocol having transaction characteristics, and the transaction characteristics of both parties being guaranteed by transaction messages of the message middleware; wherein the application system records transaction information of each execution by establishing a transaction table, and different transactions are distinguished by a transaction ID field in the transaction table. The application can solve the data consistency problem between password protocol steps having distributed transaction characteristics or between two password protocols.

Description

Technical Field

[0001] This invention relates to the field of cryptographic protocol technology, and more specifically, to a cryptographic protocol transaction management method, medium, and apparatus based on transaction messages. Background Technology

[0002] A cryptographic protocol is a series of steps agreed upon by two or more participants to accomplish a specific task in cryptographic communication. It refers to the agreed-upon communication format, steps, cryptographic operation methods, and key data used between cryptographic devices, between cryptographic administrators, between cryptographic administrators and those being managed, and between a cryptographic system and its users, for activities related to cryptographic communication such as key transfer, data transmission, or the exchange of status and control information. The execution of the cryptographic protocol is the main activity of a cryptographic system, generally implemented through computer programs. In order to ensure the correctness and consistency of the execution of cryptographic protocol steps, transaction mechanisms are required in certain scenarios.

[0003] A transaction is a user-defined series of database operations. These operations can be viewed as a complete logical processing unit. A transaction consists of all operations executed between the start and end of the transaction. Transactions are the basic unit of recovery and concurrency control. For example, a database transaction is a logical processing unit of a set of SQL statements. In this set of SQL operations, either all operations succeed or all operations fail.

[0004] Transactions possess four key properties: atomicity, consistency, isolation, and durability. Atomicity means that a transaction must be a single, atomic unit of operation; each operation within a transaction can only achieve one of two states during its execution: either all succeed or all fail; any single operation will cause the entire transaction to fail, and all other executed operations will be rolled back. Only when all operations succeed is the entire transaction considered successfully completed. Consistency means that a transaction cannot compromise the integrity and consistency of the database data during execution. The database must be in a consistent state before and after a transaction's execution. Isolation means that in a concurrent environment, the operations and data used within a transaction are isolated from other concurrent transactions; concurrently executed transactions cannot interfere with each other. Durability means that once a transaction is committed, the data in the database must be permanently saved; even in the event of a server system crash or downtime, as long as the database restarts, it can be restored to the state it was in after the transaction successfully concluded.

[0005] For distributed systems, distributed transaction mechanisms are also required. A distributed transaction refers to a transaction where the participants, supporting servers, resource servers, and transaction manager reside on different nodes within the same distributed system. Because distributed transactions span multiple database resources, enforcing ACID properties to maintain data consistency across all resources is crucial.

[0006] Regarding the distributed transaction problem in cryptographic protocols—that is, the issue of distributed transaction characteristics between steps in a cryptographic protocol or between two cryptographic protocols—currently, distributed transaction technology has not been applied to cryptographic protocols, and there is no dedicated solution. The main approach is to use non-transactional mechanisms or perform some logical compensation, which easily leads to inconsistent execution results. A search of domestic and international papers and patents reveals very few papers offering solutions to the transaction problem in cryptographic protocols, and there are no patents related to applying transactional message mechanisms to cryptographic protocols to solve the distributed transaction problem.

[0007] Transaction issues in cryptographic protocols, like other transaction issues, include local transactions and distributed transactions. Local transactions can be guaranteed using mature technologies. However, for distributed transactions, since distributed systems may be deployed on different servers and can only communicate over a network, it is impossible to accurately know the transaction execution status of each system. The characteristic of distributed system calls is that the execution of a core transaction logic simultaneously calls multiple downstream services for processing. Service failures, network connection anomalies, or synchronous call timeouts can lead to data inconsistencies. Figure 1 This is a schematic diagram of the distributed transaction principle of a cryptographic protocol. How to ensure that the execution results of the core business and multiple downstream businesses are completely consistent is the main problem that distributed transactions need to solve.

[0008] To ensure consistency between the execution results of core business processes and multiple downstream business processes, a typical solution is a distributed transaction system based on the XA protocol. This involves encapsulating downstream call branches into large transactions containing independent transaction branches. While the XA protocol-based distributed transaction solution can guarantee the correctness of business processing results, its biggest drawback is the large scope of resource locking and low concurrency in a multi-branch environment. As the number of downstream branches increases, system performance deteriorates.

[0009] The above-mentioned distributed transaction scheme based on the XA protocol is simplified by treating upstream system changes as local transactions and executing remaining system changes as downstream transactions of ordinary messages. The transaction branch is simplified to upstream transaction + ordinary message, fully utilizing the asynchronous capabilities of messages to shorten the link and improve concurrency. However, in this scheme, inconsistencies can easily arise between the downstream branch of the message and the main branch of the upstream system. The fundamental reason why ordinary messages and upstream transactions cannot guarantee consistency is that ordinary messages do not have the capabilities of commit, rollback, and unified coordination like single-machine database transactions. Distributed transaction messaging functionality based on message queues, on the basis of ordinary messages, supports two-phase commit capability. Binding two-phase commit with local transactions achieves global consistency of commit results. The message queue transaction messaging solution also has the advantages of high performance, scalability, and simple business development.

[0010] Applying transactional messaging mechanisms to cryptographic protocols that require distributed transactions can effectively solve the data consistency problem between steps in cryptographic protocols with distributed transaction characteristics or between two cryptographic protocols. Summary of the Invention

[0011] The present invention aims to provide a cryptographic protocol transaction management method, medium and apparatus based on transaction messages, so as to solve the data consistency problem between steps of cryptographic protocols with distributed transaction characteristics or between two cryptographic protocols.

[0012] This invention provides a cryptographic protocol transaction management method based on transaction messages, comprising:

[0013] The application system and message middleware using the cryptographic protocol execute the cryptographic protocol in the application system. Steps A and B of the cryptographic protocol have transaction characteristics, and the transaction characteristics of both parties are guaranteed by the transaction messages of the message middleware.

[0014] The application system establishes a transaction table to record the transaction information for each execution, and the transaction ID field in the transaction table distinguishes different transactions.

[0015] Furthermore, the method includes the following steps:

[0016] (1) The application system executes the cryptographic protocol. Steps A and B of the cryptographic protocol have transaction characteristics. When the cryptographic protocol executes step A, it first sends a message to the message middleware.

[0017] (2) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message.

[0018] (3) The application system begins to execute the transaction logic of step A of the cryptographic protocol;

[0019] (4) The application system submits a secondary confirmation result to the message middleware based on the transaction execution result of step A of the cryptographic protocol. After receiving the secondary confirmation result, the message middleware performs the following processing:

[0020] The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to the application system, then proceeds to step (8);

[0021] The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to the application system. The application system's cryptographic protocol execution ends or steps (1) are re-executed.

[0022] (5) In special circumstances such as network outage or application system restart, if the message middleware does not receive the second confirmation result submitted by the application system, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message back lookup to any producer instance in the application system cluster, i.e. the message producer.

[0023] (6) After receiving the message callback, the application system needs to check the final state of the local transaction execution of the corresponding message;

[0024] (7) The application system resubmits the second confirmation result based on the final state of the local transaction it has detected, and the message middleware still processes the semi-transaction message according to step (4).

[0025] (8) After receiving the semi-transactional message from the message middleware, the application system executes the transaction logic of step B of the cryptographic protocol. The success of step B is guaranteed by the application system. If step B is executed successfully, the subsequent business process will continue to be executed. If step B fails, the transaction logic of step B will be re-executed.

[0026] This invention also provides a cryptographic protocol transaction management method based on transaction messages, applied to distributed transaction management of multiple cryptographic protocols, the method comprising:

[0027] Using application system A, cryptographic protocol module A is located in application system A, application system B, cryptographic protocol module B is located in application system B, and message middleware; the two application systems execute their respective cryptographic protocols, cryptographic protocol A and cryptographic protocol B have transaction characteristics, which are guaranteed by transaction messages in message middleware;

[0028] Application system A establishes a transaction table to record the transaction information for each execution, and the table distinguishes different transactions by the transaction ID field.

[0029] Furthermore, the method includes the following steps:

[0030] (1) Application system A contains cryptographic protocol A transaction logic, and application system B contains cryptographic protocol B transaction logic; cryptographic protocol A transaction logic and cryptographic protocol B transaction logic are related during execution, cryptographic protocol A transaction logic is executed before cryptographic protocol B transaction logic, and both have transaction characteristics; application system A and application system B are connected through a message middleware with transaction message function;

[0031] (2) When application system A executes the transaction logic of cryptographic protocol A, it first sends a message to the message middleware;

[0032] (3) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system A, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message.

[0033] (4) Application system A begins executing the transaction logic of cryptographic protocol A;

[0034] (5) Application system A submits a secondary confirmation result to the message middleware based on the transaction logic execution result of cryptographic protocol A. After receiving the secondary confirmation result, the message middleware performs the following processing:

[0035] The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to application system B, then proceeds to step (9);

[0036] The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to application system B. The transaction logic of the cryptographic protocol A of application system A will end or step (2) will be re-executed.

[0037] (6) In special circumstances such as network outage or application system A restart, if the message middleware does not receive the second confirmation result submitted by application system A, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message lookup to any producer instance in the application system A cluster.

[0038] (7) After receiving the message callback, application system A needs to check the final state of the execution of the local transaction (cryptographic protocol A transaction logic) of the corresponding message;

[0039] (8) Application system A resubmits the second confirmation result based on the final state of the local transaction it has checked. The message middleware still processes the semi-transaction message according to step (5).

[0040] (9) After receiving the semi-transactional message from the message middleware, application system B executes the cryptographic protocol B transaction logic. The success of the cryptographic protocol B transaction logic is guaranteed by application system B. If the cryptographic protocol B transaction logic is executed successfully, the subsequent business process will continue to be executed. If the cryptographic protocol B transaction logic fails to execute, the cryptographic protocol B transaction logic will be re-executed.

[0041] The present invention also provides a computer terminal storage medium storing computer terminal executable instructions, characterized in that the computer terminal executable instructions are used to execute the above-described cryptographic protocol transaction management method based on transaction messages.

[0042] The present invention also provides a computing device, comprising:

[0043] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described transaction message-based cryptographic protocol transaction management method.

[0044] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0045] 1. In terms of performance, this invention uses a message middleware that can withstand high concurrency, making it suitable for both general business scenarios and high-concurrency scenarios. Taking RocketMQ message middleware as an example, RocketMQ can handle hundreds of thousands of concurrent requests and supports clustered deployment. The system's concurrency can be increased by adding deployment instances to meet higher requirements. For cryptographic protocol business systems within the scenario, performance is guaranteed by the system itself.

[0046] 2. In terms of ease of use, the system architecture of this invention is simple to build. By establishing message middleware between cryptographic protocols or steps with transactional properties, transactional messages are used to ensure the eventual consistency of the cryptographic protocols. Message consumers (the cryptographic protocols that process messages) must support idempotency in message consumption to prevent the duplicate consumption of the same message; at the same time, the execution results of downstream cryptographic protocol steps are guaranteed by the cryptographic protocol system itself.

[0047] 3. In terms of scalability, the actual cryptographic protocol is determined based on the specific business application system and can be extended to meet different business needs. The specific format and content of messages in a transaction can be adjusted according to different business scenarios and systems. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a schematic diagram of the distributed transaction principle of a cryptographic protocol.

[0050] Figure 2 This is a flowchart of the cryptographic protocol transaction management method based on transaction messages in Embodiment 1 of the present invention.

[0051] Figure 3 This is a flowchart illustrating the application of the transaction message-based cryptographic protocol transaction management method in multi-cryptographic protocol distributed transaction management in Embodiment 2 of the present invention. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0053] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0054] Example 1

[0055] This embodiment proposes a cryptographic protocol transaction management method based on transaction messages. It uses an application system and message middleware to execute the cryptographic protocol within the application system. Steps A and B of the cryptographic protocol have transactional characteristics, which are guaranteed by transactional messages from the message middleware. Figure 2 As shown, the process of the transaction management method for cryptographic protocols based on transaction messages includes the following steps:

[0056] (1) The application system executes the cryptographic protocol. Steps A and B of the cryptographic protocol have transaction characteristics. When the cryptographic protocol executes step A, it first sends a message to the message middleware.

[0057] (2) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message.

[0058] (3) The application system begins to execute the transaction logic of step A of the cryptographic protocol;

[0059] (4) The application system submits a secondary confirmation result (Commit or Rollback) to the message middleware based on the transaction execution result of step A of the cryptographic protocol. After receiving the secondary confirmation result, the message middleware performs the following processing:

[0060] The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to the application system, then proceeds to step (8);

[0061] The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to the application system. The application system's cryptographic protocol execution ends or steps (1) are re-executed.

[0062] (5) In special circumstances such as network outage or application system restart, if the message middleware does not receive the second confirmation result submitted by the application system, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message back lookup to any producer instance in the application system cluster, i.e. the message producer.

[0063] (6) After receiving the message callback, the application system needs to check the final state of the local transaction execution of the corresponding message;

[0064] (7) The application system resubmits the second confirmation result based on the final state of the local transaction it has detected, and the message middleware still processes the semi-transaction message according to step (4).

[0065] (8) After receiving the semi-transactional message from the message middleware, the application system executes the transaction logic of step B of the cryptographic protocol. The success of step B is guaranteed by the application system. If step B is executed successfully, the subsequent business process will continue to be executed. If step B fails, the transaction logic of step B will be re-executed.

[0066] In this method, the application system establishes a transaction table to record transaction information for each execution. Different transactions are distinguished by a transaction ID field in the transaction table. The entire execution process is within the same transaction, corresponding to a single transaction record in the transaction table. Message sending and receiving carry the same transaction ID number, including the transaction ID number in the lookup message and the transaction ID number in the secondary confirmation result. This method ensures that message sending and the local transaction (cryptographic protocol step A) succeed or fail simultaneously. Based on the success or failure of the transaction message, the application system ensures the success or non-execution of cryptographic protocol step B. This ensures the consistency between the success or failure of cryptographic protocol steps A and B.

[0067] Furthermore, this embodiment proposes a computer terminal storage medium storing computer terminal executable instructions, which are used to execute the transaction management method of the cryptographic protocol based on transaction messages as described in the preceding embodiments. Examples of computer storage media include magnetic storage media (e.g., floppy disks, hard disks, etc.), optical recording media (e.g., CD-ROMs, DVDs, etc.) or memory such as memory cards, ROMs, or RAMs. The computer storage medium can also be distributed across a network-connected computer system, for example, as an application store.

[0068] Furthermore, this embodiment proposes a computing device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the transaction management method of the cryptographic protocol based on transaction messages as described in the preceding embodiments. Examples of computing devices include PCs, tablet computers, smartphones, or PDAs.

[0069] Example 2

[0070] This embodiment proposes a cryptographic protocol transaction management method based on transaction messages, applied to distributed transaction management of multiple cryptographic protocols. It uses application system A, cryptographic protocol module A located in application system A, application system B, cryptographic protocol module B located in application system B, and a message middleware. The two application systems execute their respective cryptographic protocols. Cryptographic protocols A and B have transactional characteristics, which are guaranteed by transactional messages from the message middleware. Figure 3 As shown, the process of applying the transaction message-based cryptographic protocol transaction management method to distributed transaction management of multiple cryptographic protocols includes the following steps:

[0071] (1) Application system A contains cryptographic protocol A transaction logic, and application system B contains cryptographic protocol B transaction logic; cryptographic protocol A transaction logic and cryptographic protocol B transaction logic are related during execution, cryptographic protocol A transaction logic is executed before cryptographic protocol B transaction logic, and both have transaction characteristics; application system A and application system B are connected through a message middleware with transaction message function;

[0072] (2) When application system A executes the transaction logic of cryptographic protocol A, it first sends a message to the message middleware;

[0073] (3) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system A, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message.

[0074] (4) Application system A begins executing the transaction logic of cryptographic protocol A;

[0075] (5) Application system A submits a secondary confirmation result (Commit or Rollback) to the message middleware based on the transaction logic execution result of cryptographic protocol A. After receiving the secondary confirmation result, the message middleware performs the following processing:

[0076] The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to application system B, then proceeds to step (9);

[0077] The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to application system B. The transaction logic of the cryptographic protocol A of application system A will end or step (2) will be re-executed.

[0078] (6) In special circumstances such as network outage or application system A restart, if the message middleware does not receive the second confirmation result submitted by application system A, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message lookup to any producer instance in the application system A cluster.

[0079] (7) After receiving the message callback, application system A needs to check the final state of the execution of the local transaction (cryptographic protocol A transaction logic) of the corresponding message;

[0080] (8) Application system A resubmits the second confirmation result based on the final state of the local transaction it has checked. The message middleware still processes the semi-transaction message according to step (5).

[0081] (9) After receiving the semi-transactional message from the message middleware, application system B executes the cryptographic protocol B transaction logic. The success of the cryptographic protocol B transaction logic is guaranteed by application system B. If the cryptographic protocol B transaction logic is executed successfully, the subsequent business process will continue to be executed. If the cryptographic protocol B transaction logic fails to execute, the cryptographic protocol B transaction logic will be re-executed.

[0082] In this method, application system A establishes a transaction table to record transaction information for each execution. Different transactions are distinguished by a transaction ID field in the table. The entire execution process is within the same transaction, corresponding to a single transaction record in the transaction table. Message sending and receiving carry the same transaction ID number, including the transaction ID number in the lookup message and the transaction ID number in the secondary confirmation message. This method ensures that message sending and the local transaction (application system A's cryptographic protocol A) succeed or fail simultaneously. Then, based on the success or failure of the transaction message, application system B ensures the success or non-execution of cryptographic protocol B. In this way, the consistency between application system A's cryptographic protocol A and application system B's cryptographic protocol B is guaranteed regardless of success or failure.

[0083] Furthermore, this embodiment proposes a computer terminal storage medium storing computer terminal executable instructions, which are used to execute the transaction management method of the cryptographic protocol based on transaction messages as described in the preceding embodiments. Examples of computer storage media include magnetic storage media (e.g., floppy disks, hard disks, etc.), optical recording media (e.g., CD-ROMs, DVDs, etc.) or memory such as memory cards, ROMs, or RAMs. The computer storage medium can also be distributed across a network-connected computer system, for example, as an application store.

[0084] Furthermore, this embodiment proposes a computing device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the transaction management method of the cryptographic protocol based on transaction messages as described in the preceding embodiments. Examples of computing devices include PCs, tablet computers, smartphones, or PDAs.

[0085] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cryptographic protocol transaction management method based on transaction messages, characterized in that, include: The application system and message middleware using the cryptographic protocol execute the cryptographic protocol in the application system. Steps A and B of the cryptographic protocol have transaction characteristics, which are guaranteed by the transaction messages of the message middleware. The application system establishes a transaction table to record the transaction information of each execution, and different transactions are distinguished by the transaction ID field in the transaction table. The cryptographic protocol transaction management method based on transaction messages includes the following steps: (1) The application system executes the cryptographic protocol. Steps A and B of the cryptographic protocol have transaction characteristics. When the cryptographic protocol executes step A, it first sends a message to the message middleware. (2) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message. (3) The application system begins to execute the transaction logic of step A of the cryptographic protocol; (4) The application system submits a secondary confirmation result to the message middleware based on the transaction execution result of step A of the cryptographic protocol. After receiving the secondary confirmation result, the message middleware performs the following processing: The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to the application system, then proceeds to step (8); The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to the application system. The application system's cryptographic protocol execution ends or steps (1) are re-executed. (5) In special circumstances such as network outage or application system restart, if the message middleware does not receive the second confirmation result submitted by the application system, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message back lookup to any producer instance in the application system cluster, i.e. the message producer. (6) After receiving the message callback, the application system needs to check the final state of the local transaction execution of the corresponding message; (7) The application system resubmits the second confirmation result based on the final state of the local transaction it has detected, and the message middleware still processes the semi-transaction message according to step (4). (8) After receiving the semi-transactional message from the message middleware, the application system executes the transaction logic of step B of the cryptographic protocol. The success of step B is guaranteed by the application system. If step B is executed successfully, the subsequent business process will continue to be executed. If step B fails, the transaction logic of step B will be re-executed.

2. A computer terminal storage medium storing computer terminal executable instructions, characterized in that, The computer terminal can execute instructions for performing the transaction management method of cryptographic protocol based on transaction messages as described in claim 1.

3. A computing device, characterized in that, include: At least one processor; The system also includes a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the transaction management method based on transaction messages as described in claim 1.

4. A cryptographic protocol transaction management method based on transaction messages, applied to distributed transaction management of multiple cryptographic protocols, characterized in that, The method includes: Using application system A, cryptographic protocol module A is located in application system A, and application system B, cryptographic protocol module B is located in application system B, along with a message middleware; the two application systems execute their respective cryptographic protocols, and cryptographic protocols A and B have transactional characteristics, which are guaranteed by transactional messages in the message middleware; application system A establishes a transaction table to record the transaction information for each execution, and different transactions are distinguished by the transaction ID field in the table; The cryptographic protocol transaction management method based on transaction messages includes the following steps: (1) Application system A contains cryptographic protocol A transaction logic, and application system B contains cryptographic protocol B transaction logic; cryptographic protocol A transaction logic and cryptographic protocol B transaction logic are related during execution, cryptographic protocol A transaction logic is executed before cryptographic protocol B transaction logic, and both have transaction characteristics; application system A and application system B are connected through a message middleware with transaction message function; (2) When application system A executes the transaction logic of cryptographic protocol A, it first sends a message to the message middleware; (3) The message middleware persists the message. After successful persistence, it returns an Ack confirmation message to the application system A, indicating that the message has been sent successfully. At this time, the message is marked as "cannot be delivered temporarily". The message in this state is a semi-transactional message. (4) Application system A begins executing the transaction logic of cryptographic protocol A; (5) Application system A submits a secondary confirmation result to the message middleware based on the transaction logic execution result of cryptographic protocol A. After receiving the secondary confirmation result, the message middleware performs the following processing: The second confirmation result is Commit: The message middleware marks the semi-transactional message as deliverable and delivers it to application system B, then proceeds to step (9); The second confirmation result is Rollback: The message middleware will roll back the transaction and will not deliver the half-transaction message to application system B. The transaction logic of the cryptographic protocol A of application system A will end or step (2) will be re-executed. (6) In special circumstances such as network outage or application system A restart, if the message middleware does not receive the second confirmation result submitted by application system A, or the second confirmation result received by the message middleware is in the Unknown state, after a fixed period of time, the message middleware will initiate a message lookup to any producer instance in the application system A cluster. (7) After receiving the message callback, application system A needs to check the final state of the local transaction execution of the corresponding message; the local transaction is the transaction logic of cryptographic protocol A. (8) Application system A resubmits the second confirmation result based on the final state of the local transaction it has checked. The message middleware still processes the semi-transaction message according to step (5). (9) After receiving the semi-transactional message from the message middleware, application system B executes the cryptographic protocol B transaction logic. The success of the cryptographic protocol B transaction logic is guaranteed by application system B. If the cryptographic protocol B transaction logic is executed successfully, the subsequent business process will continue to be executed. If the cryptographic protocol B transaction logic fails to execute, the cryptographic protocol B transaction logic will be re-executed.

5. A computer terminal storage medium storing computer terminal executable instructions, characterized in that, The computer terminal can execute instructions for performing the transaction management method of cryptographic protocol based on transaction messages as described in claim 4.

6. A computing device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the transaction management method of the cryptographic protocol based on transaction messages as described in claim 4.

Images