 |
 |
 |
|
|
|
Måndag 4/11 9.00
Stuart Jones, IBM Hursley
What is MQSeries?
MQSeries är en sk. middleware-produkt för meddelandehantering.
Det programmet gör i enkla ordalag är att det skickar meddelanden
från en applikation till en annan. Om den mottagande
applikationen ligger på samma maskin som den skickande eller
inte, är ointressant. De båda applikationerna märker ingen
skillnad om de körs i samma server, på olika servrar i samma
lokal eller om de körs på varsin sida Atlanten. MQSeries är alltså kommunikation
mellan applikationer utan kunskap om maskiner eller nätverk. MQSeries ser
till att leverera meddelandet från Applikation A (Loan
Request i bilden) till Applikation B (Loan Terms
Security via kön Q5 eller Customer Information
via kön Q2 i bilden) med garanterad säkerhet, och det
är en av MQSeries styrkor. Leveransen av meddelandet är
garanterad till exakt ett meddelande! Inte 0 meddelanden
på grund av en krasch eller liknande, och inte 2 eller fler pga
att meddelandet gått olika vägar till målet. I och med att alla
anrop går via ett standardiserat API (MQI i bilden)
skyddas applikationerna från implementationstekniska problem,
så det är samma API på alla operativsystem och språk!
MQSeries har även fördelen att skicka meddelandet i flera steg. Det
första steget är att sändande applikationen sänder meddelandet
till den lokala queue managern. När meddelandet säkert tagits
över av den kan programmet fortsätta med annat. Queue managern
ser till att leverera meddelandet till rätt kö, oavsett om det är
en kö på den lokala queue managern eller om det är en kö på
en queue manager på en annan maskin. Om nätet inte fungerar
eller om mottagande queue manager inte är aktiv, kan meddelandet
inte skickas på en gång utan blir liggande kvar på den lokala queue
managern. När förbindelsen sedan återupptas skickas
meddelandet till den mottagande queue managern. Det mottagande programmet
behöver inte vara igång på den mottagande servern för att meddelandet
ska kunna skickas. Meddelandet blir då bara liggande i kön på
den maskinen tills det mottagande programmet körs och läser meddelandet!
Det ger en enorm flexibilitet då de olika ingående delarna inte måste
vara aktiva och tillgängliga samtidigt!
MQSeries har således en stabil grundfunktion med ett ganska
enkelt API, som kallas MQI (MQInterface), vilket gör det applicerbart
i många olika fall. Det enklaste är att använda MQSeries som
en säker transportmekanism för meddelanden från A till B. Det är
mycket säkrare än att skicka filer eller liknande då det i
MQSeries är full koll på transaktionerna och om en applikation
fått iväg meddelandet till MQSeries levereras det garanterat.
Om inte applikationen får iväg meddelandet till MQ kan hela
transaktionen rullas tillbaka, dvs även databastransaktioner mm.
På grund av denna säkerhet lämpar sig som sagt MQSeries mycket
väl som enkel meddelandeförmedling.
IBM har dock mer visioner än så. MQSeries kan användas som ett
lager mellan program för att tex fungera i en distribuerad miljö
med applikationer på flera olika servrar etc. Det här
diskuterades en del under konfrensen och finns med som beskrivningar
i andra sessioner.
Why MQSeries?
Stuart Jones jämförde MQSeries med de andra
kommunikationssystem som IBM 'definierat':
MQSeries family
Jones fortsate med att beskriva MQSeries-familjen. Den är ganska
komplex på samma gång som den, enligt IBM, är komplett (dock
ej SilliconGraphics och Apple). De flesta stora operativsystem
är med på listan, dock kategoriserade i olika grupper.
Grupperna delas in beroende på vilken kodbas som MQSeries är
byggd på. Det ställer till lite problem då det blir svårt
för IBM att upprätthålla samma funktionalitet i alla
versioner. IBM skiljer MQSeries-server-versionerna åt genom en Level1-nivå
och en Level2-nivå. Level2-nivå-system är de senaste och
innehåller en mängd nyare funktioner jämfört med de äldre
Level1-nivå-systemen. Exempel på Level1-plattformar är VMS och
SCO Unix, medans exempel på Level2-plattformar är OS/2, Windows
NT, AIX, OS/400 mfl. Det finns också en tredje variant som
lanserats nyligen; MQSeries for Windows. Det är en serverversion
som bantats ner för att kunna köras på Windows 3.11/95, och
det innebär tex att MQSeries for Windows95 inte kan hantera
klienter, utan bara server-server-kommunikation. Det är ingen
stor nackdel, för Windows95 skall inte användas som en riktig
MQ-Server utan IBMs ide med detta är att MQSeries ska kunna följa
med ut på fältet i bärbara datoer, och köras i existerande
applikationer. När meddelande skall skickas från applikationerna
läggs de i den lokala transmissionskön utan att programmen
märker att de körs utan nätkontakt. Nästa gång maskinen
jackas in i nätet, eller då MQSeries kommenderas att koppla upp
sig mot nätet själv (via MQSeries DialIn eller RAS) kommer de
lokalt lagrade paketen att skickas till den eller de kömanagers
som angetts tidigare.
MQSeries basics
Jones beskrev därefter hur ett meddelande egentligen ser ut. Det
består av en header och resten user data. Header-delen innehåller
information om meddelandet; vart det ska, varifrån det kom,
vilken tid det skickades, vilken ID-kod det har mm. Under meddelandets färd
mot kön som är målet rör MQ endast header-delen av
meddelandet och låter användardatat vara. Det innebär att det
går att skicka vilken typ av information som helst i MQ, tex
text, ljud, bilder eller filmklipp. Maxstorleken för ett MQ-meddelande
är 4Mb (skall dock ökas eventuellt till 100Mb).
En av de största fördelen i MQSeries är att applikationerna
som använder MQ slipper bry sig om vilket nätverk som de skall skicka
meddelanden genom. Det sköter MQSeries helt transparent. Inte
ens i MQSeries är alla delar nätverksmedvetna. En queue manager är uppdelad
i köhantering och kanalhantering. Det är endast programmen som
sköter om kanalerna (MessageChannelAgents MCAs) som hanterar
nätverkets unika delar. Resten av MQ kan vara
nätverksoberoende, och i så stor utsträckning som möjligt
även OS-oberoende.
Ytterligare en sak i MQSeries som är en stor fördel är att
applikationer som använder köer att skriva på inte behöver
bry sig om var det mottagande programmet egentligen befinner sig.
Det mottagande programmet kan köras på samma maskin, eller på
en annan maskin i nätet. Genom att MQSeries tar hand om
köhanteringen tror det skickande programet hela tiden att det är
en lokal kö som det skriver på, men i själva verket kan det alltså
vara en kö på en helt annan queue manager.
Vid diskussionen om MQSeries API (MQI) kom Jones in på
intressanta delar av MQ. Han berätade om det (relativt) lilla APIet
med dess möjligheter till transaktionskontroll. Alla meddelanden
som skickas eller tas emot kan ingå i en transaktion. Det är
något som man väljer vid användningen av funktionen. Om man
väljer att funktionen (GET/PUT) ska ingå i en transaktion ger
MQSeries möjlighet att göra rollback på alla GETs och PUTs som
skett mot MQSeries. Förutom att MQSeries har det här inbyggt
för meddelanden, finns det också möjligheter att göra det
genom en transaction manager, så som CICS, Encina, Tuxedo eller
annan. Det ger möjligheter att synkronisera MQs transaktioner av meddelanden
med andra typer av transaktioner, tex databasanrop. I några
operativsystem (AIX, HP-UX och NT (1997)) är MQSeries XA-compliant,
vilket betyder att alla transaktionsmonitorer som kan hantera
XA-resurser kan ha MQSeries med i transaktionerna.
I MQ finns det inga
begränsningar till hur många applikationer som får skriva till
en kö. Det finns heller ingen begränsning i hur många som får
läsa en kö, och det gör att det finns möjligheter direkt i MQ att
hantera lastbalansering. Om en process som jobbar mot en kö inte
hinner med att processa dessa meddelanden kan fler processer
startas och läsa samma kö. Med asynkron meddelandehantering (se
mer om det i andra seminarier som tex Advanced Messaging
Solutions eller MQSeries Three Tier is Enterprise
Client/Server) kan således en applikation trigga många
applikationer samtidigt genom att skicka meddelanden till dem.
Det ger en form av parallell körning (se bilden).
Lite för snabbt gick sedan
Stuart igenom dynamisk routing. Det var ett mycket intressant
ämne då det skulle kunna minska antalet kanaler på queue managers
dramatiskt, men tyvärr var det dock inte rätt forum för en
djupare diskussion om routing (den skedde senare i Distributed Queuing - How to Set up an MQSeries network).
Det handlade om att varje meddelande innehåller adressen till
den queue manager det ska skickas till och det kan användas för
routing (Se bilden där meddelanden från QueueManagerC
skickas till QueueManagerE via QMA och QMB). På
samma sätt innehåller varje meddelande en adress till vilken
queue manager och vilken kö som svarsmeddelanden skall skickas
till, och det kan användas till att skicka svaren från den mottagande
applikationen till en helt annan applikation än den som sände meddelandet
från början.
MQSeries är uppbyggt på MQServers och MQClients. Serverdelen
är hjärtat av MQ och det är det som hela MQnätet bygger på.
En MQServer innehåller en eller flera queue managers, vilka i
sin tur innehåller ett antal köer. Applikationer som körs på
en MQServer kan accessa köerna lokalt utan näthantering. En
MQClient är en lättare produkt för att få tillgång till de
möjligheter som en MQServer har, utan att behöva installera en
hel MQServer på kienten, vilket skulle kräva en hel del prestanda
och resurser. En Windowsklient har ingen anledning att köra en
hel MQServer lokalt (det går dock med en specialversion av
MQSeries som riktar in sig på bärbara datorer med Windows
3.11/95) men behöver skicka meddelanden precis som
serverbaserade program. Det görs med MQSeries clients. En klient
kopplar upp sig mot en server och skickar meddelanden till en kö
som finns på en kömanager på den servern. Den funktionalitet
som är inbyggd i MQ med att linan kan vara nere gäller dock
inte här. Linan till MQServern måste vara uppe för att
klienten skall kunna skicka sitt data. Det är dock ingen större
nackdel i de flesta fall då klienter kan vara användbara. Det
som istället är nackdelen med klienter är att ett klientprogram
inte kan köras på en server och vice versa! Det betyder att man
måste veta om applikationen ska köras på en klient eller på
en server.
Om triggers berättade inte Stuart mycket. Han berättade att det
gick att få MQ att starta program automatiskt så fort det lades
in meddelanden i en kö. Det kan vara ett bra sätt att strukturera
upp en applikation, men det är inte säkert att det alltid är
det bästa sättet att göra saker. Risken med det här sättet
att jobba är att det tenderar att likna RPC, och det är inte meningen
med MQSeries. Triggers kan dock vara en ypperlig funktionalitet inom
vissa områden dock, för varningar eller liknande.
Security
Inom ämnet säkerhet beskrev Stuart en del funktioner som finns,
och en del som inte finns, i MQ. När det gäller meddelandesäkerhet
i formen av avlyssning eller likande i nätet har MQ idag
inga inbyggda funktioner. Genom sk exits (se seminariet om MQSeries Exits) kan man modifiera data
innan och efter sändning över en kanal. Det gör att
kryptering, och även komprimering kan ske innan meddelandet
sänds, och sedan sker en dekryptering på andra sidan. Det här
kommer IBM att ändra på, och själva lansera egna funktioner
för detta.
När det gäller transaktionell säkerhet har MQ mycket bättre
stöd. IBM garanterar full säkerhet vid sändning av meddelanden,
och det går att ha lite olika angreppssätt på detta. Det som
Stuart visade som det traditionella sättet, med datahantering +
MQ-sändning på system A och sen MQ-mottagning + datahantering
på system B, med single UnitOfWork och two-phase commit, beskrev
han som bra endast i vissa fall. Det han ville förespråka var istället
att använda den inbyggda möjligheten i MQ. System A gör en
datahantering + MQ-sändning samt en commit. MQ garanterar nu att
meddelandet är säkrat i MQ-systemet. Det är första UOW. Andra
UOW är när MQ ser till att förflytta meddelandet till det
mottagande systemet. Tredje UOW är när System B gör en MQ-mottagning
+ datahantering samt commit. Det här sättet att hantera synkronisering med flera
punkter har en stor fördel då det stöder IBMs teori med
asynkron meddelandehantering och det håller lås kortare tider
på de dataresurser som är inblandat i transaktionen. Det
använder också fördelarna med MQ där inte båda systemen
behöver vara uppe samtidigt. Nackdelen är att eventuella
rollbacks måste skötas logiskt i programmen, men det var något
som löste sig i en asynkron design.
Stuart medgav att det inte var lämpligt i vissa fall, men dock i
det flesta, och så fick han sista ordet.