There are a number of mechanisms by which the client may pass messages to the workflow controller. The first way is to use the transactional RPC mechanism. This makes the request look like a local procedure call. The second uses peer-to-peer communication. This puts a greater burden on the programmer, but provides more complex patterns of communication. As an alternative, you may want to build a transactional message queue as an interface between the client and the workflow controller.
Queues are one of the fundamental data structures in C++ programming. The Standard Template Library (STL) offers a variety of queue-like structures. A container accepts component items (in this case, request messages), stores them, and returns them upon demand. A queue is a container that returns items in the order in which they were received (first in, first out, or FIFO). A priority queue is a container that allows messages to define a sort-order, and returns items based on their order in the queue. A persistent message queue is a message queue that can survive a program or system crash. A transactional queue understands transactional semantics (commit, roll-back, etc.).
Queued transaction processing requires a transactional, ordered, persistent message queue. This includes participating in the protocols that define how transactions are started, committed and aborted. It also means participating in the protocols that define how the system is restarted after a failure and how permanent media such as disk are restored after a failure.
There are several advantages to using a queue for message requests to a TP system:
The architecture typically includes a queue manager that functions as a TP resource manager, a request queue and a response queue. The response queue may be logically or physically segregated by the client workstation or cluster in which it is located.
The server requires one transaction to process a queue element. After the transaction starts, the message queue provides the server with the highest priority request, which is processed by that server, based on the message type. The server processes the message and puts the result on the response queue. The server then ends the transaction. If the transaction rolls back, then the response is removed from the response queue, and the request is added back to the request queue, where it will be processed the next time.
The client runs one transaction to submit the request to the server. After the server transaction puts the result on the response queue, the client runs a third transaction to obtain the result. Committing this third transaction releases the queue element from the response queue. The net effect is that the request is processed under correct conditions or error conditions, and always results in either a response to the caller or an exception being generated.