Temporary queues are created by means of a program call and can also be deleted again by means of a program. The name of the queue is assigned when the queue is created (i.e. it does not have to be generated). The name can be created by the program or by openUTM.
In the case of UTM-S, temporary queues remain after an application is terminated unless they are deleted explicitly beforehand. In the case of UTM-F, all temporary queues are lost when the application is terminated.
Temporary queues are particularly suitable for free communication between mutually independent services (“free” dialog), and they embody the concept of synchronous waiting for asynchronous events particularly well. They are thus considered to be at some point between the concepts of the “strict dialog” and the “background jobs”.
The services can either reside within an application or be located on different systems. The following are two important applications of this concept:
the dialog between two services in a UTM application
the dialog of a UTM application with a remote transport system application
These two applications are explained below and illustrated graphically.
In the first example, the “Customer” service of a call center application looks for additional customer data by means of the asynchronous service “Search”. This writes the data to a temporary queue, which is used in this case as a pure reply queue (i.e. data transfer goes in one direction only).
Figure 27: Communication between two services by means of a temporary queue
The “Customer” service creates the temporary queue and forwards the name of the queue in the job to the “Search” service. The “Customer” service then engages in further dialog queries with the client, while the “Search” service carries out a database query in the background. If necessary, the “Customer” service waits for the reply from the “Search” service (synchronous waiting). When it receives the required data, it writes it to the queue and then terminates. As soon as the message is in the queue, “Customer” is activated, takes over subsequent processing and then deletes the queue.
In the second example, a UTM application wants to access the data of a remote transport system application. As a pure transport system application, this cannot use any higher-level protocols such as OSI TP or LU6.1 for communication. In order to enable a dialog in spite of this, temporary queues are used on the UTM side.
Figure 28: Communication with a transport system application by means of a temporary queue
The “Shares” service creates the temporary queue and forwards the name of the queue to the transport system in the job. The “Shares” service then waits for the reply (synchronous waiting). In the meantime, the transport system application obtains the required data and sends it to the “Invest” application. The name of the queue must be at the beginning of the message. The “Shares” service is activated as soon as the message is in the queue. The queue is deleted on completion of processing.
| The openUTM manual „Programming Applications with KDCS” describes how to create and delete temporary queues. To find out how to specify the maximum number and properties of temporary queues, refer to the openUTM manual “Generating Applications” (look for the keywords QUEUE and temporary queue). |
