Transaction & Messaging Congress 96

Advanced Messaging Solutions

Måndag 4/11 15.30
Paul Williams, IBM Hursley

Det första som slog mig när jag satte mig för att vänta på sessionens start var den enorma lunta som delades ut som hand-out. Det var 138 sidor fördelade på 57 sidor OH-bilder och 61 sidor beskrivningar! Luntan finns uppe hos mig om det är någon som är intreserad av att läsa i den. Den var mycket intressant och det finns en beskrivning av de idéer och teorier som Williams lade fram i klartext, alltså inte bara OH-bilder!

Det Paul Williams pratade om i denna, och de två andra sessionerna han höll i (se Total Solutions with IBM MQSeries Bridges, Gateways and Bindings och MQSeries Three Tier is Enterprise Client/Server), var genomgående baserat på hans och IBM Hursleys idéer om hur framtida datasystem (applikationer, nätverk, meddelandehantering, administration mm) skall vara designade. Hans grundfilosofi är att skapa system med ett koncept som han kallade 'Commercial Messaging'. Det är all form av meddelandehantering, så som 'Workflow Computing', 'Object Messaging', 'Mobile Messaging' osv. Detta har IBM beskrivit i 'IBM Messaging Business Solutions Framework'. IBMs mål är att MQSeries ska ta en strategisk roll i alla produkter som skapas för att underlätta 'Commercial Messaging', oavsett om det är IBM-produkter eller inte.
Det är enligt Paul Williams mycket viktigt att ha en 'Business Approach' på MQSeries!

Williams började som de flesta med att beskriva fördelarna med MQSeries, men han gjorde det ur sin synvinkel med 'Commercial Messaging'. I och med MQSeries starka position och stora fördelar kan MQSeries användas i alla fall av meddelandehantering där hög säkerhet, nätverksoberoende, plattformsoberoende och flexibelt gränssnitt behövs, bland annat:

• Workflow Computing och Message Driven Processing var något som Williams gärna berättade om. Att designa sina system som 'Business Event Driven' är något som skall bli en grundsten i framtida design. Williams lanserade tesen 'Asynchronus Messaging and Computing' som är ett sätt att driva programflödet hårdare än normalt. Det sker genom att skapa affärshändelser i program och låta andra program ta emot dessa och reagera på dem. Det program som skapade händelsen väntar inte på svar utan kan istället koncentrera sig på att skapa nästa händelse. Till så stor utsträckning som möjligt ska de svar som kan behöva komma tillbaka tas omhand av andra program som reagerar på de nya händelser som skapats. På det här sättet kan flera processer startas samtidigt av en och samma applikation, och det med ett underliggande system som är säkert och garanterar leverans av händelsemeddelandena, dvs MQSeries.
• Cooperative Processing är IBMs sätt att knyta ihop processer och de affärshändelser som skickas mellan dem. MQSeries Three Tier är en produkt som designats för att ta hand om de problem som uppstår när meddelanden skall skickas mellan program på olika plattformar och den flödeskontroll som måste ske för att processerna skall kunna synkronisera sina meddelanden.
• Enterprise Messaging skall möjliggöra för total Client/Server där klienter som web-browsers och Lotus-Notes skall kunna använda företagets hela nätverkskapacitet för att få sina tjänster utförda.
• Data replication kan skötas av MQSeries för att replikera data mellan IBM-system och icke-IBM-system på ett standardiserat och enormt säkert sätt.
• Object Technology där MQSeries skall kunna tillhandahålla möjligheter för objekt att anropa metoder i varandra asynkront! IBM har målet att vara en standardprodukt även här, så samtal förs med bla OMG.
• Mobile med MQSeries fungerar utmärkt då MQSeries inte har något krav på sig att ha nätet uppkopplat vid applikationens sändtillfälle.

I en verksamhet som förändras, normalt eller genom BPR, höjs kraven på förändringstålig programvara. Med ny design och omskrivna klientprogram kan det bli svårt och omständigt att skriva om de hostbaserade programmen utan att behöva skriva om klienter mm igen. Genom att använda de idéer som Williams beskrev skall man kunna designa sitt system på ett sådant sätta att förändringar i både hostmiljö, men även genom nya typer av klienter, inte skall behöva slå längre ut än inom det egna delsystemets ramar. Detta möjliggörs med 'Commercial Messaging' och MQSeries!

Message Driven Processing (MDP)
Applikationsdesign skall baseras på meddelandehantering. Applikationerna baseras på enheter eller element, som kan utföra ett begränsat antal funktioner oberoende av de andra elementen som bygger upp en applikation. Ett element används genom att skicka händelsemeddelanden till det. Elementet bearbetar händelsen och den information som följde med och startar (i de flesta fall) ytterligare programelement genom att skicka händelsemeddelanden till dem. Det här låter lite som OO, men det är inte tänkt att vara det. Anledningen till att IBM inte vill prata OO om det här tankesättet är att alla delar i ett företags system skall kunna samverka i en dylik struktur, dvs även stordatorbaserade transaktioner.
Williams pratade om end-to-end-lösningar där web-klienter skall kunna komma åt funktionalitet och data lagrat i stordatormiljön! För att kunna lösa det här krävs nån form av flödeskontroll. Det kan bli enorma logiska flöden som på något sätt måste styras. Det kan göras tex med IBM FlowMark.
Det Williams poängterade här var att dagens gamla 'monolitiska' system måste brytas upp så att det går att använda de ingående delarna mer flexibelt, och att det blir tåligare mot förändringar i affärsprocesserna.

Cooperative Processing
För att få MDP att fungera på ett effektivt sätt måste det till något för att få de olika elementen att kommunicera med varandra utan att applikationerna själva behöver veta vilka program/element som existerar vart i nätet osv. Ett program som triggats av en händelse ska inte behöva veta vart händelsen kom ifrån utan enkelt kunna skicka ett svar (till en klients GUI, inte nödvändigtvis det sändande programmet/tråden) och låta systemet ta hand om resten. Problem som kan uppstå när program/element slutar att fungera eller ett meddelande inte kommer fram utan timeoutas är också något som måste överlåtas till en separat produkt, och det är MQSeries Three Tier. MQ3T är en MQSeries-baserad lösning som tillhandahåller delar i utvecklingsmiljön för att få program att enkelt hantera 3T-problematiken, samt en exekveringsmiljö där problemen som nämndes ovan hanteras. I MQ3T finns regler för hur meddelanden skall trigga processer/element och det ger möjligheter att hantera komplexa GUI- och server-program. I det här garanterar MQSeries leverans av meddelanden vilket är av mycket stor vikt i kritiska affärsverksamheter. MQ3T möjliggör en multi-tier-miljö där klienter och servrar interagerar på ett effektivt och förändringståligt sätt!

MQ3T definierar tre typer av applikationsklasser (dock ej OO):

• 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.

Bara för att det är three-tier behöver det inte innebära att det är tre maskinnivåer utan det kan vara ett stort antal maskiner, både servrar och klienter, inblandade.

Williams kommenterade att kombinationen med multi-tier och parallell meddelandehantering ger oslagbar kraft!

End-to-end solutions
I och med systemet som baserar sig på händelsemeddelanden, kan en rad olika klienter köra och använda systemet. Inte bara traditionella Windows- eller OS/2-klienter kan använda en MQ3T-infrastruktur. Javaprogram som körs i en webbrowser kan via MQs internet-gateway starta processer i systemet, och samma gäller för Lotus Notes-klienter. Genom de olika bryggor som finns mellan MQSeries och andra system finns också möjligheten att ta tillvara på redan existerande kod som skrivits i hosten (ännu bara IMS, men CICS kommer under 1997).

Object Messaging
Trots att Strukturerna ovan pratar om isolerade moduler som reagerar på händelsemeddelanden så är det ingen OO. Traditionella program bygger upp en infrastruktur som kan likna OO, men är det inte. När det gäller OO satsar IBM på objektorienterade lösningar och blundar inte för ORBar av olika slag. Williams berättade dock om den asynkrona delen av filosofin och att det gäller att hitta en modell där man kan applicera det asynkrona tänkandet på objektorienterade system. De var ute efter något som kan liknas vid ett asynkront DSOM, där man tar hand om tex oberoendet av tiden för leverans av ett meddelande, som ju är en viktig del i MQSeries.

Enligt Williams skall IBM satsa hårt på att vara med i de olika standardiseringsgrupper som jobbar för att få fram regler för hur distribuerad objektorientering ska gå till. De arbetar med OMG om ett asynkront Corba (eventuellt baserat på MQ), RFP för asynkron meddelandehantering och SOM-klasser som stöder Corba.

Mobile
I framtiden kommer det att bli viktigare och viktigare med kraftiga applikationer som körs mobilt och som kan kommunicera med företagsnäten. I benämningen mobilt ingår deltidskoppling mot företags-LAN, telefonuppringd (hotell) samt trådlös (mobil telefonuppkoppling). I det sammanhanget passar MQSeries bra, då det redan idag klarar fallen där nätet inte är uppkopplat då applikationerna sänder sina meddelanden. I framtida versioner av MQSeries måste dock en del förändringar och förbättringar göras, tex intellegenta transmissionskanaler, lättviktskärnor att köras i mindre kraftfulla operativsystem (finns redan i formen av ett MQSeries för Windows 3.11/95), regelbaserad kommunikation.

Enterprise Messaging
Williams pratade om att client/server-tekniken måste kunna skalas upp enkelt ända till enterprise-nivå, och till och med till inter-enterprise-nivå. Kombinera det med BPR som kräver nätverks-fokuserad dataanvändning istället för host-baserad dataanvändning och svaren är 'Commercial Messaging' i delformen 'Enterprise Messaging'. Enterprise Messaging innebär också möjligheterna att ta tillvara på de resurser som redan finns i organisationen genom transparent användning så att inte de nya klienter som kopplas in behöver känna till hur nätverket och resurserna är konfigurerade. De delar som bygger upp 'Enterprise Messaging' är:

• IBM MQSeries Link for Lotus Notes
  Klientplattformar är på OS/2, AIX och HP-UX. Planerat för NT och Solaris. Serverplattform kan vara vilken som helst av de plattformar MQSeries körs på. Dataflöde kan ske både från Notes och från MQ-servern. Allt sker transparent för användaren. Informationen ingår i dokumentet som vanligt Notes-data.
• LotusScript Extension (LSX) for IBM MQSeries
  Tanken är att MQSeries skall fungera transparent genom LSX-modulerna för att accessa data i MQ-servrar.
• IBM MQSeries support for the WorldWideWeb
  MQSeries Internet Gateway körs på web-servern och möjliggör MQ-access från web-browsern.
• IBM MQSeries Link for SAP R/3
  MQSeries länkar insig i R/3 på ett mycket R3-likt sätt.
• IBM Global Network (IGN) for IBM MQSeries

I exemplen ovan gäller det faktum att alla MQ-serverapplikationer som serverar klienterna med data inte är medvetna om vilken typ av klient som begär data. Det innebär att det krävs delar i en webserver för att HTML-konvertera det resultat som en MQ-applikation skickat tillbaka som svar på ett anrop från en web-klient. Om alla MQ-serverapplikationer har denna egenskap blir systemet mycket flexibelt då flera olika klienter kan använda samma datakälla.

Transactional Messaging
Williams gick i slutet av sessionen igenom en del om transaktioner och MQSeries. Det berättades i andra sessioner så det blev lite ytligt och inget att återge. Han tryckte dock på fördelarna på att bryta upp en traditionell single UOW med 2-phase-commit till en tripple UOW med single-phase-commit genom att använda leveransgarantin i MQ.

Egentligen är det här inget problem ansåg Williams då den asynkrona angreppstekniken löser mycket av det här!