Transaction & Messaging Congress 96

Exploiting MQSeries Features in Applications

Onsdag 6/11 8.45
Harry Halliwell, IBM Hursley

Halliwell började med att beskriva de fördelar som MQ kan ge applikationerna:

• Single multi-platform MQI gäller för samma programspråk mot olika operativsystem och olika nätverksprotokoll. Det behövs ingen detaljkunskap om nät och OS för att använda MQ i applikationer.
• Time independance, parallelism innebär att program inte alltid behöver vänta på svar. Ibland är det så att programmet vill ha ett svar, men för att anpassa sig till det asynkrona sättet att driva applikationerna ska inte några svar användas i den bemärkelsen.
• Assured message delivery är en stor fördel i MQ då meddelanden som skickas mellan applikationerna verkligen kan garanteras leverans.
• Faster application development beskrev inte Halliwell, men jag kan tänka mig att IBM anser att det går snabbare att slippa ta hänsyn till nätets funktionalitet i applikationen.

Single multi-platform MQI
How single? Fler och fler plattformar (Level2) klarar nu de mer avancerade möjligheterna som MQSeries erbjuder, och skall till slut gälla alla, så att det inte finns någon tveksamhet över vad som finns på vilka plattformar:

• Dynamic queues används för temporära svar. Skapas för det svaret och tas sedan bort.
• Message context beskriver från vem och när ett meddelande skickades.
• Confirm arrival/delivery kan användas för att bara få ett accept på leveransen, men det ska till ganska speciella anledningar för det då MQ garanterar leverans.
• Message expiry kan användas till att få en timeout på ett meddelandes leverans. Om meddelandet inte levererades tar queue managern bort det.
• Priority queues
• Get message order
• Message data conversion är en kraftfull funktion...om den används! Se alltid till att ha dessa flaggor påslagna vid hantering av meddelanden. Det går att specificera en konstant vid funktionsanrop (MQGMO_CONVERT) och det går att sätta på kanalen att det skall konverteras (CONVERT(Y)). Tänk bara på att det endast är strängar (och integers) som konverteras! Binärt data som strukturer i C eller liknande har ingen möjlighet att konverteras av MQSeries då den underliggande strukturen är okänd för MCAn.

Time Independence
Det är en enkel grund i MQSeries, men den kan ge avancerade möjligheter och är en av hörnstenarna i IBMs tanke på asynkron meddelandehantering och programexekvering!

• Separata processer kan användas för svaren från de anropade applikationerna.
• Inget krav på att applikationerna/processerna måste köras samtidigt. Ej heller krav på att nätverket måste vara uppe och fungerande för att applikationen ska kunna skriva meddelanden i köerna.
• Program kan triggas igång då meddelanden anländer. Det är en avancerad funktion som kan ge stora fördelar, men det gäller att tänka igenom lösningen innan för det kan finnas lägen då det här inte är en bra lösning.
  Ex. AppA skickar ett meddelande via QM1 till AppB på QM2/QX. QM2 lägger meddelandet i rätt kö, och iom att det är en trigger på kön skapar QM2 ett meddelande som läggs i en InitiationQueue. På QM2 körs en trigger monitor som märker när ett meddelande anländer till denna initieringskö. Triggermonitorn startar då den applikation/process som skall behandla meddelandet som nu ligger i QM2/QX.
  Det här ger en mängd fördelar:
  - Instantiering av processer sker vid behov
  - Man minskar mängden resurser som systemet kräver
  - Informationsflödet automatiseras
  

Det finns möjligheter i olika OS att hantera signaler; MVS-ECB, Tandem-IPC, VMS-SYS$WAKE osv.
Halliwell berättade också att det går att skriva sin egen triggermonitor, men att det var ganska svårt, och att det inte var rekommenderat. Det var dock ett vanligt MQ-program, så det var inget speciellt och annorlunda med det.

Då programmen inte har direkt kontakt, kan inte den sändande applikationen ha full kontroll på hur mottagningen gått utan får lugnt vänta på eventuellt svar. Timeouter vid väntan på dessa svar är inget enkelt problem att lösa. Det som Halliwell dock rekommenderade var att ha en svarskö på remote-queue managern med Message Expiry. Svaret kommer då att ligga kvar ett tag och efter timeouten raderas det. Det gäller då att ha en fungerande timeout på den lokala queue managern, men det måste hanteras logiskt i applikationen, tyvärr. Det finns ännu inget som hanterar detta i MQ, men det är en av funktionerna i MQSeries Three Tier.

Det finns en del andra möjligheter för det här också; Slå på rapporter från MQ vid olika händelser, eller kolla hur DLQn ser ut, eller kanske få MQ att skicka tillbaka olevererade meddelanden tillbaka till sändaren. En bra funktion är att få MQSeries att skicka händelseinformation när vissa gränser har uppnåtts i en queue manager, tex när antalet meddelanden i en kö har nått en viss nivå, eller en kanal har stannat.
Det finns ett antal köer som hanterar dessa events; SYSTEM.ADMIN.PERFM.EVENT, SYSTEM.ADMIN.QMGR.EVENT, SYSTEM.ADMIN.CHANNEL.EVENT.

Assured Delivery
När meddelanden läggs in i köer skapas de som 'persistent' eller 'non persistent'. Persistenta meddelanden garanteras av MQSeries att de kommer fram till den kö de skickats till. Oavsett vad som händer under tiden med kraschade system mm kommer dessa meddelanden att återskapas vid recovery av queue managers. Till skillnad från denna garanti hanteras icke-persistenta meddelanden utan någon säkerhet. Om en queue manager dyker eller kraschar garanterar inte MQSeries att det kommer att återskapas. De hanteras dock snabbare än de persistenta meddelandena. Det gäller att bestämma vilka meddelanden som är viktiga och vilka som inte är det innan man tar igång sitt system.

När en queue manager startas om efter en krasch kommer den att återskapa alla meddelanden som varit persistenta i alla köer. Queue managern håller reda på allt som hänt i en kö från tillfället då den senast var tom. data som förstörts av en krasch på grund av HW eller OS ligger kvar i köerna utan att upptäckas. Det är först vid eventuell leverans som meddelandet kan orsaka problem. Kan behöva annan åtgärd.

När en applikation läser eller skriver ett meddelande finns möjligheten att ange om MQSeries skall använda sig av syncpoint för transaktionen. Om applikationen inte använder syncpoints uppdateras kön direkt efter anropet och det finns ingen möjlighet att ta tillbaka åtgärden. Däremot om MQSeries används i en transaction genom att ange att syncpoint ska användas, kan allt som skett sedan transaktionen startades tas tillbaka med rollback (MQBACK). I en transaktion kan vissa MQPUTs och MQGETs använda syncpoint och andra inte.

Koordination av transaktioner kan som sagt ske i MQSeries, men det finns även möjligheter att använda en transaktionsmonitor för detta. Det finns flera alternativ och det beror mest på vilket OS man kör i. CICS eller Encina för Unix, CICS för MVS, CICS eller Tuxedo (eller Encina) för Windows NT. MQSeries är XA-kompatibelt (på en del plattformar tex Unix, NT) så vilken transaktionshanterare som helst som följer XA kan användas på de plattformarna. Med dessa transaktionshanterare får man också möjligheten att använda MQSeries i större transaktioner med fler resurser inblandade, för tex 2-phase-commits.
När det gäller syncpoints i en asynkron tillämpning finns det andra alernativ än 2-phase-commits i en enda UOW, nämligen tre UOWs med MQ som brygga (Se Welcome to MQ-Series avsnittet om Security).

Det finns också möjligheter att se på ett meddelande hur många gånger det blivit rollbackat. Det gör att om ett meddelande tex inte kan sparas i en databas kommer det antalet att öka, och programmet kan kolla det antalet för att se vad det skall göra med meddelandet. Något måste göras för de andra meddelandena ligger låsta bakom det problematiska meddelandet.

MQ-klienter hanteras inte riktigt så som program i en MQ-server så kolla det innan start!