Finally we shall look at cases in which a service (B) communicates with a job submitter (A) and a job receiver (C) via the OSI TP protocol using Chained Transactions. Compared to the previous cases, only the intermediate node B is in a new situation since it possesses both a job submitter A and a job receiver C.
When the OSI TP protocol is used, an intermediate node is not free to decide when an end of transaction or end of dialog is to occur. This also applies to dialogs with its job receiver. The intermediate node B cannot request end of transaction or end of service from job receiver C until B itself has received an end-of-transaction request from its job submitter.
The following examples depict individual, characteristic situations. There are numerous other possibilities which can be constructed by combining the cases described in the sections above.
Data transfer phase
The data transfer phase is the period in which no CTRL calls are issued by any of the partners, and the program runs are terminated exclusively by PEND KP.
Example 12: Data transfer phase in multi-step transfer trees.
B need not always communicate with A and C in alternation, as is the case in this example. B can also conduct multiple dialog steps consecutively with C or communicate exclusively with A before reintegrating C into the communication.
However, it is important to note that B may not send messages to A and C simultaneously. An intermediate node may pass the send authorization either to the job submitter or to one or more job receivers, but not to the job submitter and a job receiver at the same time.
A service may transfer the end-of-transaction send authorization for a maximum of one dialog.
End of transaction
After B has received the end-of-transaction request from A, it has 3 options:
B can send a message to C and simultaneously request C to terminate the transaction(see also examples 12, 14, 15)
B can continue the data transfer phase with C and request C to terminate the transaction in a later processing step. (see also example 13)
B can refrain from further communicating with C in the current transaction and itself request end of transaction. (see also example 16)
A, B or C may own the end-of-transaction send authorization.
Example 13: End-of-transaction send authorization is owned by A
In the example above, B cannot pass the end-of-transaction send authorization to C since A has not yet passed the end-of-transaction send authorization to B.
Example 14: B continues the dialog with C - end-of-transaction send authorization is owned by A
In this example, B does not initially request C to terminate the transaction and, instead, continues the data transfer phase with C. In this example only one more dialog message is exchanged. However, it would be possible to continue the data transfer phase beyond this. In this case, B and C can only use PEND KP to terminate the program runs. At some time B must request C to end the transaction.
In this example, again, B cannot pass the end-of-transaction send authorization to C since A has not yet transferred the end-of-transaction send authorization to B.
Example 15: End-of-transaction send authorization is owned by B
Example 16: End-of-transaction send authorization is owned by C
Example 17: No message to job receiver before end of transaction
In this example, B refrains from sending another message to C in the current transaction, and requests end of transaction immediately.
After PEND RE from node B, an MPUT message is sent to A and a PREPARE protocol element is sent to C. This requests C to terminate the transaction. C does not then receive any further user messages. The MGET call at C simply reads the status of the dialog with B. This call can be omitted.
End of dialog
An intermediate node can bring about the job-submitter-based end of dialog in the same way as an end of transaction. These possibilities are depicted in the two examples below.
Example 18: B first terminates the dialog with the job receiver.
Example 19: Simultaneous end of dialog with job receiver and job submitter.
