 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| C/C++ / CGI / Sieć Novell / PHP / Java / SQL / Oracle / WebSphere MQ / WebSphere Message Broker / JavaScript / Humor / IT Quiz | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
Informacje podstawowe O WebSphere MQ Komunikacja synchroniczna i asynchroniczna Systemy kolejkowe * Kolejki MQ Aliasy MQ * Kanały MQ Automatycznie generowane kanały kanałów Inne obiekty MQ (Service, Listener) Multi-hopping * Powielanie kanałów * Ciekawsze komendy MQ Rodzaje komunikatów MQ Persystencja komunikatów Priorytety komunikatów Triggering Traceroute komunikatów MQ i rozszerzenie Web Services * Klastry MQ Komunikaty fast nonpersistent * Kanały in doubt * SSL Transakcje MQ Monitorowanie MQ Backup MQ Serwisy MQ Reference messages Accounting and Statistics Real-time monitoring Raporty activity MQ Events DLQ Handler Exity Połączenie do menadżera komunikatów Otwieranie kolejki * Czytanie z kolejki * Zapis do kolejki Komunikacja Publish-Subscribe Distribution Lists (Listy dystrybucyjne) Segmentacja komunikatów * Grupowanie komunikatów Raportowanie Tablica definicji kanałów klienckich (client channel definition table) Kompresja komuniktów JMS *Enterprise Service Bus na Was 6 Monitorowanie MQ Bezpieczeństwo Literatura Jeden plik Legenda w przygotowaniu * w trakcie tworzenia Podczas tego kursu postaram się omówić narzędzie WebSphere MQ firmy IBM. Kurs ten jest w trakcie tworzenia i może się zdarzyć, że informacje w nim zawarte mogą wydawać się chaotycznie posegregowane. Nie będzie on również omawiał narzędzia od podstaw, lecz najciekawsze według mnie jego elementy, dlatego może się okazać, że dla osób nie znających chociaż podstaw WebSphere MQ będzie on niezrozumiały. Będę starał się cały czas rozwijać go ponieważ jest to moja specjalizacja (systemy kolejkowe) i docelowo kurs ten będzie zawierał podstawowe informacje jak również zaawansowane dla osób znających temat. Na dzień dzisiejszy jest w nim trochę informacji podstawowych oraz trochę informacji wchodzących głębiej w charakterystykę narzędzia. Ze względu na specyfikę możemy rozróżnić dwa sposoby komunikacji, komunikacja synchroniczna i asynchroniczna. Komunikacja synchroniczna, to standardowy sposób komunikacji, kiedy to wysyłając zadanie blokując czekamy ze zwróceniem interfejsu do klienta, aż zadanie zostanie przetworzone. W przypadku krótkich transakcji taka sytuacja jest do przyjęcia, jednak w przypadku bardzo długich transakcji nie ma ona racji bytu. Weźmy na przykład zadanie wygenerowania raportu, którego przetworzenie trwa długi czas. W takiej sytuacji nie miałoby sensu aby użytkownik systemu przez ten okres nie mógł nic zrobić w aplikacji. W takich właśnie sytuacjach stosuje sie komunikacje asynchroniczna. Polega ona na tym ze wysyłane jest tylko zadanie wykonania zadania ( w naszym przypadku będzie ta zadanie wykonania raportu ) i zaraz potem następuje zwrócenie interfejsu do klienta, a wtedy można wykonywać inne operacje w aplikacji. Oczywiście należałoby tu zapewnić funkcjonalność pozwalającą na stwierdzenie, jaki jest status zadania, czy też, w przypadku zakończenia przetwarzania pozwalającą na pobraniu wygenerowanych danych. Wybór odpowiedniej metody komunikacji ma duże znaczenie przy integracji aplikacji, jak również na kwestie wydajnościowe. Będąc w temacie integracji warto tu zauważyć, że poza ustaleniem typu komunikacji (synchroniczna, czy asynchroniczna) ważnym elementem jest dobranie formy transportu danych. Mamy tu szeroki wachlarz możliwości: FTP, baza danych, płaski plik, połączenie TCP/IP, itp. W tej całej gamie możliwości wskazane jest aby wybrać jeden, góra dwa standardowe sposoby integracji. Skraca to czas tworzenia aplikacji a co za tym idzie obniża koszty. Dzieje sie tak dlatego, że jeśli ograniczymy ilość sposobów integracji nie będziemy musieli przy nowych aplikacjach tworzyć modułów odpowiadających za komunikacje, ponieważ będą one już gotowe. Dla aplikacji J2EE takim sposobem komunikacji może być technologia Web Services lub JMS. Oczywiście nie należy popadać w skrajność i do każdego rodzaju komunikacji używać wybranego standardu. Mogą istnieć nietypowe wymagania, gdzie okaże się, że lepszym rozwiązaniem jest wykorzystanie innego sposobu przesyłania danych. Jako przykład można tu przytoczyć przesłanie bardzo dużej ilość danych. W takim przypadku może się okazać, że lepszym i bardziej wydajnym rozwiązaniem może być np. FTP. Do najważniejszych zalet takich systemów jest to, że podczas komunikacji nie jest wymagane aby w tym samym czasie oba komunikujące się ze sobą systemy działy. Aplikacja wysyłająca komunikat informujący o zmianie w swoim systemie wysyła go do swojej kolejki wyjściowej nie wiedząc, czy aplikacja docelowa jest uruchomiona, czy nie i czy komunikat został już przetworzony. W zadzie nawet ją to nie interesuje. Niezależnie, czy aplikacja docelowa działa, czy nie, komunikat pozostaje w jej kolejce. Kiedy aplikacja docelowa zostanie uruchomiona może przeczytać komunikat i wykonać odpowiednie działania. Do omówienia zasady działania takich systemów kolejkowania ważne jest omówienie kilku terminów z nimi związanymi. Menadżer kolejek, to proces uruchomiony na serwerze, nasłuchujący na odpowiednich protokołach na połączenia sieciowe lub poprzez lokalne wywołanie API. Proces ten obsługuje podłączone do niego aplikacje, jak również inne menadżery kolejek. Aplikacje po połączeniu sie z procesem mają możliwość wykonania różnego rodzaju operacji na kolejkach. Kolejka z kolei, to kolejny logiczny obiekt takich systemów. Do kolejki takiej można wysyłać komunikaty (dane), z niej komunikaty pobierać lub je przeglądać. Oznacza to, ze każda aplikacja powinna mieć do pracy otwarte co najmniej dwie kolejki, jedną do odczytywania z niej komunikatów, a drugą do wysyłania do niej własnych komunikatów. Oczywiście tych kolejek może być więcej, wszystko to zależy od architektury systemu. Podczas działania aplikacja czyta komunikaty z kolejki. Każde pobranie komunikatu oznacza usunięcie go z kolejki co zapewnia ze konkretny komunikat zawsze zostanie przeczytany tylko raz. Przeglądanie z kolei odczytuje komunikat z kolejki pozostawiając go cały czas w kolejce. Aby poprawić wydajność aplikacji można uruchomić ją w kilku watkach co spowoduje, ze jednocześnie w danej chwili może być procesowanych wiele komunikaów poprzez zrównoleglenie zadań. Rozróżniamy następujące typy kolejek: Kolejka lokalna Jak sama nazwa wskazuje jest to standardowa kolejka znajdująca się lokalnie na menadżerze. Aplikacja podłączona do danego menadżera może do takiej kolejki czytać i pisać. Komenda tworząca taką kolejkę może mieć postać: DEFINE QLOCAL(QUEUE.IN) gdzie: QUEUE.IN : nazwa kolejki lokalnej Kolejka zdalna Kolejka ta określa lokalny wskaźnik do kolejki znajdującej się na innym "zdalnym" menadżerze kolejek. Pozwala ona na stworzenie na menadżerze obiektu wskazującego na inną kolejkę na zdalnym menadżerze. Do takiej kolejki można tylko zapisywać. Jako, że fizycznie kolejka ta znajduje się na innym menadżerze odczyt z niej jest niemożliwy. Po wrzuceniu komunikatu do takiej kolejki jest on przenoszony do kolejki transmisyjnej z nią związaną a następnie poprzez proces MCA i związaną z daną kolejką transmisyjna parą kanałów jest on przenoszony na kolejkę docelową na zdalnym menadżerze. Komenda tworząca taką kolejkę może mieć postać: DEFINE QREMOTE(QUEUE.OUT) RNAME(QUEUE.IN) RQMNAME(QM2) XMITQ(QM2_TRANS) gdzie: QUEUE.OUT : nazwa kolejki zdalnej QUEUE.IN : nazwa kolejki docelowej znajdującej się na zdalnym menadżerze QM2 : nazwa zdalnego menadżera kolejek QM2_TRANS : nazwa kolejki transmisyjnej Kolejka aliasowa Kolejka modelowa Kolejka dynamiczna Kolejka dynamiczna jest to specjalna kolejka, która jest tworzona dynamicznie przez aplikacje.Rozróżniamy kolejki dynamiczne tymczasowe i trwałe. Kolejka tymczasowa jest usuwana zaraz po zakończeniu aplikacji i odłączeniu się od menadżera kolejek. Kolejka trwała przetrwa zakończenie aplikacji. To czy stworzona kolejka dynamiczna będzie trwała, czy nie zależy od parametru DEFTYPE kolejki modelowej na podstawie której stworzona zostanie kolejka dynamiczna. Parametr ten może przyjmować następujące wartości: PERMDYN : Tworzona kolejka dynamiczna będzie trwała TEMPDYN : Tworzona kolejka dynamiczna będzie tymczasowa Przykładowy kod: String dynamicQueueName="dynam*"; Kolejka klastrowa Kolejka transmisyjna Kolejka inicjalizacyjna Rodzaje kanałów Sender-Receiver Jest to chyba najczęściej spotykany typ kanałów. W przypadku wysyłania komunikatu do zdalnego menadżera komunikat umieszczany jest w kolejce transmisyjnej. Następnie uruchamiany jest (jeśli wcześniej nie był uruchomiony) kanał sender po stronie wysyłającej, który z kolei uruchamia, jeśli wcześniej nie był uruchomiony, kanał receiver po stronie odbierającej i przesyła poprzez sieć komunikat. Po stronie odbierającej kanał receiver umieszcza komunikat w docelowej kolejce lokalnej. Requester-Server Requester-Sender Server-Receiver Cluster server- Cluster receiver Ciekawsze parametry kanałów Batch Heartbeat Interval (BATCHHB) Parametr ten określa, co jaki czas będą wysyłane specjalne komunikaty do zdalnego kanału sprawdzające, czy jest on aktywny. Komunikaty te są wysyłane tylko i wyłącznie wtedy, kiedy pomiędzy MCA wysyłającym a MCA odbierającym od pewnego czasu nie było komunikacji. Wysyłane są one po wysłaniu paczki komunikatów a przed jej potwierdzeniem. Możliwe wartości parametru przyjmowane są z zakresu od 0 do 999 999 999, gdzie 0 oznacza, ze komunikaty takie nie będą wysyłane. Batch interval (BATCHINT) Parametr ten określa w milisekundach czas, przez jaki kanał będzie trzymał otwarta paczkę komunikatów do skomitowania. Jako paczkę mamy tu na myśli blok komunikatów do potwierdzenia. Komunikaty wysyłane są indywidualnie, natomiast, co jakiś czas wysyłka poprzednich komunikatów jest potwierdzana paczka komunikatów zostanie zamknięta (potwierdzona), jeśli zawiera BATCHSZ komunikatów lub, jeśli jest pusta kolejka transmisyjna i paczka komunikatów do wysyłki jest juz otwarta (nie było potwierdzenia) BATCHINT milisekund. Możliwe wartości parametru przyjmowane są z zakresu od 0 do 999 999 999. Wartość domyślna to 0, co oznacza, ze paczka zostanie zamknięta, jeśli kolejka transmisyjna będzie pusta lub zawiera ona BATCHSZ komunikatów. Batch size (BATCHSZ) Parametr ten określa maksymalną ilość komunikatów, jakie mogą być wysłane pomiędzy kolejnymi potwierdzeniami. W jakich okolicznościach paczka jest potwierdzana opisano w punkcie BATCHINT. Data compression (COMPMSG) Parametr ten określa Możliwe techniki kompresji dostępnej w danym kanale. Możliwe wartości to NONE, RLE, ZLIBFAST, ZLIBHIGH, ANY Disconnect interval (DISCINT) Parametr określa w sekundach, po jakim czasie od zakończenia ostatniej paczki komunikatów połączenie zostanie zerwane. Pozwala to w przypadku, kiedy np. komunikaty przez dłuższy czas nie są przesyłane przez kanał na zwolnienie zasobów. Parametr przyjmuje wartości od 0 do 999999, gdzie 0 oznacza brak zrywania połączenia. Header compression (COMPHDR) Heartbeat interval (HBINT) Parametr określa w sekundach, po jakim czasie od stwierdzenia, ze w kolejce transmisyjnej nie ma już komunikatów zostanie wysłana specjalny komunikat do kanału odbierającego. Komunikat ten powoduje, że odbierający MCA może zwolnić zaalokowaną na potrzeby dużych komunikatów pamięć oraz zamknąć otworzone przez siebie kolejki. Parametr przyjmuje wartości od 0 do 999999, gdzie 0 oznacza, ze tego typu komunikaty nie są wysyłane. Domyślnie parametr ten przyjmuje wartość 300. Wartość ta powinna być mniejsza niż wartość disconnect interval. KeepAlive interval (KAINT) Parametr określa w sekundach keepalive kanału (TCP/IP). Aby ten parametr zadziałał należy w pliku konfiguracyjnym qm.ini ustawić parametr KEEPALIVE ( KEEPALIVE=YES). Dopiero wtedy parametr kanału KAINT będzie brany pod uwagę. Parametr przyjmuje wartości od 0 do 99999, gdzie 0 oznacza, że ta funkcjonalność kanału jest wyłączona. Jeśli parametr ten jest ustawiony na AUTO to wartość ta wynosi wynegocjowany heartbeat + 60 sekund. Short retry count (SHORTRTY),Short retry interval (SHORTTMR),Long retry count (LONGRTY),Long retry interval (LONGTMR) Parametry te określają w ja sposób nawiązywane jest połączenie ze zdalnym serwerem. W pierwszym etapie co SHORTTMR sekund podejmowanych jest SHORTRTY prób połączenia się. Jeśli to się nie uda następnie co LONGTMR sekund podejmowanych jest LONGRTY prób połączenia się. Jeśli to z kolei się nie powiedzie następuje zatrzymanie kanału. Operacja ta została podzielona na dwie części, aby w pierwszej fazie jak najszybciej połączyć się z zdalnym serwerem, a w drugiej nie dopuścić do zatrzymania się kanału. Dlatego szczególna uwagę należy zwrócić na odpowiednie dobranie tych parametrów. Maximum messąge length (MAXMSGL) Messąge retry count (MRRTY) Messąge retry interval (MRTMR) Nonpersistent messąge speed (NPMSPEED) Multi-hopping jest specjalną techniką pozwalającą na przesłanie komunikatu z jednego menadżera na drugi bez użycia bezpośredniego połączenia pomiędzy nim za pomocą kanałów, tylko poprzez wykorzystanie pośrednich menadżerów. Przy tym rozwiązaniu stosuje się aliasy menadżera kolejek. Alias taki to w praktyce standardowa kolejka zdalna, w której wskazanie na zdalną kolejkę przyjmuje wartość pustego łańcucha. Dla przykładu w konfiguracji, kiedy mamy 4 menadżery kolejek QM1, QM2, QM3 oraz QM4 połączonych ze sobą szeregowo, aby przetransportować komunikat z menadżera QM1 na QM4 należy na menadżerach nie połączonych bezpośrednio z QM4 utworzyć alias wskazujący, że komunikaty przesyłane do menadżera QM4 powinny znaleźć się w kolejce transmisyjnej wskazującej na kolejny menadżer w ścieżce. I tak na menadżerze QM1 definiujemy alias mówiący, że komunikaty przesyłane do menadżera QM4 mają przechodzić przez menadżer QM2: DEFINE QREMOTE (QM4) RNAME('') RQMNAME(QM4) XMITQ(QM2) Na menadżerze QM2 definiujemy alias mówiący, że komunikaty przesyłane do menadżera QM4 mają przechodzić przez menadżer QM3 DEFINE QREMOTE (QM4) RNAME('') RQMNAME(QM4) XMITQ(QM3) Na menadżerze QM3 nie musimy definiować alisów ponieważ jest on bezpośrednio połączony z menadżerem QM4. W powyższych przykładach nazwa kolejki transmisyjnej jest taka sama jak nazwa menadżera w którym komunikaty mają się znaleźć. Nic nie stoi na przeszkodzie aby była to dowolna nazwa z którą związana jest jakaś para kanałów pomiędzy menadżerami. W przypadku komunikacji pomiędzy menadzerami istnieje możliwość powielenia kanałów. Oznacza to, że komunikacja pomiędzy dwoma menadzerami może być rozdzielona pomiędzy kilka niezależnych transmisji kanałami. Często jest to wykorzystywane dla odseparowania od siebie systemów łączących sie do jednego menadżera. Wyobraźmy sobie dwa menadżery QM1 i WBRK_QM. W przypadku dwóch aplikacji łączących się do menadżera QM1 każda mo *QIN Do ciekawszych komend MQ należą: dspmq Wyświetla listę lokalnych menadżerów kolejek i status ich pracy. crtmqm Tworzy menadżera kolejek. amqmdain Uruchamia lub zatrzymuje menadżera kolejek w przypadku systemu Windows. strmqm Uruchamia menadżera kolejek. endmqm Zatrzymuje menadżera kolejek. runmqsc Uruchamia konsole tekstową do zarządzania menadżerem kolejek. strmqcsv Uruchamia proces command server menadżera kolejek. setmqaut Ustawia prawa użytkowników lub grup do obiektów MQ. dspmqaut Wyświetla prawa użytkowników lub grup do obiektów MQ. dmpmqaut Wyświetla szczegółowe informacje o prawa użytkowników lub grup do obiektów MQ. Tworzy zrzut praw runmqlsr Dla wersji MQ V5.3 uruchamia proces listener'a. mqrc Wyświetla informacje o błędzie MQ. dspmqver Wyświetla szczegółowe informacje i wersji MQ i zainstalowanych poprawkach. 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 Każdy komunikat wysyłany, czy też odbierany z kolejki posiada, poza blokiem danych aplikacji, blok nagłówkowy. Zawiera on parametry związane z charakterystyką komunikatu. Do najważniejszych z nich należą: MessageId Pole oznacza identyfikator komunikatu. CorrelationId Pole oznacza identyfikator skorelowanego komunikatu. Wykorzystywane w komunikacji REQUES-RESPONSE. W przypadku adaptera odpowiadającego pole powinno być ustawione na indeks zapytania i tak wysłane do adaptera pytającego, aby ten z kolei mogł ustalić na jakie zapytanie jest to odpowiedź. Expiry Pole określa kiedy komunikat traci ważność. Jest ono wykorzystywane bardzo często, kiedy wiemy, że po jakimś upływie czasu informacja zawarta w komunikacie się przedawni lub kiedy odpowiedzi na zadane przez nas pytanie oczekujemy przez ściśle określony czas. Persistence Pole to często jest wykorzystywane wspólnie z poprzednim polem. Określa ono, czy komunikat ma być trwały, czy nie. Trwałość rozumie się przez to, że komunikat w przypadku restartu menadżera kolejek, jeśli przed restartem znajdował się w kolejce, to i po nim też tam się będzie znajdował dopóki jakiś adapter go stamtąd nie pobireze. Komunikaty nietrwałe takiej operacji nie przetrwają i w takiej sytuacji zostają utracone. Sens wykorzystania komunikatów nietrwałych wiąże się z wydajnością. W związku z tym jeśli nie ma takiej potrzeby, to nie jest zalecane aby wszystkie wysyłane komunikaty były trwałe. ReplyToQueue Pole to jest wykorzystywane w komunikacji REQUES-RESPONSE. Ustawiane jest ono przez adapter odpytujący i określa do jakiej kolejki powinna być wysłana odpowiedź, tak aby z tej kolejki adapter ten mógł ja odczytać. Persystencja komunikatów jest bardzo ważnym parametrem oznaczającym czy komunikaty maja być trwale przechowywane przez menadżer kolejek i nie mogą zaginąć. Komunikaty dzielimy na persystentne i nie persystentne. Jeśli komunikat jest persystentny oznacza to, że będzie on logowany w pamięci trwalej, co powoduje to, ze nie ma możliwości jego utraty. Komunikat taki przetrwa nawet restart menadżera kolejek. W związku z tym, że komunikaty takie musza być logowane ich procesowanie trwa zdecydowanie dłużej niż komunikatów niepersystentnych. Komunikaty niepersystentne z kolei nie gwarantują dostarczenia do adresata ze względu na swoja ulotna naturę. Nie są one logowane tak jak komunikaty persystentne, ale za to są o wiele szybciej procesowane. To czy wysyłany komunikat powinien być persystentny zależy od logiki aplikacji. Jeśli np. aplikacja wysyła dane synchronizacyjne o zmianach w swoim systemie, a inne aplikacje te informacje potrzebują, aby zaktualizować własne bazy wskazane jest, aby komunikaty te były persystentne. Jeśli z kolei wysyłany komunikat jest zapytaniem o informacje w innym systemie I wiemy, ze w przypadku niepowodzenia zawsze możemy zapytać się ponownie zalecane jest, aby komunikaty takie uczynić nie persystentnymi. Persystencję komunikatu określa parametr persistence i przyjmuje on następujące wartości: MQC.MQPER_PERSISTENT : komunikat persystentny MQC.MQPER_NOT_PERSISTENT : komunikat niepersystentny MQC.MQPER_PERSISTENTCE_AS_Q_DEF : persystencja komunikatu zgodna z definicja kolejki. Priorytet komunikatu określany jest przez wypełnienie pola Priority w nagłówku komunikatu. Wartością tego pola jest liczba od 0 do 9, gdzie 0 oznacza najniższy priorytet, a 9 najwyższy. Parametr ten jest dość często wykorzystywany w systemach gdzie np. do tej samej kolejki trafiają komunikaty o rożnej charakterystyce obsługi. Jako przykład można ty przytoczyć aplikację wysyłającą dwa rodzaje komunikatów, jeden obsługiwany w adapterze dość długo, a drugi obsługiwany w ułamku sekundy. I teraz niech aplikacja wyśle w krótkim czasie na przemian kilkadziesiąt "długich" i kilkadziesiąt "krótkich" komunikatów. Jeśli adapter obierający będzie działał w jednym wątku lub będzie miał ich niewiele, to jeśli wysłane komunikaty będą miały taki sam priorytet, będą one obsłużone zgodnie z zasadą FIFO (pierwsze przyszło, pierwsze wyszło). Jeśli okaże się, że komunikaty krótkie są dla nas ważniejsze możemy ustawić im wyższy priorytet i wtedy w momencie wrzucenia takiego komunikatu do kolejki zostanie on dodany na koniec komunikatów o tym samym priorytecie a przed komunikatami o niższym priorytecie. W takiej sytuacji adapter odbierający pobierze komunikat "długi" tylko wtedy jeśli nie będzie w kolejce już komunikatów "krótkich" ponieważ będą miały one wyższy priorytet. Często w przypadku komunikacji MQ aplikacja uruchamiana jest niezależnie od menadżera kolejek, łączy się z nim, czyta jej kolejki, procesuje komunikaty cały oczekując na nowe komunikaty w kolejce wejściowej. Istnieją jednak sytuacje, w których tego typu rozwiązanie można zastąpić bardziej odpowiednim. Wyobraźmy sobie sytuacje, kiedy komunikaty, które aplikacja musi przetworzyć pojawiają się w jej kolejce wejściowej bardzo rzadko. Może się okazać, że aby nie trzymać zasobów niewykorzystywanych, a to ma miejsce np., kiedy aplikacji przez długi czas oczekuje na kolejce na nowe komunikaty bez rezultatu, wskazane by było uruchomienie aplikacji w momencie pojawienia się komunikatu w kolejce. Taka uruchomiona aplikacja może przeczytać dany komunikat z kolejki przetworzyć go i inne znajdujące się w kolejce i rozłączyć się po zaraz po ich przetworzeniu lub po jakimś określonym w aplikacji czasie. Na tym właśnie polega triggering aplikacji. Zasada działania Za uruchomienie aplikacji, która ma być triggerowana, czyli uruchamiania w momencie pojawienia się komunikatu w kolejce odpowiada trigger monitor. Trigger Monitor to specjalny proces ( runmqtrm ), którego zadaniem jest czytanie specjalnej kolejki inicjującej w której menadżer kolejek umieszcza komunikaty zdarzenia informujące o tym, iż spełnione zostały warunki do uruchomienia odpowiedniej klienckiej aplikacji. Trigger monitor odczytuje te komunikatu i na podstawie informacji w nich zawartych uruchamia odpowiedni proces aplikacji, która po uruchomieniu czyta komunikatu w jej kolejce wejściowej. Aby włączyć triggering danej aplikacji należy : -Kolejkę wejściową aplikacji ustawić jako trigerowaną -Utworzyć specjalną kolejkę w której zapisywane będą komunikaty inicjujące aplikację -Utworzyć specjalny obiekt MQ reprezentujący aplikację, która będzie uruchamiana przez trigger monitor -Uruchomić proces trigger monitora Określenie kolejki jako triggerowanej Z pojęciem triggerowania aplikacji związane są następujące atrybuty kolejki: TRIGGER : Parametr oznacza włączenie triggerowanie danej kolejki TRIGTYPE : Parametr oznacza sposób triggerowania kolejki i przyjmuje następujące wartości : EVERY: Aplikacja będzie uruchamiana za każdym razem, kiedy w kolejce pojawi się komunikat FIRST: Aplikacja będzie uruchamiana jeśli kolejka będzie pusta i pojawi się w niej nowy komunikat oraz żadna aplikacja nie będzie miała kolejkę otwartą do odczytu. Dodatkowo jeśli po czasie w milisekundach określonych w parametrze TRIGINT menadżer kolejek nie stwierdzi aby kolejka była otwarta do odczytu nowy komunikat inicjujący zostanie umieszczony w kolejce inicjującej. DEPTH: Aplikacja zostanie uruchomiona jeśli w kolejce będzie odpowiednia ilość komunikatów. Ilość tą określa parametr TRIGDPTH Przykładowo poniższa komenda mqsc tworzy kolejkę QUEUE.IN, która jest triggerowana. Komunikat inicjujący zostanie umieszczony w kolejce inicjującej QUEUE.INITw momencie kiedy w kolejce będzie 10 komunikatów i nie będzie ona otwarta przez żadną aplikację do czytania. Trigger monitor w momencie pojawienia się zdarzenia ma uruchomić aplikacje opisaną w obiekcie MYAPP_PROCESS. DEFINE QLOCAL (QUEUE.IN) + Utworzenie kolejki inicjującej Proces tworzenie kolejki inicjującej nie różni się od tworzenia standardowej kolejki MQ. Zaleca się jedynie, aby triggerowanie działało poprawnie, ustawić tą kolejkę jako nie triggerowaną oraz aby zabronić czytania z niej wielu instancją aplikacji, tj. trigger monitora. Przykładowa komenda tworząca taką kolejkę może mieć postać: DEFINE QLOCAL(QUEUE.INIT) + Utworzenie obiektu PROCESS W celu określenia jaka aplikację trigger monitor ma uruchamiać w momencie pojawienia się komunikatu w kolejce inicjującej należy stworzyć specjalny obiekt PROCESS, którego argumenty to: APPLTYPE : określa system operacyjny aplikacji, która ma być uruchamiana APPLICID : określa ścieżkę uruchamianej aplikacji USERDATA : określa dodatkowe argumenty dla uruchamianej aplikacji Przykład tworzenia takiego obiektu PROCESS może mieć postać: DEFINE PROCESS (MYAPP_PROCESS) + Uruchomienie trigger monitora W celu uruchomienia trigger monitora należy uruchomić proces runmqtrm z parametrami: -m : nazwa menadżera kolejek, na której znajduje się kolejka inicjująca -q : nazwa kolejki inicjującej, która ma być czytana przez trigger monitora Przykład takiej komendy może mieć postać: runmqtrm -m QMGR1 -q QUEUE.INIT W przypadku komunikacji pomiędzy kanałami również możemy zastosować triggering. Jako triggering mamy tu na myśli uruchamianie kanałów po zdarzeniu jakim jest pojawienie się komunikatu w kolejce transmisyjnej. W kolejce transmisyjnej znajdują się komunikaty które mają zostać przetransportowane do innego menadżera kolejek za pomocą kolejki zdalnej. Tu jak w przypadku można tak skonfigurować konały tak, aby po odpowiednim czasie były one zatrzymane i w ten sposób zwalniały zasoby do momentu kiedy znów będą potrzebne, tj., kiedy pojawi się nowy komunikat do przesłania pomiędzy menadżerami. Za ponowne uruchamianie kanałów odpowiada specjalny dedykowany proces o nazwie chanel initiator. Aby zdefiniować triggering kanałów należy : -Kolejkę transmisyjną połączyć i kolejką inicjującą -Uruchomić proces channel initiator Połączenie kolejki transmisyjnej z kolejką inicjującą Z pojęciem triggerowania kanałów związane są następujące atrybuty kolejki transmisyjnej: TRIGGER : Parametr oznacza włączenie triggerowanie kanału związanego z daną kolejką transmisyjną INITQ : Parametr określa nazwę kolejki inicjującej w której znajda się komunikaty oznaczające pojawienie zdarzenia jakim jest komunikat wrzucony do pustej kolejki. Najczęściej parametr ten jest ustawiony na kolejkę systemową SYSTEM.CHANNEL.INITQ. TRIGDATA : Parametr określa nazwę kanału do uruchomienia. W przypadku, kiedy to pole jest puste uruchomiony zostanie kanał, który jest związany z daną kolejką transmisyjną. Przykładowa komenda tworząca kolejkę transmisyjną przystosowaną do triggerowania kanałów może mieć postać: DEFINE QLOCAL(QMGR2) + Uruchomienie procesu channel initiator W celu uruchomienia procesu channel initiator należy uruchomić jego proces za pomocą konsoli tekstowej i polecenia START CHINIT. Jego najważniejszym argumentem jest INITQ określający nazwę kolejki inicjującej. Przykład takiej komendy może mieć postać: START CHINIT INITQ(SYSTEM.CHANNEL.INITQ) Standardowy proces chanel initiator jest uruchamiany wraz z uruchomieniem menadżera kolejek i razem z menadżerem kolejek jest zatrzymywany. Klastry MQ, to rozwiązanie pozwalające na połączenie większej ilości menadżerów kolejek w grupę. Rozwiązanie to pozwala na programowe osiągniecie wysokiej dostępności jak również na zmniejszenie ilości kanałów do zarządzania. W przypadku klastrów MQ wysoka dostępność polega na tym, iż w klastrze tym można tworzyć kolejki klastrowe, których instancje mogą znajdować się na wielu menadżerach kolejek, w związku z czym jeśli np. któryś z tych menadżerów będzie zatrzymany komunikaty będą przesyłane do pozostałych. Uproszczenie zarządzania polega na tym, iż w przypadku kanałów wewnątrz klastra nie trzeba mieć połączonych ze sobą parą wszystkich menadżerów w klastrze. Wymagane jest tylko stworzenie kanału odbierającego oraz kanału sender do pełnego repozytorium danego klastra. W przypadku środowiska klastrowego jeśli aplikacja jest połączona do konkretnego menadżera kolejek, to może ona również otwierać kolejki klastrowe umieszczone na innym menadżerze będącym członkiem tego samego klastra. Pełne repozytorium klastra (Full repository) Pełne repozytorium klastra stanowi ważny element architektury klastrowej MQ. Jest to standardowy menadżer kolejek, który poza zarządzaniem własnymi kolejkami pełni rolę repozytorium wszystkich menadżerów i ich kolejek klastrowych. Jego zadaniem jest utrzymywaniem aktualnej tej listy na podstawie informacji przekazywanych mu przez inne standardowe menadżery znajdujące się w klastrze lub przez inne pełne repozytorium. Informacje te następnie są wykorzystywane przez pozostałe menadżery w celu zdefiniowania połączenia do innego menadżera w klastrze. Jako, że utrato takiego menadżera skutkowała by niemożnością połączenia z innymi menadżerami w klastrze wskazane jest aby takich pełnych repozytoriów w klastrze było przynajmniej 2. Aby określić dany menadżer kolejek, jako pełne repozytorium MQ należy na nim wykonać komendę: ALTER QMGR REPOS(NAME) gdzie: NAME : nazwa kastra, którego dany mendzer będzie pełnym repozytorium MQ Częściowe repozytorium klastra (Partial repository) Częściowe repozytorium klastra to każdy inny menadżer kolejek, który nie pełni rolę pełnego repozytorium MQ. Menadżer taki nie posiada informacji o pełnej architekturze MQ klastra, tylko częściową informacje o niej. Dzieje się tak dlatego, ponieważ posiada on wyłącznie informacje o menadżera i kolejkach w klastrze do których wcześniej się odwoływał i dostał już wcześniej informacje o ich położeniu od pełnego repozytorium MQ. Jeśli musi się połączyć z menadżerem, którego nie zna wysyła żądanie do pełnego repozytorium o jego dane. Taki wewnętrzny cache w częściowym repozytorium przechowywane jest przez 30 dni. Po tym czasie wysyłane jest ponownie żądanie do pełnego repozytorium o dane na temat obiektów znajdujących się w lokalnej kopii. Z drugiej strony menadżer pełniący rolę pełnego repozytorium MQ przesyła do częściowych repozytoriów informacje tylko i wyłącznie o zmianach w architekturze klastra. Kanał cluster sender Kanał ten musi być stworzony na każdym menadżerze będącym częścią klastra. Wskazuje on na menadżer będący pełnym repozytorium MQ. Każde częściowe repozytorium MQ powinno mieć tyle kanałów cluster sender ile w klastrze znajduje się pełnych repozytoriów. Każde pełne repozytorium klastra powinno mieć po jednym tego typu kanale wskazującym na pozostałe pełne repozytoria znajdujące się w klastrze. Kanał cluster receiver Kanał ten musi być stworzony na każdym menadżerze będącym częścią klastra. Wskazuje on na siebie samego i każdy menadżer ma tylko jeden tego typu kanał. Kanał ten służy do wskazywania innym menadżerom w klastrze definicji połączenia z menadżerem, na którym kanał ten został stworzony. Łączenie się do klastra z menadżera kolejek znajdującego się poza klastrem W przypadku kiedy mamy sytuacje, gdy aplikacja podłączona jest do menadżera znajdującego się poza klastrem, a kolejka docelowa znajduje się na menadżerach kolejek wewnątrz klasta w kilku instancjach można zastosować architekturę, w której jeden menadżer w klastrze potraktujemy jednocześnie jako gateway pomiędzy klastrem a zewnętrznymi menadżerami kolejek. W takiej sytuacja pomiędzy zewnętrznym menadżerem, a menadżerem pełniącym rolę klastra tworzy się standardowe definicje par kanałów np. sender-receiver. Następnie aby umożliwić zewnętrznym menadżerom komunikacje z innymi menadżerami wewnątrz klastra na gateway-u tworzy się alias menadżera wskazujący na dowolny menadżer w klastrze. Definicję taką możemy utworzyć np. poleceniem: DEFINE QREMOTE(ANY.CLUSTER) RNAME(' ') RQMNAME(' ') Oznacza to, że jeśli do menadżera gatewaya dotrze z zewnątrz komunikat z kolejki zdalnej wskazującej na menadżer o nazwie ANY.CLUSTER, komunikat ten zostanie przekazany do dowolnego menadżera wewnątrz klastra posiadającego instancję kolejki, zdefiniowanej w definicji kolejki zdalnej na zewnętrznym menadżerze. Definicję takiej kolejki zdalnej znajdującej się na zewnętrznym menadżerze może mieć postać: DEFINE QREMOTE(TO.CLUSTER.QUEUE) RNAME(CLUSTER.QUEUE.IN) RQMNAME(ANY.CLUSTER) XMITQ(QM3) Teraz po umieszczeniu na zdalnym menadżerze komunikatu w kolejce TO.CLUSTER.QUEUE komunikatu przejdzie on za pośrednictwem pary sender-receiver do gatewaya. Tam jako, że docelowy menadżer okazał się aliasem na dowolny menadżer kolejek za pomocą określonych zasad routingu komunikat zostanie umieszczony w jednym z menadżerów kolejek wewnątrz klastra zawierających lokalna kolejkę klastrową CLUSTER.QUEUE.IN. Usunięcie menadżera z klastra Niekiedy istnieje potrzeba zatrzymania menadżera lub jego usunięcia. W przypadku architektury klastrowej Ważne jest aby przed dokonaniem tej czynności poinformować innych członków klastra, o tym zdarzeniu aby nowe komunikaty ni były do niego przesyłane. Inne menadżery mogą mieć we własnej częściowej bazie informacje o tym menadżerze i jego zatrzymanie nie spowoduje od razu rozpropagowanie tej informacji. Informacja ta wygaśnie na innych menadżerach po 90 dniach, ponieważ co taki czas menadżery w klastrze odświeżają swoje lokalne repozytorium. Aby prawidłowo zatrzymać menadżera będącego częścią klastra należy przed tym wykonać na nim komendę usuwającą jego definicje z klastra. Komenda ta ma postać: SUSPEND QMGR CLUSTER(CLUSTER_NAME) MODE(SUSPEND_MODE) gdzie : CLUSTER_NAME : nazwa klastra, z którego danego menadżera usuwamy SUSPEND_MODE : tryb usunięcia. Przyjmuje następujące wartości: QUIESCE:usunięcie z oczekiwaniem na zakończenie bieżących prac FORCE:usunięcie natychmiastowe Po dokonaniu na nim odpowiednich czynności, np. wgrania poprawki taki menadżer możemy ponownie dodać do klastra. Dodanie ponowne usuniętego menadżera do klastra ma postać: RESUME QMGR CLUSTER(CLUSTER_NAME) gdzie : CLUSTER_NAME : nazwa klastra, do którego danego menadżera dodajemy Jeśli już się zdarzyło, że usunęliśmy menadżera bez wykonania na nim komendy SUSPEND lub w jakiś inny sposób straciliśmy nad nim kontrolę możemy w takiej sytuacji wykonać na pełnym repozytorium klastra komendę nakazującą wszystkim menadżerom w klastrze usunąć definicje tego zagubionego menadżera. Komenda taka ma postać: RESET CLUSTER(CLUSTER_NAME) ACTION( FORCEREMOVE ) QMNAME(QMGR_NAME) gdzie : CLUSTER_NAME : nazwa klastra, z którego usuwamy wszystkie definicje danego menadżera QMGR_NAME : nazwa menadżera kolejek, którego definicje chcemy usunąć Przykładowa architektura Dla zobrazowania koncepcji klastrów przykładowe poniższe skrypty wykonują: Zmienia definicje menadżera QM1 ustalając go pełnym repozytorium klastra MK_CLUSTER, tworzy jego kanał cluster receiver, kanał cluster sender do drugiego pełnego repozytorium klastra QM2 oraz tworzy na nim kolejkę klastrową CLUSTER.QUEUE.IN #na QM1 wykonyjemy Zmienia definicje menadżera QM2 ustalając go pełnym repozytorium klastra MK_CLUSTER, tworzy jego kanał cluster receiver, kanał cluster sender do drugiego pełnego repozytorium klastra QM1 oraz tworzy na nim kolejkę klastrową CLUSTER.QUEUE.IN #na QM2 wykonyjemy #na QM3 (GATEWAY) wykonyjemy Aby teraz zweryfikować działanie klastra należy na zewnętrznym menadżerze nie będącym w klastrze wykonać komendę tworzącą kolejkę zdalną wykorzystującą alias stworzony wcześniej. DEFINE QREMOTE(TO.CLUSTER.QUEUE) RNAME(CLUSTER.QUEUE.IN) RQMNAME(ANY.CLUSTER) XMITQ(QM3) Po wrzuceniu kilku komunikatów do tej kolejki część z nich powinna się znaleźć na menadżerze QM1, a część na menadżerze QM2. Ilość komunikatów jakie znajda się w jednej i drugiej kolejce klastrowej będzie rozłożona mniej więcej proporcjonalnie (przy standardowej konfiguracji). Czasami w przypadku pojawienia się problemów sieciowych po rozwiązaniu problemu kanały nie mogą się ponownie automatycznie skomunikować. W takiej sytuacji wymagana jest manualna reakcja. Poniżej postaram się opisać procedurę. Pierwszym rzeczą jaką należy zrobić jest odczytanie po stronie kanały sender oraz receiver identyfikatora ostatnio skomitowanego bloku danych. Po stronie sender dokonujemy tego komendą: DISPLAY CHSTATUS(nazwa_kanału) SAVED CURLUWID Po stronie receiver dokonujemy tego komendą: DISPLAY CHSTATUS(nazwa_kanału) SAVED LSTLUWID Jeśli wartość są identyczne oznacza to, że druga strona już wykonała commit paczki danych, która po stroniesender jest w stanie in doubt. W takiej sytuacji możemy spokojnie usunąć oczekujące komunikaty in doubt. Dokonujemy tego wykonując po stronie sender komendę: RESOLVE CHANNEL(nazwa_kanału) ACTION(COMMIT) Jeśli wartość są różne oznacza to, że druga strona nie wykonała jeszcze commit paczki danych, która po stroniesender jest w stanie in doubt. W takiej sytuacji należy oczekującą paczkę in doubt przesłać poprzez kolejkę transmisyjną do menadżera ze strony receiver. Dokonujemy tego wykonując po stronie sender komendę: RESOLVE CHANNEL(nazwa_kanału) ACTION(BACKOUT) WebSphere MQ ma możliwość za pomocą SSL zabezpieczyć komunikacje kliencka, jak również komunikacje pomiędzy menadżerami.Każdemu menadżerowi przypisana jest własna baza certyfikatów i tą bazę będzie on używał przy połączeniach szyfrowanych. Baza ta jest w standardowym formacie pliku kdb.Ważne tu jest, że w celu poinformowania menadżera jakiego klucza prywatnego ma używać alias tego klucza musi nosić odpowiednią nazwę. Nazwa ta to webspheremq{QMGNNAME}, gdzie {QMGNNAME}, to nazwa menadżera pisanamałymi literami.Po odpowiednim przygotowaniu bazy możemy przystąpić do konfiguracji kanału. Parametry menadżera odpowiadające za komunikacje SSL to: SSLKEYR Określa plik z bazą certyfikatów bez rozszerzenia. Standardowo parametr ten ustawiony jest na : {MQDIR}/qmgrs/{QMGR_NAME}/ssl/keyOznacza to, że plik ten będzie nazywał się {MQDIR}/qmgrs/{QMGR_NAME}/ssl/key.kdb SSLCRLNL Określa obiekt namelist zawierający listę definicji połączeń do serwera LDAP. Poprzez te połączenia menadżer będzie weryfikował listę certyfikatów, które zostały anulowane. SSLEV Określa, czy jest w przypadku błędu podczas negocjacji SSL będzie generowany odpowiedni komunikat EVENT. SSLCRYP Określa parametry związane ze urządzeniem kryptograficznym jeśli jest wykorzystywane. SSLFIPS Określa ... SSLRKEYC Określa ilość bajtów, jaka jest przesłana lub odebrana pomiędzy renegocjacjami klucza SSL. Parametry kanału odpowiadające za komunikacje SSL to: SSLCIPH Określa CipherSpecs ( sposób szyfrowania ) jaki będzie użyty przy komunikacji. SSLPEER Określa dn, jaki zostanie zaakceptowany podczas połączenia SSL. Można tu stosować paterny.W momencie negocjacji połączenia z duga strona, jeśli certyfikat drugiej strony nie będzie się zgadzał z tym paternem połączenie nie zostanie nawiązane. SSLCAUTH Określa, czy wymagane jest aby strona kliencka przedstawiła się certyfikatem w celu autentykacji. Poniżej znajduje się kod modyfikujący kanał poprzez ustawienie CipherSpecs, CN'a drugiej strony jaki będzieakceptowany oraz konieczności weryfikacji certyfikatu strony łączącej się. alter chl('receiver') chltype(rcvr) + Jeśli chodzi o część aplikacyjną, to aby połączyć się z kanałem kliencki skonfigurowanym do obsługi SSL należyustawić statyczne pole sslCipherSuite klasy MQEnvironment określające CipherSuite połączenia, które MUSI być identyczne jak to samo pole kanału klienckiego, do którego aplikacja chce się łączyć oraz dodatkowo zmienne systemowe javax.net.ssl.keyStoreijavax.net.ssl.trustStoreokreślające plik z kluczem prywatnym oraz z zaufanymi certyfikatami wraz z hasłami do tych plikówjavax.net.ssl.keyStorePasswordijavax.net.ssl.trustStorePassword. MQEnvironment.sslCipherSuite = "SSL_RSA_WITH_NULL_MD5"; Komunikaty Accounting and Statistics są specjalnymi komunikatami generowanymi przez menadzer zawierającymi informacje statystyczne. Czy informacje te będą generowane zależy od konfiguracji kolejki, którą chcemy monitorować oraz menadżera kolejek. Po włączeniu monitorowania statystyk są one generowane i umieszczane w kolejce systemowej SYSTEM.ADMIN.STATISTICS.QUEUE. Komunikaty te są sformatowane w postaci PCF. Statystyki te można podzielić na trzy grupy, dotyczące operacji MQI, kolejek i kanałów i można je niezależnie włączać i wyłączać. Parametry kolejki to: STATQ : Określa poziom logowania informacji dla kolejki Możliwe wartości to : QMGR : to czy statystyki będą generowane zależy od parametru STATQ menadżera kolejek ON : statystyki będą generowane jeśli parametr STATQ menadżera kolejek nie jest ustawiony na wartość NONE OFF : statystyki nie będą generowane Parametry dla kanału to: STATCHL : Określa poziom logowania informacji dla kanału Możliwe wartości to : QMGR : statystyki dla kanału będą generowane na takim poziomie na jaki stawiony jest parametr STATQ menadżera kolejek OFF : statystyki dla kanału nie będą generowane LOW : statystyki dla kanału będą generowane na niskim poziomie MEDIUM : statystyki dla kanału będą generowane na średnim poziomie HIGH : statystyki dla kanału będą generowane na wysokim poziomie Parametry menadżera to: STATACLS : Określa poziom logowania informacji o kanałach typu cluster-sender Możliwe wartości to : QMGR : statystyki dla kanału cluster-sender będą generowane w sposób opisany parametrem menadżera STATCHL OFF : statystyki dla kanału cluster-sender nie będą generowane LOW : statystyki dla kanału cluster-sender będą generowane na niskim poziomie MEDIUM : statystyki dla kanału cluster-sender będą generowane na średnim poziomie HIGH : statystyki dla kanału cluster-sender będą generowane na wysokim poziomie STATCHL : Określa poziom logowania informacji o kanałach Możliwe wartości to : NONE : statystyki dla kanału nie będą generowane OFF : statystyki nie będą generowane dla kanałów, które maja ustawiony atrybut STATCHL na QMGR LOW : statystyki będą generowane na niskim poziomie dla kanałów, które maja ustawiony atrybut STATCHL na QMGR MEDIUM : statystyki będą generowane na średnim poziomie dla kanałów, które maja ustawiony atrybut STATCHL na QMGR HIGH : statystyki będą generowane na wysokim poziomie dla kanałów, które maja ustawiony atrybut STATCHL na QMGR STATMQI : Określa poziom logowania informacji o menadżerze kolejek Możliwe wartości to : OFF : statystyki MQI nie będą generowane ON : statystyki MQI będą generowane dla każdego połączenia z menadżerem kolejek STATINT : Określa częstotliwość w sekundach, z jaką statystyki są generowane STATQ : Określa poziom logowania informacji o kolejkach Możliwe wartości to : NONE : statystyki nie będą generowane dla kolejek OFF : statystyki nie będą generowane dla kolejek, które maja ustawiony atrybut STATQ na QMGR ON : statystyki będą generowane dla kolejek, które maja ustawiony atrybut STATQ na QMGR Poniższa tabela zawiera parametry komunikatu PCF dla danych typu statistics dla operacji na kolejkach.
Poniższa tabela zawiera parametry komunikatu PCF dla danych typu statistics dla kanałów.
Poniższa tabela zawiera parametry komunikatu PCF dla danych typu statistics dla operacji MQI.
Po włączeniu monitorowania statystyk typu accounting są one generowane i umieszczane w kolejce systemowej SYSTEM.ADMIN.ACCOUNTING.QUEUE. Komunikaty te są sformatowane w postaci PCF. Parametry dla menadżera to: ACCTCONO : Określa, czy w aplikacji jest możliwe nadpisanie ustawień ACCTMQI oraz ACCTQ menadżera kolejek Możliwe wartości to : SAME : atrybuty nie są zmieniane DISABLED : aplikacja może nadpisać ustawienia ACCTMQI oraz ACCTQ menadżera kolejek za pomocą pola Options struktury MQCNO podczas operacji MQCONNX ENABLED : aplikacja nie może nadpisać ustawienia ACCTMQI oraz ACCTQ menadżera kolejek za pomocą pola Options struktury MQCNO podczas operacji MQCONNX ACCTINT : Określa częstotliwość w sekundach, z jaką statystyki są generowane ACCTMQI : Określa poziom logowania dla operacji MQI Możliwe wartości to : SAME : atrybuty nie są zmieniane OFF : operacje nie są logowane ON : operacje są logowane ACCTQ : Określa poziom logowania dla kolejek Możliwe wartości to : SAME : atrybuty nie są zmieniane NONE : operacje nie są logowane dla kolejek i nie może to być zmienione za pomocą atrybutu kolejki ACCTQ OFF : operacje nie są logowane dla kolejek, które mają atrybut ACCTQ ustawiony na QMGR ON : operacje są logowane dla kolejek, które mają atrybut ACCTQ ustawiony na QMGR Parametry kolejki to: ACCTQ : Określa poziom logowania dla kolejki Możliwe wartości to : SAME : atrybuty nie są zmieniane QMGR : zachowanie zależy od parametru ACCTQ menadżera kolejek OFF : operacje nie są logowane dla kolejki ON : operacje są logowane dla kolejki Poniższa tabela zawiera parametry komunikatu PCF dla danych typu accounting.
Monitorowanie real-time polega na zbieraniu informacji online o działaniu kanału lub statusie kolejki.Informacje takie możemy uzyskać po odpowiedniej konfiguracji w narzędziu WebSphere ME Explorer lub poprzez komendy MQSCDISPLAY QSTATUSlub DISPLAY CHSTATUS Parametry dla menadżera to: MONQ : Określa poziom logowania informacji dla kolejek Możliwe wartości to : SAME : Atrybut nie jest zmieniany NONE : Monitorowanie dla kolejek jest wyłączone i nie może to być zmienione za pomocą atrybutu kolejki MQNO OFF : Monitorowanie dla kolejek jest wyłączone dla kolejek, które mają atrybut MQNO ustawiony na QMGR LOW : Monitorowanie dla kolejek jest włączone na niskim poziomie dla kolejek, które mają atrybut MQNO ustawiony na QMGR MEDIUM : Monitorowanie dla kolejek jest włączone na średnim poziomie dla kolejek, które mają atrybut MQNO ustawiony na QMGR HIGH : Monitorowanie dla kolejek jest włączone na wysokim poziomie dla kolejek, które mają atrybut MQNO ustawiony na QMGR MONCHL : Określa poziom logowania informacji dla kanałów Możliwe wartości to : SAME : Atrybut nie jest zmieniany NONE : Monitorowanie dla kanału jest wyłączone i nie może to być zmienione za pomocą atrybutu kanału MONCHL OFF : Monitorowanie dla kanału jest wyłączone dla kanałów , które mają atrybut MONCHL ustawiony na QMGR LOW : Monitorowanie dla kanału jest włączone na niskim poziomie dla kanałów, które mają atrybut MONCHL ustawiony na QMGR MEDIUM : Monitorowanie dla kanału jest włączone na średnim poziomie dla kanałów, które mają atrybut MONCHL ustawiony na QMGR HIGH : Monitorowanie dla kanału jest włączone na wysokim poziomie dla kanałów, które mają atrybut MONCHL ustawiony na QMGR MONACLS : Określa poziom logowania informacji dla kanałów typu cluster sender Możliwe wartości to : SAME : Atrybut nie jest zmieniany NONE : Monitorowanie dla kanałów typu cluster sender jest wyłączone QMGR : Monitorowanie dla kanałów typu cluster sender jest zależne od parametru MONCHL menadżera kolejek LOW : Monitorowanie dla kanałów typu cluster sender jest włączone na niskim poziomie MEDIUM : Monitorowanie dla kanałów typu cluster sender jest włączone na średnim poziomie HIGH : Monitorowanie dla kanałów typu cluster sender jest włączone na wysokim poziomie Parametry kolejki to: MONQ : Określa poziom logowania informacji dla kolejki Możliwe wartości to : SAME : Atrybut nie jest zmieniany QMGR : Monitorowanie dla kolejki jest zależne od parametru MONQ menadżera kolejek OFF : Monitorowanie dla kolejki jest wyłączone LOW : Monitorowanie dla kolejki jest włączone na niskim poziomie MEDIUM : Monitorowanie dla kolejki jest włączone na średnim poziomie HIGH : Monitorowanie dla kolejki jest włączone na wysokim poziomie Parametry dla kanału to: MONCHL : Określa poziom logowania informacji dla kanału Możliwe wartości to : QMGR : Monitorowanie dla kanału zależy od parametru MONCHL menadżera kolejek OFF : Monitorowanie dla kanału jest wyłączone LOW : Monitorowanie dla kanału jest włączone na niskim poziomie MEDIUM : Monitorowanie dla kanału jest włączone na średnim poziomie HIGH : Monitorowanie dla kanału jest włączone na wysokim poziomie Exity są to specjalne aplikacje powiązane z kanałami MQ uruchamiane przez proces MCA. W zależności od tego jakiego typu są to exity i z jakim typem kanału są one związane, mogą mieć różne zastosowanie. Pozwalają one np. na weryfikacje strony klienckiej przy próbie połączenie i pozwolić lub nie na nawiązanie połączenia. Mogą służyć do manipulacji komunikatami zanim zostaną one odczytane przez aplikacje. Rozróżniamy następujące typy exitów: Message exit Ten typ exita jest wywoływany przy każdej obsłudze komunikatu. Tego typu exit jest wywoływany zaraz po wywołaniu metody MQGET przez proces MCA po stronie wysyłającej, przed wywołaniem metody MQPUT przez proces MCA po stronie odbierającej, oraz przy inicjacji i kończeniu pracy procesu MCA. Możemy np. za pomocą tego exita przed wysłaniem go po sieci treść komunikatu zakodować po stronie sender, a następnie odkodować po stronie reciever. Możemy tu również zmieniać dowolne pola nagłówka MQMD. Message-retry exit Tego typu exit jest wywoływany, kiedy nie udało się otworzyć docelową kolejkę. Możemy tu np. ustawiać jak często i z jaką częstotliwością ponawiać próbę umieszczenia komunikatu w kolejce. Receive exit Tego typu exit jest wywoływany zaraz po pojawieniu się transmisji po sieci oraz przy inicjacji i kończeniu pracy procesu MCA. Security exit Jest to chyba najczęściej spotykany typ exita. Tego typu exit jest wywoływany zaraz po zakończeniu procesu negocjacji przy starcie kanału po obu stronach oraz przy inicjacji i kończeniu pracy procesu MCA. Pozwala on na autentykację drugiej strony komunikacji. Za pomocą tego exita możemy po stronie odbierającej kanału oczekiwać na wysłanie przez drugą stronę hasła pozwalającego na komunikację. W takim przypadku po drugiej stronie kanału potrzebne jest zastosowanie innego security exita, który wysłałby takie hasło. Send exit Tego typu exit jest wywoływany przed transmisją po sieci oraz przy inicjacji i kończeniu pracy procesu MCA. Auto-definition exit Tego typu exit jest wywoływany, kiedy staramy się wystartować konał typu auto-definition. Możemy tu np. zmieniać definicję tworzonego kanału. Rozróżniamy następujące tryby wywołań exita: MQXR_INIT Ten tryb oznacza, że exit jest wywoływany po raz pierwszy. W tym miejscu możemy zainicjować zewnętrzne zasoby, oraz ogólnie zainicjować jego pracę. MQXR_TERM Ten tryb jest przeciwieństwem poprzedniego. Oznacza on, że exit jest w ostatniej fazie procesowania i to jest najlepsze miejsce do zwolnienia wszystkich zainicjowanych zasobów wcześniej podczas trybu MQXR_INIT. MQXR_MSG Ten tryb oznacza, że exit jest w trakcie procesowanie komunikatu. Tryb ten jest związany tylko i wyłącznie z exitami typu message. MQXR_XMIT Ten tryb oznacza, że exit jest w trakcie transmisji danych. Tryb ten jest związany tylko i wyłącznie z exitami typu send i receive. MQXR_SEC_MSG Ten tryb oznacza, że exit jest w trakcie procesowania danych security. Tryb ten jest związany tylko i wyłącznie z exitami typu security. MQXR_INIT_SEC Ten tryb występuje zaraz po pojawieniu się trybu MQXR_INIT w przypadku security exita po stronie reciever. Jeśli teraz zostanie zwrócona odpowiedź MQXCC_OK, to po stronie security exita typu sender zostanie wygenerowany tryb MQXR_INIT_SEC. Jeśli teraz zostanie zwrócona odpowiedź MQXCC_SEND_SEC_MSG lub MQXCC_SEND_AND_REQUEST_SEC_MSG, to po stronie security exita typu sender nie zostanie wygenerowany nigdy tryb MQXR_INIT_SEC tylko MQXR_SEC_MSG. Tryb ten jest związany tylko i wyłącznie z exitami typu security. MQXR_RETRY Ten tryb jest wywoływany w przypadku ponownej próby umieszczenia komunikatu w kolejce po pojawieniu się błędu. Tryb ten jest związany tylko i wyłącznie z exitami typu message-retry. MQXR_AUTO_CLUSSDR Ten tryb jest wywoływany w p | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
