 |
 |
 |
|
|
|
Tisdag 5/11 16.10
Mark Taylor, IBM Hursley
Mark Taylor började med att beskriva MQ så som det beskrivits i
de flesta av sessionerna. Ingen skillnad förutom att han profilerade
sig lite genom att säga att han inte ansåg att det nödvändigtvis
var motiverat i alla förekommande fall att beskriva MQ med den
bild man visat i de andra sessionerna. Bilden visade två
applikationer. AppA skickar ett meddelande till AppB via en
MQ-kö. AppB behandlar meddelandet och skickar ett svar tillbaka
till AppA via en annan MQ-kö. Det här ansåg inte Taylor var en
bra användning av MQ. Han tyckte att det visade på en
traditionell programmeringsstill, där man lika gärna kunde använda
RPC! Det här uttalandet var definitivt ett personligt och inte nåt
som IBM stod för!
Languages
Han visade på lite olika språk som hade API-er
för MQ.
Det förvånade mig klart att Taylor inte hade med Smalltalk
på en sådan lista med OO-språk. Jag har MQ-stödet installerat för
VisualAge/Smalltalk, men om Smalltalkstöd hördes inte ett dugg.
Programming in C - the header files
I C används header-filer för de olika
funktionerna i MQ. Det som är ytterst viktigt med dessa är att
använda rätt h-fil för rätt OS. Om man använder en
Unix-header under Windows får man knepiga resultat i MQ.
Det är också mycket viktigt att använda de typer som
definierats i MQ. Använd MQLONG istället för long
om det är en 32-bits integer som behövs. Tex, i 64-bits Unix kan
en long vara 64 bitar.
För C-programmerare kan en del datakonstruktioner kännas ovana,
tex är strängar som beskriver namn mm paddade med space
istället för att vara null-terminerade. Det här beror på att
APIet ska vara generellt för alla operativsystem och programspråk.
Programming in C - the library files
Lib-filerna är grovt sett uppdelade i två olika
kategorier. En för serverbaserade program, och en för program
som skall köras som MQ-klienter. Det är tyvärr två olika
system, vilket gör att ett länkat program inte kan köras både
i klient och server! Det är en stor nackdel och något som IBM
jobbar på att få bort. I framtiden kanske
de två olika lib-filerna kommer att migreras ihop till en enda.
Det finns en del olika filer för de olika operativsystemen. I
Windows måste man ta hänsyn till 16 eller 32 bits, och i Unix
är det en annan lib-fil för flertrådiga program.
Threading
MQ har inga problem med flertrådiga program. Varje
tråd har en egen connection till en queue manager, och det går
inte att dela connections mellan trådar. Det gör att det bara
är i en tråd som en UOW körs. För en del OS är det samma
API, ex Windows NT och OS/2, medans det är olika APIer för
andra OS, tex Unix. Taylor ansåg inte att man skulle använda threading
i Unix då det är för ospecificerad funktionalitet. Det kan
finnas ett läge där det är försvarbart och det är om MQ körs
i endast en tråd. I vissa OS, tex AS/400, finns inte trådhantering
i MQ alls.
Flow patterns - an RPC application using MQSeries
Här kom Taylor tillbaka till applikationsdesignen.
Han visade en modell där AppA skickade ett meddelande till AppB
och fick ett svar tillbaka. Det var inte rätt modell att använda MQSeries,
utan det var bättre att använda RPC i det läget. Han knöt an
till de ideer som Williams beskrev i Advanced
Messaging Solutions vilket gick ut på att tänka asynkront i applikationsmodelleringen.
Att vänta på ett svar från ett anropat program var inte bra
design!
Taylor beskrev det här som ett av olika 'application flows' och
var det som var enklast i sin uppbyggnad och därför det första
att visa för att beskriva MQ, tyvärr. Det finns dock anledningar
till att använda en liknande modell i MQ för 'RPC' och det är
om meddelandet kräver 'persistency', dvs att det skall
återskapas vid en recovery efter en krasch.
Taylor visade en del flow patterns där MQ skulle komma mer till
sin rätt, och där de asynkrona modellidéerna skulle användas.
För att exemplifiera detta visade taylor ett exempel på
parallell meddelandekörning av processer. En applikation skickade
tre meddelanden på tre köer för att starta tre processer, och
utan att vänta på svar. De tre processerna behandlar meddelandena
och skickar svar till en svarskö. Den startande applikationen
(eller en annan applikation om man ska tänka asynkront) får de
tre svaren och kan avancera i applikationen. Det finns dock
frågor kring det här förfarandet.
Design example problem
Taylor visade som sista stora avsnintt ett
designexempel av ett telefonkatalogsystem där den totala
katalogen var sammansatt av ett antal kluster som samverkade. En
fråga från det sökande programmet skickades till närmsta
katalog-server och den såg sedan till att svara de träffar den
hade i sin katalog, och sedan se till att skicka frågan vidare
till andra servrar osv. Han visade flödet i ett antal 'Data Flow
Diagrams' och det finns hos mig.De utgick från asynkron
programmering och det som var en av de svåra bitarna i det hela
var hur man skulle synkronisera svaren tillbaka innan man ansåg
att det var ett korrekt sammansatt svar som erhållits, och detta
utan tunga loopar för att kolla köerna hela tiden. För att
lösa detta kunde man använda en workflow manager, som FlowMark
från IBM. Det var något som Williams diskuterade i Advanced Messaging Solutions tex.
Questions?
Taylor svarade på några frågor som var extra
intressanta: