Hintergrundaufträge können nicht nur an Asynchron-Services der lokalen Anwendung gestellt werden, sondern auch an Asynchron-Services ferner Anwendungen.
Hier zeigt sich eine der Hauptstärken der MQ-Funktionalität von openUTM, d.h. openUTM arbeitet bei Hintergrundaufträgen an ferne Anwendungen mit zwei jeweils lokalen Queues: eine Queue liegt dabei in der Sender-Anwendung, die andere Queue beim Empfänger. Durch dieses Deferred Delivery-Prinzip ist das Rechner-übergreifende Message Queuing mit openUTM vollständig unabhängig davon, ob gerade eine Verbindung möglich ist oder nicht: Falls keine Verbindung aufgebaut werden kann, bleibt der Auftrag solange in der lokalen Sender-Queue, bis eine Verbindung hergestellt ist.
Auch beim Remote Queuing müssen Sie sich nicht um den Queuing-Mechanismus kümmern. Sie geben lediglich an, für welchen Asynchron-Service die MQ-Nachricht bestimmt ist. Ferne Asynchron-Services werden auf die gleiche Weise adressiert wie auch ferne Dialog-Services, was das Design verteilter Anwendungen erleichtert.
Bild 24: Remote Queuing mit openUTM
Bild 24 zeigt, wie ein Hintergrundauftrag an eine ferne Anwendung von openUTM behandelt wird. Das Bild macht auch deutlich, dass Remote Queuing in vielen Fällen eine sinnvolle Alternative zur verteilten Dialogverarbeitung darstellt: Die Kommunikation zwischen den beiden Services gliedert sich in drei transaktionsgesicherte Schritte. Sobald der Auftrag in die lokale Queue der Anwendung A eingetragen ist, können die benötigten Betriebsmittel in Anwendung A freigegeben und eventuell gesetzte Sperren in Resource 1 wieder aufgehoben werden - auch wenn das Netz gerade nicht verfügbar ist oder die Anwendung B nicht läuft.
Würde eine solche Kommunikation innerhalb einer Dialog-Transaktion abgearbeitet werden, bestünde die Gefahr lang anhaltender Sperren und „hängender“ Transaktionen. Durch die Kommunikation über Remote Queuing kann vermieden werden, dass lokale Störungen oder Ausfälle zu übergreifenden, länger andauernden Blockaden führen.