The programmer can choose from three communication paradigms for client/server communication:
synchronous request response paradigm: single-step dialog.
The client is blocked after sending the service request until it receives a response.asynchronous request response paradigm: single-step dialog.
The client is not blocked after sending the service request.conversational paradigm: multi-step dialog.
Client and server can exchange data in any way required.
The XATMI functions required for these communication paradigms are described only briefly below; C notation is used here. An exact description of the XATMI functions can be found in the X/Open Specification “Distributed Transaction Processing: The XATMI Specification”.
Synchronous request-response paradigm
The client only needs one single tpcall() call for the communication.
The tpcall() call addresses the service, sends precisely one message to this service, and waits until it receives a response, i.e. tpcall() has a blocking effect.
Figure 17: Synchronous request response paradigm
In this diagram, svc is the internally used service name, svcinfo is the service info structure with the service name, and tpservice is the program name of the service routine. The service info structure is part of the XATMI interface.
With this paradigm, a dialog TAC for the requested service has to be generated on the UTM server side.
Asynchronous request-response paradigm
With this paradigm, communication is handled in two steps. In the first step, a tpacall() call is used to address the service and send the message. In the second step the response is fetched with tpgetrply() at a later stage, see diagram below.
Figure 18: Asynchronous request response paradigm
In this diagram, svc refers to the internally used service name, cd is the communication descriptor in the specific process, svcinfo is the service info structure with the service name, and tpservice is the program name of the service routine.
tpacall is non-blocking, i.e. the client can carry out other local processing tasks in the meantime. However, the client cannot call another service, as only one job is permitted at any one time with the UPIC carrier system.
If the client is to engage several services in parallel, you must use the OpenCPIC carrier system.
In contrast, tpgetrply is blocking, which means that the client waits until the response is received.
With this paradigm, a dialog TAC must be generated for the service on the UTM server side (as with synchronous request-response).
Conversational paradigm
XATMI offers the conversational paradigm for connection-oriented tasks (“conversations”).
This paradigm can be used, for example, to transfer large volumes of data in several substeps. This avoids problems which can occur in the synchronous request response paradigm (call tpcall() ) due to the limited size of the local data buffers.
In the conversational paradigm, the conversation is explicitly established to a service with the tpconnect call. As long as the conversation exists, the client and server can exchange data with tpsend and tprecv. However, this “dialog” is not a dialog in the sense of OSI TP, and only one transaction can be processed.
The conversation is terminated when the server signals the end with tpreturn; the client then receives a corresponding code with tprecv in the tperrno variable. The client program must therefore contain at least one tprecv call.
Figure 19: Conversational paradigm
In this diagram, svc refers to the local name of the service, cd is the communication descriptor in the specific process, tpservice is the program name of the service routine, and svcinfo is the service info structure with the service name and the communication descriptor.
With this paradigm, a dialog TAC must be generated for the service on the UTM server side.
In the event of errors, the client can force a conversation abort with the tpdiscon call.