W przypadku komunikacji poprzez MQ rozróżniamy kilka rodzajów komunikatów. Komunikat REQUEST określa komunikat będący zapytaniem do innego systemu. Jako przykład można tu przytoczyć aplikacje, która pobiera z innego systemu dane o kliencie. W takim przypadku wysyła ona komunikat z zapytaniem o konto klienta. Kiedy taki komunikat z zapytaniem dotrze do tego docelowego systemu, wysyła on (docelowy system) w odpowiedzi komunikat z danymi o kliencie, z typem komunikatu ustawionym na REPLY. Typ REPLY to drugi typ komunikatu określający, że dany komunikat jest odpowiedzią na odebrane przez aplikacje zapytanie. Przy tego typu komunikacji (REQUEST-REPLY) należy jeszcze określić na jakie zapytanie dany komunikat jest odpowiedzią. Używa sie do tego dwóch parametrów komunikatów JMS, MessageId oraz CorrelationId. Kiedy aplikacja wysyła zapytanie menadzer kolejek ustawia w nim parametr MessageId, określający identyfikator komunikatu. Następnie kiedy aplikacja do której komunikat był skierowany odczyta go i będzie chciała wysłać odpowiedź, to przy wysyłce poza ustawieniem typu komunikatu na REPLY, przepisze z zapytania parametr MessageId do parametru CorrelationId odpowiedzi. Operacja taka nazywa się korelacją. W ten sposób aplikacja, która odbierze komunikat REPLY, przez analizę jego parametru CorrelationId będzie wiedziała, jaki jest identyfikator wysłanego przez nią komunikatu REQUEST, do którego odnosi sie ta odpowiedź. Biorąc pod uwagę kwestie projektowe mamy dwie możliwości implementacji takiej komunikacji. Pierwszy sposób, to podejście synchroniczne. Polega ono na tym, ze aplikacja po wysłaniu komunikatu typu REQUEST odczytuje jego parametr MessageId, następnie przy pobieraniu komunikatu z kolejki wejściowej, określa, żeby nie pobierać pierwszego komunikatu z kolejki, tylko komunikat, którego parametr CorrelationId równa się wcześniej odczytanemu parametrowi MessageId z zapytania. Drugim rozwiązaniem jest podejście asynchroniczne. Polega ono na tym, że jednym wątkiem są wysyłane komunikaty REQUEST i do współdzielonej pamięci zapisywane są dane tych komunikatów, wraz z ich identyfikatorem, innym natomiast są pobierane po kolei wszystkie komunikaty, a następnie procesowanie komunikatów typu REPLY poprzedzone zostaje sprawdzeniem we wspomnianej wcześniej pamięci współdzielonej na jakie zapytanie jest to odpowiedź.

Innym rodzajem typu komunikatu jest typ DATAGRAM. Określa on komunikat standardowy nie powiązany z żadnym innym. Może być on użyty (i najczęściej tak się dzieje) np. przy wysyłaniu komunikatu synchronizacyjnego informującego o zmianach jakie nastąpiły w systemie macierzystym, a co może zainteresować inne systemy. Jest to przykład typowej komunikacji asynchronicznej.

W przypadku pobierania komunikatów z kolejki mamy możliwość określenia, czy operacja ta ma być blokująca, czy nie. Oznacza to, czy w przypadku operacji odczytu komunikatu z kolejki i braku w niej komunikatów aplikacja ma czekać na pojawienie się komunikatu przez jakiś czas, czy czekać aż komunikat się pojawi, czy w takiej sytuacji natychmiast powrócić z metody z błędem informującym, że w kolejce nie ma żadnych komunikatów.

Parametry komunikatów