Asynchroniczna komunikacja aplikacji staje się regułą ich skutecznego współdziałania.

Do komunikacji między aplikacjami w rozproszonym środowisku przetwarzania stosuje się najczęściej zdalne wywołanie procedur (Remote Procedure Call - RPC). RPC zestandaryzowano w wielu środowiskach przetwarzania, w tym DCE (Distributed Computing Environment). Jednakże to podejście, niezależnie od tego na ile przejrzyste i standardowe, ma wadę: RPC jest mechanizmem komunikacji synchronicznej, blokującej aplikację na czas otrzymania odpowiedzi. W efekcie aplikacja wchodzi w martwą pętlę, nie wykorzystuje zasobów procesora, nawet jeśli chodzi o czekanie na prosty komunikat błędu. Jest to sytuacja dość absurdalna, jako że nie wszystkie konwersacje między aplikacjami wymagają natychmiastowej odpowiedzi.

W większości przypadków wystarczy zwykłe upewnienie się, że komunikat dotarł do odbiorcy, aby system działał poprawnie. Zarządzanie kolejkami komunikatów jest jedną z najstarszych technik, wykorzystywanych już w wielkich systemach do obsługi komunikacji między terminalami a jednostką centralną.

W systemach bardziej współczesnych asynchroniczna obsługa komunikatów jest ściśle związana z niejednorodnością sprzętową i systemową oraz z pojawieniem się i rozwojem systemów klient/serwer. Pakiety komunikacji asynchronicznej zajmują się także obsługą kolejek, zwalniają aplikacje z obowiązku czekania na odpowiedź oraz zajmują się kierowaniem komunikatów. Pakiet tworzy więc luźne sprzężenie między aplikacjami, i to tym luźniejsze, o ile aplikacje mają także możliwości komunikacji synchronicznej w celu wymuszonego uzyskania odpowiedzi.

MQSeries na czele

Zalety komunikacji asynchronicznej skłoniły wielu producentów do opracowania narzędzi komunikacji asynchronicznej między aplikacjami. Już w roku 1985 pakiet DECMessageQ wytypowano do standaryzacji komunikacji asynchronicznej przez ISO. Jednakże na czele stawki znajduje się pakiet komunikacyjny MQSeries firmy IBM (zakupiony w 1994 r. od System Strategies Inc. - SSI). Rozwojem MQSeries zajmują się laboratoria IBM w Hursley (W. Brytania), wytwarzające także monitor transakcji CICS. MQSeries jest dostępne na ponad dwudziestu platformach, nie tylko IBM-owskich.

MQSeries zajmuje się przesyłaniem w sposób asynchroniczny komunikatów między aplikacjami w środowisku niejednorodnym. W celu wykorzystania jego możliwości programista posługuje się niewielką liczbą poleceń MQI (otwórz/zamknij kolejkę, odbierz/wyślij komunikat, połącz/rozłącz i in.), pozwalających mu doglądać komunikaty. Mechanizm obsługi ma charakter FIFO (pierwszy w kolejce jest obsługiwany jako pierwszy), ale aplikacje mogą pobierać komunikaty z dowolnego miejsca kolejki.

Technicznie MQSeries składa się z dwóch elementów: interfejsu programistycznego MQI i biblioteki DLL, zajmującej się obsługą kolejki. Po otrzymaniu komunikatu z aplikacji, MQSeries umieszcza go w kolejce i próbuje wysłać do zdalnej lokalizacji. Komunikat jest usuwany z kolejki dopiero po otrzymaniu odpowiedzi z lokalizacji zdalnej.

Możliwe jest zadanie parametrów, np. "Jeżeli komunikat nie zostanie wysłany przed godziną 10, usuń go z kolejki". Jeżeli dostarczenie komunikatu okaże się niemożliwe, pakiet MQSeries generuje odpowiedni komunikat. W niektórych przypadkach programiści wykorzystują pakiet lokalnie, nawet bez sieci, aby zachować jednolitą strukturę aplikacji lokalnych i zdalnych.

Inni producenci

Oprócz wspomnianych już IBM i DEC, pakiety do komunikacji asynchronicznej dostarczają komercyjnie także Peerlogic (pakiet Pipes), Covia Technologies (pakiet Communication Integrator) oraz Momentum Software (pakiet XüIPC).

Zalety komunikacji asynchronicznej

Aby aplikacja korzystająca z komunikacji asynchronicznej mogła działać poprawnie, nie jest potrzebna dostępność zdalnego komputera. Ma to szczególne znaczenie w przypadku obsługi wielu lokalizacji rozrzuconych w różnych strefach czasowych oraz obsługi użytkowników w ruchu. Jeżeli nawet użytkownik nie ma chwilowo dostępu do sieci, to z chwilą podłączenia się do niej dostanie wszystkie wysłane do niego komunikaty. I nie dotyczy to tylko poczty, ale przede wszystkim transakcji na używanej przez niego bazie danych, uaktualnianej zdalnie za pośrednictwem komunikatów.