Message queuing (MQ) is a form of communication in which messages are not exchanged immediately, rather are buffered in intermediate queues before being dispatched. openUTM offers sophisticated message queuing functions through the concept of asynchronous processing.
The term “asynchronous” refers to a type of programming in which a program sends a message but need not wait for a response from the receiver program (non-blocking conversations). (non-blocking conversations). openUTM supports this programming style, of course, but it also offers a wide and subtly differentiated range of control options. Depending on who is responsible for processing the messages in a queue, a distinction is drawn between UTM-controlled queues and service-controlled queues.
UTM-controlled queues
A UTM-controlled queue is a message queue in which the retrieval and further processing of the messages is controlled entirely by openUTM. UTM-controlled queues are used for background jobs and output jobs. All MQ functions are available to both the sender and the recipient, which is why you do not have to generate or configure such queues and their queue managers separately or create any special triggering or polling mechanisms.
Service-controlled queues
A service-controlled queue is a message queue in which the retrieval and further processing of the messages is controlled by services. In other words, the recipient of the message is responsible for reading and processing it. The following types of service-controlled queue exist: USER queues, TAC queues and temporary queues:
A USER queue is a user-specific message queue. A separate USER queue is automatically available to every UTM user. You can use USER queues to implement mailbox mechanisms for UTM users, for example.
A TAC queue must be generated explicitly by means of KDCDEF (exception: dead letter queue). TAC queues can be addressed using their generated names by any service. TAC queues are used, for example, to forward UTM messages to the WinAdmin graphical administration workstation or to the Web application WebAdmin and archive them there.
A temporary queue is created dynamically by a program and can also be deleted by a program. With temporary queues it is possible, for example, to implement a dialog between two independent services.
Deferred delivery mechanism with transaction management
openUTM works with the transaction-based deferred delivery mechanism in all message queues: the sender and recipient can run at different times and in different places, and the transmission of the message is guaranteed, regardless of whether or not there is a network connection. Messages are entered in a queue and stored there until the line and the recipient are ready. openUTM also offers additional flexibility in that time control and priority scheduling can be used in message queuing, and maximum wait times can be defined for service-controlled queues.
Dialog processing and message queuing can be combined as desired. MQ jobs can be initiated within a dialog service, and a service program started asynchronously can engage in a synchronous conversation with a remote dialog service. Long-running or non-time-critical jobs (e.g. slow print jobs, lengthy statistical calculations, sort operations, etc.) can be performed independently of the online dialog, without having to sacrifice the transaction processing capability.
Implementing modern concepts
Thanks to its message queuing functionality, openUTM is ideally suited to modern concepts, such as workflow strategies: operational procedures are divided into steps and intermediate states are passed from one application to the next. The sender program does not necessarily wait for a response from the receiver, and the next step may not be started immediately. However, it must be ensured that the intermediate state is actually received by the target program. This is the responsibility of the UTM transaction-oriented queuing mechanism. Even if the network is currently unavailable or the receiver application is offline, openUTM guarantees that no message will be lost or duplicated.
This independence from the quality and availability of connections means that openUTM forms a reliable middleware base for mobile computing. Mobile clients (e.g. applications) running on laptops can interact with servers without a permanent physical connection. Blocked transmission is made possible through the local, transaction-oriented collection of messages. Connection times are thus reduced and line costs kept to a minimum.
By using USER queues and TAC queues you can develop finely tuned concepts for mailbox systems and alarm mechanisms that include the clients, as well. This makes things much easier for the users of the application – both for customers and administrators – and thus means that the application is better received by users and that the security of the investment for the future is improved.
openUTM’s message queuing functions also offer effective support for the implementation of data warehousing solutions and decision support systems. These applications generally work with vast, heterogeneous information pools, and involve linking and analyzing in-house and often external databases from the most varied IT systems. The information must be accessible to a large number of users. Since message queuing allows you to separate particularly long-running jobs from dialogs, openUTM ensures fast response times. In the case of pure retrieval applications in which restarting does not play such an important role, it is possible to use the UTM-F (Fast) variant (see section "Restart with UTM-F").
| Further information on message queuing can be found in chapter "Message queuing". |
