Transaction & Messaging Congress 96

MQSeries Three Tier is Enterprise Client/Server

Onsdag 6/11 14.00
Paul Williams, IBM Hursley

Den sista och tredje sessionen med Paul Williams blev en av de mest spektakulära på flera olika sätt! Han skulle äntligen visa sina teorier i praktiken; Hur ser det ut när man kör MQSeries Three Tier live. Målet var att demonstrera en applikation som de utvecklat i Hursley-labbet och som var byggt på den Three-Tier-produkt de har för OS/2. Dr Williams hade också svårt att skilja på de två OH-apparaterna där den ena visade OH-bilder och den andra visade skärmen. Den kraftigt vita presentationen från OH-bilderna sänkte bildskärmen vilket gav muntra kommentarer då Williams glömde att slå av den när han demade programmet! Williams muttrade som svar att det nu bara var barnen och djuren som saknades för att cirkusen skulle sluta i totalt kaos :-) Trots detta lyckades William under en timme att visa hur IBM tänkt när det gäller MQSeries som en motor i en three-tier-miljö, vilket var mycket intressant.

Paul Williams började sessionen med att repetera en del om 'Cooperative Processing', 'Business Event Driven Computing' och 'Asynchronus Message Handling' och hur det kräver system för att effektivt och enkelt implementera möjligheterna i sina applikationer. En av lösningarna för att uppnå det här är då MQSeries Three Tier. Det är ett system som

underlättar utveckling av 3T-program, samt en hel driftsmiljö för att hantera den komplexa meddelandehantering i MQSeries som blir följden.
möjliggör en uppdelade applikationsmodell med distribuerad logik.
tar hand om affärsregler för att hantera kopplingarna (workflow) mellan komplexa GUI- och server-applikationer.
ger möjligheten att återanvända redan existerande program utan att dessa behöver skrivas om. (Genom bryggor och länkar).
skyddar logiken i ett system från förändring. De olika logikdelarna skall inte förstöra den befintliga strukturen vid modifiering eller omskrivning.
använder MQSeries för att garantera leverans av meddelanden, ge oberoende av nätverkets struktur och status.
hanterar problematiken med late-message-policy som går ut på att MQSeries garanterar att meddelandet kommer fram, men i vissa fall i en applikation kan den tiden det tar för meddelandet att behandlas av mottagande applikation vara för lång. Det som ska ske i det läget tar 3T hand om. Det viktiga är att ge användaren information om att det tar tid för behandlingen av meddelandet så att det går att planera eller informera andra som är beroende av resultatet av körningen.
är helt transparent i VisualAge! Med hjälp av visuella komponenter hanteras all problematik med 3Ts implementation i programmet och programmeraren kan fokusera på att utnyttja möjligheterna istället.

3T Business Application Structure
3T definierar tre typer av programklasser:

Presentation logic som körs på arbetsstationer för GUI och snabb respons mot användare.
Business logic som körs på servrar för att få prestanda, dela kod och för att få säkerhet mot datalager inbyggd i systemet.
Data Logic körs i hosten för att få skalbarhet, transaktionshantering och datasäkerhet.

Ett program startas i GUI-miljön och tar hand om användarens aktioner. När användaren begär information som inte finns i presentationslogiken måste PL se till att anropa en modul i BL för att få fram datat. Det programmet som körs på en server någonstans får ett meddelande från 3T (via MQSeries) med information om vad som ska göras. I det här läget gäller det nu för 3T att bibehålla kopplingen mellan det program på användarens klient som anropade BL-programmet så att det svar som skall skickas tillbaka vet vart det ska. När BL-programmet kontaktat ett DL-program för att hämta rådatat, och sen behandlat det till begärt format, skickas det tillbaka som ett svar till programmet i klienten. Kopplingen mellan dessa två sköts av 3T helt transparent utan att de båda inblandade processerna behöver veta något om den underliggande logiken för meddelandehantering. I GUI-programmet tas det emot som ett event i GUI-miljön. Det är en normal message-loop (som bla hanterar användarens mustryckningar) som också tar hand om de business-events som kommer via 3T.

En funktion som finns inbyggd i 3T är att ha möjligheten att cacha information i BL-lagret. Om GUI-programmet i exemplet ovan vill ha mer information om samma data som det nyss begärt kan det finnas cachat redan i BL-lagret så att ett nytt anrop på mer detaljerad information inte behöver vandra hela vägen in i DL-lagret. För 3T gäller det att hantera den här strukturen så att det inte ligger gammal information och skräpar, men enligt Williams var det här en enorm fördel.

Det behöver heller inte vara GUI-delen som aktiverar systemet. Alla delar kan se till att starta affärshändelser via meddelanden i 3T. Det innebär att en BL-del kan starta ett PL-program för att få något att visas på skärmen. Det kan tex vara en koll vid en begäran av kundinformation som BL (eller DL) ser att det finns nya villkor eller erbjudanden som gäller den kund som information begärts för. BL kan då se till att aktivera PL för att presentera detta för användaren.

I ett system som bygger på 3T kan servrar skalas och data flyttas utan att applikationerna i klienter, eller andra delar som inte berörs, behöver känna till det. Williams uttryckte det som att ingen ville ha folk i användarledet som ska behöva känna till vad DB2 eller MVS eller CICS eller SNA betyder. Alla delar som har med datasystemets uppbyggnad och infrastruktur ska vara transparent för front-end-användare.

I en 3T-miljö finns det möjligheter att prenumerera på händelser. Likt en OO-miljö kan en process prenumerera på händelser från en annan process.
Det finns mer problem att tänka på när man går över till 3T. De beskrivs mer i de papper jag fick på sessionen.

How 3T applications run

En sk 'Job Viewer' är ett program som körs i PL-klienten för att dirigera och strukturera desktopen. När meddelanden kommer från 3T tar den hand om dem och skickar meddelanden till rätt fönster för rätt program.
En 'Presentation Logic Manager' körs i klienten och en 'Business Logic Manager' körs i applikationsservenr för att vänta på 3T-meddelanden. Så fort ett sådant anländer används ett regelverk för att se vilken applikation som skall köras för att behandla meddelandet, och hur ev. svar skall skickas med timeouter mm. Dessa båda ser till att applikationerna slipper känna till infrastrukturen i systemet. En applikation tar emot ett meddelande och levererar eventuellt ett svar.
PLM ser till att brygga mellan MQSeries-events och GUI-events.

Det finns en mängd hjälpmedel och verktyg för att åstadkomma en smidig 3T-miljö, men de gick inte Williams igenom utan lämnade det för vidare efterforskningar. Det står lite om det i dokumentationen, men det finns mer att hämta.

MQSeries Three Tier PL-klienter finns för Windows och OS/2, och BL-servers i OS/2 eller AIX. Som DL-server kan vilken MQSeries-plattform som helst fungera. Det beror på hur IBM utvecklar MQ3T vidare om det ska bli stöd för fler operativsystem. Det känns lite som att det är på lab-stadiet ännu, och de har ju idéer om att MQSeries ska kunna ligga till grund i Corba eller andra ORBer, Och vad blir Asynkron-DSOM?

Demonstration
Som demonstration hade Williams ett system som de utvecklat i Hursley. Det var ett litet banksystem som hanterade kunder. Han körde det i sin Thinkpad och han beklagade att det inte fanns möjligheter att köra fullskaligt med dataservrar och BL-servrar, men det visade i alla fall på att det var möjligt att skala upp datakraften vid behov, och möjligheten att köra på en maskin är ovärdelig vid testbruk vid utveckling.

Williams startade demonstrationen med att starta en 'Job Viewer'. Genom den kunde han styra alla fönster som hängde ihop med en körning på ett enkelt sätt. Genom den startade han en applikation som frågade efter en kund. När Williams valt kund sammanställde PL-programmet data om kunden i fönstret genom att först anropa en BL-modul för att sammanställa informationen. Anropet skedde via 3T-API medans svaret anlände som ett message in i message-loopen i GUIt. Samtidigt som informationen anlände och visades på skärmen poppade upp ett annat fönster på sidan om. Det fönstret visade information om något nytt lån eller så, som var möjligt att ansöka för just den här kunden. Det var således en händelse som triggats från BL-delen för att få PL att presentera det.

När Williams beordrade programmet att ta fram en mer detaljerad lista på de olika lån som kunden hade i banken anropades BL igen. Den här gången behövde dock inte BL gå ut till DL för att hämta datat utan det fanns cachat i 'systemet' och kunde därför serveras PL snabbare än om DL hade behövt blandas in. Det här syntes ju inte i demon, men beskrevs på OH-bilderna som Williams hade så svårt att synkronisera med demoskärmen.

Genom att kapa linan för en DL-modul kunde Williams simulera problemet med att meddelanden inte kommer fram inom en rimlig tid. Det hanterades av 3T så att PL-programmet inte blev höngande. Det som hände var att ingen information kom tillbaka för att fylla fönstret. Efter en stund informerades GUI-programmet att meddelandet var försenat men att det skulle behandlas så fort som det fick kontakt med DL/BL. När linan sedan slogs på rasslade det till och fönstret i PL-programmet fylldes med data och applikationen kunde fortsätta.

Williams körde inte så mycket mer, så egentligen syntes det inte så mycket av infrastrukturen och hur egentligen 3T hanterade de olika problemen med meddelanden och hur den sk. 'name-resolution' mekanismen fungerar för att få 3T att kunna skicka meddelandet till rätt applikation på rätt server och sedan få tillbaka det rätt. Det syntes dock att dfungerade i bakgrunden, och för att se mer får man nog ta och testa det hela.

Summary
Williams summerade genom att dra de fördelar som 'Cooperative Processing' ger, samt hur kraven tillgodoses genom MQSeries Three Tier. Han drog också hur en hel organisation drar fördelar av 'Commercial Messaging' osv. Samma grunder som tidigare.

Helt klart är three tier något att begrunda vid val av datastruktur, men när man tittar in i vad det innebär är det inga revolutionerande idéer eller teorier som ligger bakom. Asynkron körning av program genom meddelanden, som Williams gärna pratade om under de tre sessionerna, är i och för sig ett intressant perspektiv, och genom MQSeries är det enkelt att komma igång utan större problem, vilket gör att jag säker kommer att prova och se vad det kan ge. Kanske det resulterar i ett eget middle-ware innan det är klart?

Som en sista slutkläm hänvisade Williams till en undersökning från Gartner Group som gick ut på att det var viktigt att se över hur implementeringen av Three-Tier går till, för i vissa fall kan det vara dyrare än att köra two-tier!