Control transaction requests between applications and servers

Abstract

A concept for controlling the delivery of transaction requests between applications and servers via a decentralized architecture. In such a concept, the delivery of transaction requests is controlled taking into account information about groups of transaction requests that could cause transaction conflicts if processed in parallel. Such groupings of transaction requests can be defined, modified, and updated at runtime based on previously or currently observed transaction conflicts.

Description

Background Art

[0001] The present invention relates generally to the field of communication between applications and servers, and more particularly to a middleware system for controlling transaction requests between applications and servers.

[0002] The present invention also relates to a computer-implemented method for controlling transaction requests between an application and a server.

[0003] The invention also relates to a computer program product comprising a computer readable program code enabling a processor of a system or a plurality of processors of a network to implement such a method.

[0004] Enterprise architectures are often built around integration middleware that is configured to route data to and from various sources and destinations, such as database management systems, messaging systems, and distributed ledger technologies.

[0005] Such an architectural implementation may employ multi-version concurrency control (MVCC) that allows simultaneous reading and writing of data, where a request to write a piece of data must be accompanied by a hash or version code representing the current value of the data being overwritten. If the hash or version code does not match the current value, then the request to overwrite the data will be rejected (i.e., causing MVCC to fail) because this indicates that another connected client has concurrently updated the value. If a client's write request is rejected, then the client must retry (e.g., repeat the request), which typically involves reading the current value and sending the write request again. Under heavy load, the rate of MVCC failures can increase rapidly, resulting in poor system performance. Summary of the Invention

[0006] The present invention seeks to provide a middleware system for controlling transaction requests between applications and servers.

[0007] The present invention also seeks to provide a method for controlling transaction requests between an application and a server. The method may be computer-implemented.

[0008] The present invention further seeks to provide a computer program product comprising computer program code for implementing the proposed method when executed by a processing unit and a processing system adapted to execute the computer program code.

[0009] According to aspects of the present invention, a middleware system for controlling transaction requests between an application and a server is provided. The middleware system includes a proxy component. The proxy component is configured, at runtime, to: define one or more conflict groups for transaction requests based on previously or currently observed transaction conflicts; and control parallel delivery of transaction requests based on the one or more conflict groups.

[0010] Proposed is a concept for controlling transaction requests to reduce the risk of MVCC conflicts. In such a concept, a middleware system can be employed between an application and a server (e.g., between a client application and a blockchain network (or other MVCC-constrained backend system)), and the middleware system can control (e.g., throttle or queue) the flow of transaction requests so that only certain requests are allowed to be submitted in parallel. For example, at runtime, the middleware system can group transaction requests that it observes creating transaction conflicts when delivered in parallel. Based on such groups, the middleware system can determine whether transactions should be delivered in parallel.

[0011] Embodiments propose that potentially conflicting transaction requests can be arranged into groups, and this can be done dynamically at runtime based on observed conflicts. Transaction requests within each group can then be temporarily queued in order until the previous request has been successfully processed and, in the case of a blockchain, committed to the ledger. Some embodiments can therefore provide recommendations for integration flow nodes that can dynamically control request throttling behavior to maximize the throughput of successful transaction submissions.

[0012] The proposed embodiment can adopt the concept of dynamically creating conflict groups based on the runtime history of transaction conflicts (e.g., transaction conflicts). Moreover, this dynamic grouping information can be published to other components, nodes or organizations, allowing them to update their group configurations.

[0013] According to the proposed concept, a middleware component or system can be provided as an integration flow and placed between the client application and the server. This integration flow can form a new 'committer' or 'proxy' node that is configured to control the submission of transaction requests in a way that minimizes or potentially eliminates transaction conflicts (e.g., failures).

[0014] By way of example, a node may maintain a set of groups (hereinafter referred to as "conflict groups"), where each transaction request within a group can conflict with a failure if submitted simultaneously with any other transaction request within the same group. Then, if more than one transaction request within a group arrives at any time, the node may throttle the requests by queuing them in first-in, first-out (FIFO) order until they can be submitted. Each group may operate independently of one another, thereby enabling parallel processing of transaction requests from different groups.

[0015] Thus, according to the proposed embodiments, integration middleware can be provided that is configured to dynamically group and throttle transaction requests in a manner that reduces the risk of transaction conflicts. By dynamically grouping transaction requests based on previously or currently observed transaction conflicts, information that can be utilized to control the parallel submission of transaction requests can be provided.

[0016] Specifically, the proposed concept may attempt to reduce the risk of MVCC conflicts by providing middleware (e.g., an integration flow or proxy component) between client applications and MVCC-constrained backend systems. The middleware throttles transaction requests so that only requests that do not cause MVCC conflicts are allowed to be submitted in parallel. An embodiment may leverage this idea to group potentially conflicting transactions (e.g., based on a runtime history of MVCC conflicts, etc.), and then use such groups to determine whether incoming transactions can be submitted in parallel. For example, if more than one transaction request in a group arrives at any time, they may be queued until they can be safely submitted.

[0017] In some embodiments, the proxy component may include a publisher component that is configured to transmit information about one or more conflict groups to one or more remote components. In this way, embodiments may be configured to share information with other components, nodes, or organizations (such as other proxy components), thereby allowing them to update their configurations.

[0018] The proxy component may include a receiver component configured to receive information about at least one of: observed transaction conflicts; and further conflict groups of transaction requests from remote components. The proxy component may then be configured to further define one or more conflict groups of transaction requests at runtime based on the received information. Embodiments may thus utilize information from other components, nodes, or organizations (such as other proxy components) to update and improve conflict groups. In this way, embodiments may dynamically adapt and reconfigure to reflect changing conditions and / or parameters in a network or system.

[0019] In some embodiments, the proxy component can be configured to, in response to identifying multiple transaction requests that are members of the same conflict group in one or more conflict groups, queue the multiple transaction requests to prevent concurrent delivery of the multiple transaction requests. For example, the proxy component can be configured to queue the multiple transaction requests in a first-in, first-out order. This can enable control of delivery of the transaction requests, such as by deferring or delaying them until a later time when transaction conflicts will be avoided / prevented.

[0020] The proxy component can be configured to, in response to identifying a transaction conflict caused by delivering a transaction request, redefine one or more conflict groups for the transaction request based on the identified transaction conflict, and control the redelivery of the transaction request based on the redefined one or more conflict groups. Thus, embodiments can be adapted to dynamically reconfigure the delivery of transaction requests. For example, after redefining the conflict groups, the transaction request can be automatically redelivered / resubmitted, thereby avoiding simply aborting the delivery in response to the conflicting transaction request.

[0021] The middleware system may be configured to intercept and control the delivery of transaction requests between a client application and a Multi-Version Concurrency Control (MVCC) constrained server. Thus, embodiments may have particular value for architecture implementations employing MVCC.

[0022] According to another aspect of the present invention, a computer-implemented method for controlling transaction requests between an application and a server is provided. The method comprises: at runtime: defining one or more conflict groups for the transaction requests based on previously or currently observed transaction conflicts; and controlling parallel delivery of the transaction requests based on the one or more conflict groups.

[0023] According to another aspect of the present invention, a computer program product is provided, comprising a computer-readable storage medium having program instructions embodied therein, wherein the program instructions are executable by a processing unit to cause the processing unit to perform the method according to the proposed embodiment.

[0024] According to another aspect of the present invention, according to an embodiment, a computer system and a computer program product comprising at least one processor are provided, wherein the at least one processor is adapted to execute computer program code of the computer program product. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] These and other objects, features, and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the present invention, which will be read in conjunction with the accompanying drawings. The various features of the drawings are not to scale, as the illustrations are intended to facilitate clarity in understanding the present invention by those skilled in the art in conjunction with the specific embodiments. In the drawings:

[0026] Figure 1 shows a graphical representation of an example distributed system in which aspects of the illustrative embodiments may be implemented;

[0027] Figure 2 is a block diagram of an example system in which aspects of the illustrative embodiments may be implemented;

[0028] Figure 3 is a schematic diagram of a proposed distributed communication system according to an embodiment; and

[0029] Figure 4 A system according to another embodiment is shown. DETAILED DESCRIPTION

[0030] It should be understood that the drawings are schematic and not drawn to scale.It should also be understood that the same reference numerals are used throughout the drawings to indicate the same or similar parts.

[0031] In the context of this application, when embodiments of the present invention constitute methods, it should be understood that such methods may be processes for execution by a computer, i.e., may be computer-implemented methods. Thus, the individual steps of the method may reflect portions of a computer program, such as portions of one or more algorithms.

[0032] Furthermore, in the context of the present application, a system may be a single device or a collection of distributed devices adapted to perform one or more embodiments of the method of the present invention. For example, a system may be a personal computer (PC), a server, or a collection of PCs and / or servers connected via a network such as a local area network, the Internet, etc., to collaboratively perform at least one embodiment of the method of the present invention. Furthermore, a component may be an integrated flow executed by one or more processing units.

[0033] Proposed is a concept for controlling the delivery of transaction requests between applications and servers via a decentralized architecture (i.e., an interconnected distributed network). In such a concept, the delivery of transaction requests is controlled taking into account information about groups of transaction requests that could result in transaction conflicts if processed in parallel. Such groupings of transaction requests can be defined, modified, and updated at runtime based on previously or currently observed transaction conflicts.

[0034] For example, transaction requests that present potential conflicts can be placed into groups, and this can be done dynamically at runtime based on observed transaction conflicts. Thus, the defined groups can be used to determine whether multiple received (or intercepted) transaction requests should be prevented from being processed in parallel. For example, multiple transaction requests within the same group can be temporarily queued in order until the previous request has been successfully processed. In this way, embodiments can dynamically throttle transaction request behavior in order to reduce or avoid conflicts (and thereby seek to maximize the throughput of successful transaction submissions).

[0035] In particular, embodiments may be implemented in conjunction with existing distributed communication architectures that employ integrated middleware (eg, database management systems, messaging systems, and distributed ledger technologies).

[0036] Figure 1A diagrammatic representation of an exemplary distributed system in which aspects of the illustrative embodiments may be implemented is depicted. Distributed system 100 may include a computer network in which aspects of the illustrative embodiments may be implemented. Distributed system 100 includes at least one network 102, which is a medium for providing communication links between different devices and computers connected together within distributed data processing system 100. Network 102 may include connections such as wired, wireless communication links, or fiber optic cables.

[0037] In the depicted example, first server 104 and second server 106 are connected to network 102 along with storage unit 108. Furthermore, clients 110, 112, and 114 are also connected to network 102. Clients 110, 112, and 114 may be edge devices, such as personal computers, network computers, IoT devices, and the like. In the depicted example, first server 104 provides data, such as boot files, operating system images, and applications, to clients 110, 112, and 114. In the depicted example, clients 110, 112, and 114 are clients to first server 104. Distributed processing system 100 may include additional servers, clients, and other devices not shown.

[0038] In the depicted example, distributed system 100 is the Internet, where network 102 represents a global collection of networks and gateways that use the Transmission Control Protocol / Internet Protocol (TCP / IP) suite of protocols to communicate with each other. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, distributed system 100 can also be implemented to include multiple different types of networks, such as, for example, intranets, local area networks (LANs), wide area networks (WANs), etc. As described above, Figure 1 It is intended as an example, not as an architectural limitation for different embodiments of the present invention, and therefore, Figure 1 The specific components shown in the figures should not be construed as limiting the environments in which illustrative embodiments of the invention may be implemented.

[0039] Figure 2 is a block diagram of an example system 200 in which aspects of the illustrative embodiments may be implemented. System 200 is a computer (such as Figure 1 10) in the example of client 110 in the system 200, where the computer usable code or instructions for implementing the processing of the illustrative embodiments of the present invention can be located. For example, the proposed embodiments can be partially implemented in the processing unit 206 of the system 200.

[0040] In the depicted example, system 200 employs a hub architecture including a north bridge and memory controller hub (NB / MCH) 202 and a south bridge and input / output (I / O) controller hub (SB / ICH) 204. Thus, another proposed embodiment may be implemented in the memory controller hub 202 of system 200. Processing unit 206, main memory 208, and graphics processor 210 are connected to NB / MCH 202. Graphics processor 210 may be connected to NB / MCH 202 via an accelerated graphics port (AGP).

[0041] In the depicted example, a local area network (LAN) adapter 212 is connected to the SB / ICH 204. An audio adapter 216, a keyboard and mouse adapter 220, a modem 222, a read-only memory (ROM) 224, a hard disk drive (HDD) 226, a CD-ROM drive 230, a universal serial bus (USB) port and other communication ports 232, and PCI / PCIe devices 234 are connected to the SB / ICH 204 via a first bus 238 and a second bus 240. PCI / PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC Cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash memory basic input / output system (BIOS).

[0042] HDD 226 and CD-ROM drive 230 are connected to SB / ICH 204 via second bus 240. HDD 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I / O (SIO) device 236 may be connected to SB / ICH 204.

[0043] The operating system runs on the processing unit 206. The operating system coordinates and provides Figure 2 The operating system 200 controls the various components within the system 200. As a client, the operating system may be a commercially available operating system. An object-oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provide calls to the operating system from Java™ programs or applications executing on the system 200.

[0044] As a server, the system 200 may be, for example, a server running an advanced interactive execution Operating system or Operating system eServer TM System Computer System. System 200 may be a symmetric multiprocessor (SMP) system including multiple processors in processing unit 206. Alternatively, a single processor system may be employed.

[0045] Instructions for the operating system, programming system, and applications or programs are located on storage devices, such as HDD 226, and may be loaded into main memory 208 for execution by processing unit 206. Similarly, one or more programs according to embodiments may be adapted to be stored by storage devices and / or main memory 208.

[0046] The processes of the illustrative embodiments of the present invention may be performed by processing unit 206 using computer usable program code, which may be located in a memory, such as main memory 208 , ROM 224 , or one or more peripheral devices 226 and 230 .

[0047] Bus systems (such as Figure 2 The first bus 238 or the second bus 240 shown may include one or more buses. Of course, the bus system may be implemented using any type of communication structure or architecture that provides for data transfer between different components or devices attached to the structure or architecture. Communication units (such as Figure 2 The modem 222 or network adapter 212 may include one or more devices for transmitting and receiving data. The memory may be, for example, the main memory 208, the ROM 224 or a memory such as a memory card. Figure 2 The cache is found in the NB / MCH 202 in.

[0048] Those skilled in the art will understand that Figure 1 and Figure 2 The hardware in the may vary depending on the implementation. In addition to or instead of Figure 1 and Figure 2 In addition to the hardware depicted in the drawings, other internal hardware or peripheral devices may be used, such as flash memory, equivalent non-volatile memory, or optical disk drives, etc. In addition, the processes of the example embodiments may be applied to multi-processor data processing systems other than the aforementioned systems without departing from the scope of the invention.

[0049] Furthermore, system 200 can take the form of any of a number of different data processing systems, including a client computing device, a server computing device, a tablet computer, a laptop computer, a telephone or other communication device, a personal digital assistant (PDA), etc. In some illustrative examples, system 200 can be a portable computing device configured with flash memory to provide non-volatile memory for storing operating system files and / or user-generated data. Thus, system 200 can be essentially any known or later developed data processing system, without architectural limitation.

[0050] As described above, the proposed embodiments provide a method and system for controlling transaction requests delivered between applications and servers via a decentralized architecture.By way of further explanation, the proposed embodiments will now be described with respect to a distributed communication system comprising an application 310 and a server 320.

[0051] See also Figure 3 , depicts a schematic diagram of a proposed distributed communication system according to an embodiment. The communication system includes a middleware system 300 for controlling transaction requests between an application 310 and a server 320 according to an embodiment. More specifically, in Figure 3 In the depicted example, the middleware system 300 is configured to intercept and control the delivery of transaction requests between a client application 310 and an MVCC restricted server 320 via a communication network 330 (eg, the Internet).

[0052] The middleware system 300 includes a middleware component 340. The proxy component 340 is configured to define one or more conflict groups for transaction requests based on previously or currently observed transaction conflicts in the distributed communication system at runtime. In other words, the proxy component defines conflict groups based on the runtime history of transaction conflicts.

[0053] Here, the proxy component 340 defines groups such that each conflict group defines multiple transaction requests that would result in transaction conflicts if delivered in parallel.

[0054] In this example, the proxy component 340 includes a receiver component 350 configured to receive information about transaction conflicts and / or further conflicting groups of transaction requests observed in the communication system from a remote component, such as another proxy component 360. The proxy component 340 also uses this received information to define conflicting groups. Figure 3 In the illustrated example of , the proxy component is configured to define conflicting groups of transaction requests based on the received information at runtime as well.

[0055] The broker component 340 also includes a publisher component 355 that is configured to transmit information about the defined conflict groups to one or more remote components (such as another broker 360 and / or a remotely located database 370) (via the network 330). In this manner, the broker component 340 is configured to share information about conflict groups, thereby potentially enabling multiple broker components to collaborate (e.g., combine or aggregate information) to update and / or improve conflict group definitions.

[0056] Based on the conflict group, proxy component 340 is configured to control the delivery of intercepted transaction requests. More specifically, in response to identifying that multiple intercepted transaction requests are members of the same conflict group, proxy component 340 queues the multiple transaction requests to prevent concurrent delivery of the multiple transaction requests. For example, proxy component 340 may queue the multiple transaction requests in a first-in, first-out order. In this manner, if a first transaction request and a second transaction request are members of the same conflict group, proxy component 340 may delay the first transaction request and prevent it from being submitted concurrently with the second transaction request.

[0057] Furthermore, in this example, in response to identifying a transaction conflict caused by delivering the transaction request, the proxy component 340 is configured to redefine the conflict group based on the identified transaction conflict. Further, the proxy component 340 controls the redelivery of the transaction request based on the newly redefined conflict group, rather than aborting the transaction request.

[0058] With further explanation and illustration of the proposed concepts, we will now consider how the proposed embodiments can alter conventional transaction request delivery mechanisms. Conventional mechanisms for submitting transaction requests to a blockchain network typically require invoking the following multi-step process:

[0059] (i) Create Transaction Request - This is a data structure that includes the function to be called in the blockchain network and the arguments / parameters to be provided to the function.

[0060] (ii) Send a transaction request to each node in the "annotated" blockchain network. Each node's smart contract will simulate the processing of this function and generate a read / write set (RWset). This RWset contains the current state and the proposed future state of the relevant portion of the ledger data repository for each node in the blockchain network. The RWset is not actually applied at this stage, but is returned to the requesting client.

[0061] (iii) The client combines the RW sets received from each node and sends them to the blockchain’s ‘ordering service’. The service will perform the following steps:

[0062] a) Check that all RW sets (or enough to satisfy the annotation policy) have the same RW set. At this stage, if they are different, the transaction request can be rejected because one node can have a different read state than the others, indicating that this particular state is in the process of changing in the network (MVCC failure);

[0063] b) If step a) passes, the ordering service creates a 'block', which contains a batch of one or more transactions. This block is cryptographically signed and sent to every peer in the network;

[0064] c) Upon receiving a block, each peer attempts to apply each transaction to its ledger. For each transaction in the block, it checks that the "read" portion of the RW set matches the current read state of its ledger. If they do not match, then the transaction is rejected as an MVCC failure. Note that the actions of the ordering service ensure that all nodes in the network will accept or reject transactions in the same manner; and

[0065] d) Assuming no MVCC failure has occurred, the transaction has now been submitted to the blockchain network.

[0066] Step (iii) detailed above is asynchronous. If the client wants to be notified when the transaction is finally committed to the ledger, the client registers listeners with (multiple) peers to receive notifications of the event.

[0067] When considering how the above-described traditional approach can be modified according to the proposed embodiments, it should be noted that a middleware component (e.g., an integration flow) is placed between the client application and the blockchain network. This is configured to operate as a new proxy component (which can be thought of as a 'submitter' node) that controls the submission of transaction requests to the blockchain in a manner that minimizes or potentially eliminates MVCC failures.

[0068] The proxy component maintains information about different sets of conflict groups, where each transaction request within a group could cause an MVCC failure if submitted concurrently with any other transaction request within the same group. Based on these conflict groups, if more than one transaction request for the same group arrives immediately (e.g., simultaneously or within a predetermined time window), the proxy component delays these transaction requests (e.g., by queuing the transaction requests) until they can be submitted without causing an MVCC conflict. Conflict groups can operate independently of each other, allowing transaction requests from different groups to be processed in parallel.

[0069] As a further example, a proxy component according to an embodiment may be configured to operate as follows:

[0070] - The "Collision Group Definition" property is configured with an expression that determines at runtime the group that each transaction request should be a member of. This can be an expression that uses the content of the transaction request to derive a string value that matches the collision group name.

[0071] If it is determined at runtime that proposals from different groups are causing MVCC failures, a flag can be set to allow the proxy component to dynamically combine groups.

[0072] At runtime, the proxy component can implement the following processes:

[0073] - For each transaction request that arrives at the proxy component, the conflict group definition expression is evaluated to determine which named conflict group it should be placed in. If a conflict group of that name does not exist, it is created.

[0074] - Place the transaction request into the FIFO queue associated with the conflict group.

[0075] - Each conflicting group may then implement the following process (in parallel and independently of every other conflicting group).

[0076] - If the queue is not empty, remove the transaction request from the head of the queue.

[0077] - Perform steps 1 and 2 of the regular blockchain submission process as detailed above.

[0078] -Register commit listener with blockchain peer.

[0079] - Proceed to step 3 of the blockchain submission process.

[0080] -Wait for commit event.

[0081] - Once a successful submission event has been received, the process may start from the beginning (processing the next suggestion on the group queue).

[0082] If the commit event signals an MVCC failure, determine the cause of the failure, and if it was an MVCC failure, determine which other transaction request caused the conflict and which group that other transaction request belongs to. This information can be extracted from the block metadata.

[0083] - If it is a different group, merge the two groups into one group and move the transaction request to the newly merged group for processing. Also publish a message containing information about the group merge so that other proxy component instances can choose to act on the information.

[0084] - Otherwise, resubmit the failed transaction request by repeating the process until it is successfully processed (this is because MVCC failure may still occur if there are other client applications submitting transactions directly, rather than via this integration flow).

[0085] An embodiment may include a computer system 70 that may form Figure 47. For example, a proxy component configured to control transaction requests between an application and a server according to an embodiment may be implemented in computer system 70 (e.g., as processing unit 71). Components of computer system / server 70 may include, but are not limited to, one or more processing devices, such as a processor or processing unit 71, a system memory 74, and a bus 90 that couples various system components (including system memory 74) to processing unit 71.

[0086] System memory 74 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 75 and / or cache memory 76. Computer system / server 70 may also include other removable / non-removable, volatile / non-volatile computer system storage media. In such cases, each may be connected to bus 90 via one or more data media interfaces. Memory 74 may include at least one program product having a set (e.g., at least one) program module configured to perform the functions of the proposed embodiments. For example, memory 74 may include a computer program product having a program executable by processing unit 71 to cause input / output (I / O) interface 72 to perform a method for controlling transaction requests between an application and a server according to the proposed embodiments. A program / utility 78 having a set (at least) of program modules 79 may be stored in memory 74. Program modules 79 generally perform the functions and / or methods of the proposed embodiments for partial write operations to memory.

[0087] The computer system / server 70 may also communicate with one or more external devices 80 (e.g., a keyboard, a pointing device, a display 85, etc.); and / or any device that enables the computer system / server 70 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an input / output (I / O) interface 72. Furthermore, the computer system / server 70 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 73 (e.g., to communicate the determined optimal value of the DFWF to an edge device of the distributed network).

[0088] In the context of this application, when an embodiment of the present invention constitutes a method, it should be understood that such a method is a process for execution by a computer, that is, a computer-implemented method. Therefore, the steps of the method reflect various parts of a computer program, for example, parts of one or more algorithms.

[0089] It is understood in advance that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings cited herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0090] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0091] Features are as follows:

[0092] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0093] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0094] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0095] Rapid Elasticity: The ability to quickly and elastically provision capacity, in some cases automatically scaling down quickly and releasing quickly to scale up quickly. To the consumer, the capacity available for provisioning typically appears unlimited and can be purchased in any quantity at any time.

[0096] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0097] The service model is as follows:

[0098] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications can be accessed from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0099] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and the configuration of the application hosting environment.

[0100] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0101] The deployment model is as follows:

[0102] Private cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0103] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0104] Public cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by the organization that sells cloud services.

[0105] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0106] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that consists of a network of interconnected nodes.

[0107] The present invention may be a system, method and / or computer program product of any possible degree of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.

[0108] Computer readable storage medium can be the tangible device that can retain and store the instruction used for instruction execution device.Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device or above-mentioned any suitable combination.The non-exhaustive list of the more specific example of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, the mechanical encoding device such as punch card or the projection structure in the groove with the instruction recorded thereon and any suitable combination of the above.Computer readable storage medium as used herein should not be interpreted as transient signal itself, such as radio wave or other free propagating electromagnetic wave, electromagnetic wave (for example, the light pulse that passes through fiber optic cable) that propagates by waveguide or other transmission medium or the electric signal that is emitted by wire.

[0109] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0110] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, the configuration data of integrated circuit or source code or object code written in any combination of one or more programming languages, these programming languages ​​include object-oriented programming languages ​​(such as Smalltalk, C++ etc.) and process programming languages ​​(such as " C " programming languages ​​or similar programming languages). The computer-readable program instructions can be performed completely on the user's computer, partly on the user's computer, performed as an independent software package, partly on the user's computer, partly on a remote computer or fully on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer by any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an internet service provider through the internet). In certain embodiments, the electronic circuit comprising for example programmable logic circuit, field programmable gate array (FPGA) or programmable logic array (PLA) can make the electronic circuit personalized to perform computer-readable program instructions by utilizing the state information of computer-readable program instructions, so as to perform various aspects of the present invention.

[0111] The present invention will be described below with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0112] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in the flowchart and / or block diagram or multiple blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in the flowchart and / or block diagram or multiple blocks.

[0113] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in or in multiple boxes in the flowchart and / or block diagram.

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the systems, methods and computer program products according to different embodiments of the present invention. To this end, each box in the flowchart or block diagram may represent a module, segment or portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, the two boxes shown in succession can actually be completed as a step, performed simultaneously, substantially simultaneously, in a partially or completely overlapping manner, or the boxes can sometimes be performed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0115] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A middleware computer system for controlling transaction requests between an application and a server, the middleware system comprising: The proxy component is configured to: defining one or more conflict groups for the transaction request based on previously or currently observed transaction conflicts; as well as controlling parallel delivery of transaction requests based on the one or more conflict groups; The proxy component includes a receiver component configured to receive information about at least one of: Observed transaction conflicts; and Further conflicting groups of transaction requests from the remote component, and wherein the proxy component is configured to define, at runtime, one or more conflicting groups of transaction requests further based on the received information. 2 . The middleware computer system of claim 1 , wherein each of the one or more conflict groups defines a plurality of transaction requests that would result in a transaction conflict if delivered in parallel. 3 . The middleware computer system of claim 1 , wherein the proxy component comprises a publisher component configured to transmit information about the one or more conflict groups to one or more remote components.

4. The middleware computer system of claim 1 , wherein the proxy component is configured to, in response to identifying multiple transaction requests that are members of the same conflict group in the one or more conflict groups, queue the multiple transaction requests to prevent concurrent delivery of the multiple transaction requests. 5 . The middleware computer system of claim 4 , wherein the proxy component is configured to queue the plurality of transaction requests in a first-in, first-out order.

6. The middleware computer system of claim 1 , wherein the proxy component is configured to, in response to identifying a transaction conflict caused by delivery of a transaction request, redefine the one or more conflict groups of the transaction request based on the identified transaction conflict, and control redelivery of the transaction request based on the redefined one or more conflict groups. 7 . The middleware computer system of claim 1 , wherein the middleware system is configured to intercept and control delivery of transaction requests between a client application and a Multi-Version Concurrency Control (MVCC) restricted server.

8. A processor-implemented method for controlling transaction requests between an application and a server, the method comprising: defining one or more conflict groups for a transaction request at runtime based on previously or currently observed transaction conflicts; as well as controlling parallel delivery of transaction requests based on the one or more conflict groups; The method further comprises: receiving information regarding at least one of: an observed transaction conflict; and further conflicting groups of transaction requests from remote components, And wherein defining one or more conflict groups of the transaction request is further based on the received information.

9. The method of claim 8, wherein each of the one or more conflict groups defines a plurality of transaction requests that would result in a transaction conflict if delivered in parallel.

10. The method according to claim 8, further comprising: Information regarding the one or more conflicting groups is communicated to one or more remote components.

11. The method according to claim 8, further comprising: In response to identifying a plurality of transaction requests that are members of a same conflict group of the one or more conflict groups, the plurality of transaction requests are queued to prevent concurrent delivery of the plurality of transaction requests.

12. The method of claim 11, wherein queuing the plurality of transaction requests comprises queuing the plurality of transaction requests in a first-in, first-out order.

13. The method according to claim 8, further comprising: In response to identifying a transaction conflict caused by delivery of the transaction request, redefining the one or more conflict groups of the transaction request based on the identified transaction conflict; as well as Re-delivery of the transaction request is controlled based on the redefined one or more conflict groups.

14. The method of claim 8, wherein the method is configured to intercept and control delivery of transaction requests between a client application and a Multi-Version Concurrency Control (MVCC) restricted server.

15. A computer program product comprising a computer-readable tangible storage medium having program instructions embodied therewith, the program instructions being executable by a processing unit to cause the processing unit, when executed on a computer network, to perform a method for controlling transaction requests between an application and a server, wherein the method comprises the steps of: At runtime: by means of a proxy component, one or more conflict groups for a transaction request are defined based on previously or currently observed transaction conflicts; as well as controlling parallel delivery of transaction requests based on the one or more conflict groups; The proxy component includes a receiver component configured to receive information about at least one of: Observed transaction conflicts; and Further conflicting groups of transaction requests from the remote component, and wherein the proxy component is configured to define, at runtime, one or more conflicting groups of transaction requests further based on the received information.

16. The computer program product of claim 15, wherein each of the one or more conflict groups defines a plurality of transaction requests that would result in a transaction conflict if delivered in parallel.

17. The computer program product of claim 15, further comprising: Information regarding the one or more conflicting groups is communicated to one or more remote components.

18. A computer system comprising at least one processor and a computer program product according to claim 15, wherein the at least one processor is adapted to execute the computer program code of the computer program product.

Images