When the overall structure of the distributed process has been decided, you can then start to design individual conversations. Designing a conversation involves deciding which functions to put into the front-end transaction and into the back-end transaction, and deciding what should be in a distributed unit of work. So you have to make decisions about how to subdivide the work that is to be done for your application.
Because a conversation involves transferring data between two transactions, to function correctly, each transaction must know what the other intends. For example, little advantage is gained by the front-end transaction's sending data if all the back-end transaction is designed to do is print the weekly sales report. You must therefore consider each front-end and back-end transaction pair as one software unit.
The sequences of commands that you can issue on a conversation are governed by a protocol that is designed to ensure that commands are not issued in inappropriate conditions. The protocol is based on the concept of several conversation states. A conversation state applies only to one side of a single conversation and not to a transaction as a whole. In each state, are several commands that might reasonably be issued. The command itself, together with its outcome, might cause the conversation to change from one state to another.
To determine the conversation state, you can use either the STATE option on a command, or the EXTRACT ATTRIBUTES command.
When a conversation changes state, it is said to have undergone a state transition, which generally makes a different set of commands available. The available commands and state transitions are shown in a series of state tables. Which state table you use depends on the synchronization level chosen.
For more information, see How to use the state tables.