It is possible to send background jobs not only to asynchronous services of the local application, but also to asynchronous services of remote applications.
This is where one of the main strengths of the openUTM MQ functionality comes to the fore. In the case of background jobs sent to remote applications, openUTM works with two local queues: one in the sender application and the other in the receiver application. Thanks to this deferred delivery principle, distributed message processing with openUTM will continue to operate regardless of whether or not a connection is currently possible. If a connection cannot be established, the job remains in the local sender queue until the connection has been set up.
With remote queuing, you need not concern yourself with the queuing mechanism. You simply specify the asynchronous service for which the MQ message is intended. Remote asynchronous services are addressed in the same way as remote dialog services. This simplifies the design of distributed applications.
Figure 24: Remote queuing with openUTM
In figure 24, you can see how openUTM handles a background job sent to a remote application. This diagram also illustrates how remote queuing is often a practical alternative to distributed dialog processing. Communication between the two services is divided into three transaction-oriented steps. As soon as the job is entered in the local queue of application A, the required resources can be released in application A, and any locks set in resource 1 can be canceled - even if the network is currently unavailable or application B is not running.
If this form of communication were to be implemented within a dialog transaction, you run the risk of incessant locks and “hanging” transactions. By using remote queuing, however, it is possible to avoid ongoing global blockades caused by local errors or crashes.