Browse Prior Art Database

Distributed transactional conversation system utilizing interprocess network communication

IP.com Disclosure Number: IPCOM000238234D
Publication Date: 2014-Aug-12
Document File: 4 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database

Abstract

The solution allows the building of inexpensive distributed transactional systems to use in cloud based applications, introducing a notion of a conversation which includes multiple communications between applications, within a context of a single transaction. The system proposed utilizes standard features of JMS[1], as well as WebSockets[2] and/or MQTT[3]. The above solutions are platform-specific and are therefore only applicable to homogeneous systems. The proposed system can be deployed in any environment that supports at least JMS.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 01 of 4

Distributed transactional conversation system utilizing interprocess network communication

The problem:

    There are multiple applications of different types. These applications have interactions of a complex type, where a single operation, such as single request R from an entity A to entity B may cause a chain of request/response between these entities resulting in a final completion of the initial request. The other way to look at this is to assume that the overall lifecycle of the R is covered by two transactional contexts both on A and B. These contexts are not governed by a single transaction manager.

    The interactions within the processing cycle R can, for example, be of a data validation nature, when entity B requests additional data from A in order to complete the request. Or entity B is changing data on A side as well as modifying its own data.

    Both participants should commit their transactions at the end of the request. Equally, both participants should recover from a transaction failure on either side. Communication failure, including disappearance of either participant should cause rollback as well, at least on the surviving side.

    The assumption should be made that either application could be deployed in high-availability mode - either a cluster of equal nodes or in a cloud. The transactional context obviously can and should be maintained on a single node on either side for the duration of the R.

    Some further developments could be made including participation of more than two different types of application in a single request. So A calls to B, B calls to C etc.

    There are existing solutions to the problem. ActiveMQ provides a notion of conversation allowing synchronization of distributed systems. IBM WebSphere has a distributed transaction manager also. Both of these solutions are specific to the platform, so are non-portable.

    This description below is for 2 participants only. The multiple participants extrapolation will be described below. Also, this interaction only utilizes features of JMS. An alternative interaction can be accomplished with WebSockets, for example, and will be outlined also. That could be used as an example of an additional embodiment of this disclosure.

    Assumption is that each of the participants can have multiple instances running simultaneously, for instance as nodes in a cluster, providing high availability and load balancing. In particular, load balancing is achieved by using a single JMS Queue shared between multiple nodes. A mirror arrangement will exist on both sides, each one listening to its own Queue.

    Entity A requires some processing to be done. A database transaction (TxA) is started to cover this processing. As a part of the processing a call to entity B is required.

    The Queue Q1 is used to submit the initial request from entity A to entity B. One, and only one, of instances of B will pick the message from the Q1 and start processing it. A transaction TxB is started on B side.

    We assume t...