Asynkrona kommunikationsmönster, vägen till ett serviceorienterat nirvana?

Transkript

1 Asynkrona kommunikationsmönster, vägen till ett serviceorienterat nirvana? Projektarbete inom Dataföreningen Kompetens kurs Certifierad IT-Arkitekt, kurs 29 Författare: Andreas Öhlund Version: 1.0 Datum: Abstract Uppsatsen belyser den påverkan kommunikationsmönster har på viktiga kvalitetsattribut i en SOA. Valet av kommunikation styr även hur väl en ESB kan utnyttjas. Med hjälp att ett tydligt exempel så visas att publish and subscribe är det mönster som gör de största positiva effekterna på kvalitetsattribut och ESB utnyttjande :43:00 1

2 1 Sammanfattning I en serviceorienterad arkitektur(soa) måste man ta hänsyn till att kommunikation mellan tjänster är utsatta för en rad nya faktorer som inte funnit i tidigare arkitekturer. Exempelvis kan man inte längre ta förgivet att anropad tjänst befinner sig på ett snabbt nätverk nära anroparen när tjänsten kanske levereras från en server på andra sidan jorden. Ett felaktigt val av kommunikationsmönster kan skapa begränsningar vad gäller viktiga kvalitetsattribut och därmed riskera dyra förseningar och utebliven verksamhetsnytta för projektet. Om man väljer att investera i en Enterprise Service Bus (ESB) men inte designar sitt SOA och framför allt kommunikationen mellan sina tjänster med denna ESB i åtanke så är risken stor att man har köpt en dyr produkt som inte kan ge den nytta som motiverade inköpet. Det är farligt att tro man kan köpa sig ett fungerande SOA bara genom att införa en dyr ESB. För att belysa den påverkan valet av kommunikationsmönster har på olika kvalitetsattribut samt på vilka funktioner i en ESB som kan utnyttjas så analyseras ett scenario hämtat från försäkringsbranschen med hänseende på olika typer av kommunikation. Analysen visar att publish and subscribe är överlägsen Request/Reply vad gäller positiv påverkan på kvalitetsattribut och ESB-utnyttjande. Publish and subscribe medför dock att komplexiteten på lösningen ökar något men detta kan kompenseras genom att införa en ESB. Slutsatsen är att asynkron kommunikation och då främst publish and subscribe bör användas i så hög utsträckning som möjligt för att skapa robusta och högpresterande IT-system samt maximera nyttan av en eventuell ESB :43:00 2

3 Innehållsförteckning 2 Inledning Bakgrund Problem Syfte Avgränsning Målgrupp Metodval Teoridel Serviceorienterad arkitektur (SOA) Kommunikationsmönster Kvalitetsattribut som påverkas av kommunikationsmönster Enterprise Service Bus (ESB) Exempel på hur kommunikationsvalet påverkar kvalitetsattribut och ESB utnyttjande Synkron kommunikation Asynkron kommunikation Publish and Subscribe Slutsatser och rekommendationer Diskussion Ordlista Referenser :43:00 3

4 2 Inledning 2.1 Bakgrund Att snabbt kunna anpassa sina system till förändringar i verksamheten är en av de svåraste utmaningar som IT-avdelningarna står inför idag. En väl implementerad serviceorienterad arkitektur (SOA) är ett av viktigaste hjälpmedlen för att snabbt och kostnadseffektivt kunna leverera det systemstöd som verksamheten behöver. I ljuset av detta så finns det en övertro på att SOA automatiskt skall infria alla sina utlovade fördelar utan att sättet att utveckla IT-system anpassas. Detta gäller särskilt kommunikationsmönster som ofta tenderar att vara synkrona eftersom tidigare arkitekturer haft bra stöd för denna typ av kommunikation. Detta har förändrats i och med att SOA blivit den ledande arkitekturparadigmen. I kölvattnet av SOA försöker en rad tillverkare lyfta fram sina produkter som den ultimata lösningen för en framgångsrik SOA. Enterprise Service Buses (ESB:s) är ett bra exempel på en produkttyp som marknadsförs som en silver bullet med vars hjälp alla SOA initiativ automatiskt blir lyckade. 2.2 Problem Med en SOA måste man ta hänsyn till att kommunikation mellan tjänster är utsatta för en rad nya faktorer som inte funnit i tidigare arkitekturer. Exempelvis kan man inte längre ta förgivet att anropad tjänst befinner sig på ett snabbt nätverk nära anroparen när tjänsten kanske levereras från en server på andra sidan jorden. Ett felaktigt val av kommunikationsmönster kan skapa begränsningar vad gäller viktiga kvalitetsattribut och därmed riskera dyra förseningar och utebliven verksamhetsnytta för projektet. Om man väljer att investera i en ESB men inte designar sitt SOA och framför allt kommunikationen mellan sina tjänster med denna ESB i åtanke så är risken stor att man har köpt en dyr produkt som inte kan ge den return of investment (ROI) som var beräknad. Det är väldigt lätt att tro man kan köpa sig ett fungerande SOA genom att införa en dyr ESB-produkt. 2.3 Syfte Syftet med denna uppsats är att visa hur valet av kommunikationsmönster i en serviceorienterad arkitektur starkt påverkar viktiga kvalitetsattribut samt begränsar vilka funktioner i en ESB som kan effektivt kan utnyttjas. 2.4 Avgränsning Andra viktiga beslut för ett lyckat SOA införande så som uppdelning av tjänster baserat på verksamhetsmodeller m.m. kommer inte att behandlas i denna uppsats. 2.5 Målgrupp Uppsatsen riktar sig till IT-chefer, IT-Arkitekter samt övriga personer som på något sätt är inblandade i införandet av serviceorienterade arkitekturer. Man behöver inte vara en expert på systemutveckling för att följa resonemanget men grundläggande kunskaper inom systemutveckling och särskilt kommunikation mellan IT-system är givetvis ett plus. De viktigaste termerna finns beskrivna i ordlistan i kapitel Metodval Uppsatsen grundar sig till stor del på praktisk erfarenhet vad gäller serviceorienterade arkitekturer och systemutveckling generellt men även en del på inspiration från böcker som jag har läst :43:00 4

5 Uppsatsen kommer att presentera några praktiska exempel och runt dessa diskutera hur kommunikationsval inverkar på kvalitetsattribut och möjligheten till ESB-utnyttjande. 3 Teoridel I detta kapitel ger jag min definition på några av kärnbegreppen som uppsatsen är baserad på. Se referenser för en utförlig lista över de böcker som inspirerat till uppsatsen. 3.1 Serviceorienterad arkitektur (SOA) Om man ber två personer definiera SOA så får man mest troligt två stycken helt olika svar. Den definition av SOA som känns mest rätt för mig är: En arkitekturell strategi för att bygga system av självständiga tjänster. Jämfört med andra äldre arkitekturer så har SOA en rad fördelar. I ett SOA byggs system upp av en mängd olika tjänster och kan därför enkelt konfigureras om allt efter som kraven ändras vilket gör dem flexibla och enkla att förändra. Integration är en central del av SOA och det krävs inte längre stora och dyra integrationsprojekt för att olika system skall kunna kommunicera med varandra utan tid och resurser kan nu i högre utsträckning användas för att skapa verksamhetsnytta. SOA främjar återanvändning och gör det även enkelt att byta ut tjänster mot billigare och bättre motsvarigheter så snart sådana finns tillgängliga på marknaden. Kostnadseffektiviteten ger IT- avdelningen möjlighet att maximera nyttan av sina ITinvesteringar. Moderna verksamheter utsatta för hårdnande konkurrens gör att förutsättningar och krav förändras i allt snabbare takt. Den agilitet som SOA medför gör det enklare att klara av denna förändring och därmed öka livslängden för de enskilda systemen Begreppet tjänst En tjänst är väl inkapslad funktionalitet som tillhandahålls av en Service Provider och konsumeras av en Service Consumer. En tjänst har ett tydligt externt gränssnitt som definierar de funktioner som tjänsten levererar. Tjänster i ett SOA är ofta relativt grova och mappar ofta till olika avdelningar i verksamheten, ex. Ordertjänst, Kundtjänst, Lagertjänst osv. För många är begreppet tjänst synonymt med Web-Services. För mig är Web-Services bara är ett tranportsätt för meddelande mellan tjänster. Andra exempel på transportsätt är File Transport Protocol (FTP), Simple Mail Transport Protocol (SMTP) och meddelandeköer. Dock så är Web- Service den teknik som hjälpte SOA att bli plattformsoberoende så Web-Services betydelse för SOA:s framgång skall inte förringas. Kvaliten på den funktionalitet som varje tjänst levereras specificeras ofta i ett s.k. Service Level Agreement (SLA) vilket är ett kontrakt som innehåller fastställda värden på svarstider m.m. som en Service Consumer kan förvänta sig. Uppföljning av dessa SLA:s är ofta något som olika integrationsplattformar tillhandahåller. För att möjliggöra dynamisk upptäckt och routing av anrop mellan tjänster så inför man ofta ett så kallat Service Registry. Detta registry fungerar även som ett en katalog för tjänsterelaterad information som t.ex. tjänstens namn och adress, tillgängliga versioner och vilka SLA:s som tjänsten uppfyller :43:00 5

6 3.2 Kommunikationsmönster Kommunikation mellan tjänster i IT-system kan delas i två huvudkategorier, synkron och asynkron kommunikation. I det synkrona fallet så pausar anroparen all egen aktivitet och väntar tills den fått svar innan vidare bearbetning fortsätter. I det asynkrona fallet så väntar inte anroparen på svar utan fortsätter sin egen bearbetning för att vid ett senare tillfälle kontrollera resultatet av anropet i de fall detta är relevant. Dessa två typer av kommunikation går ofta under samlingsnamnet request/reply Den asynkrona kategorin kan ytterligare delas in i en tredje variant där anroparen inte bryr sig om att vänta på svar, s.k. fire and forget. Denna typ av kommunikation kallas ofta publish and subscribe och innebär att en publisher publicerar meddelande utan att på förhand veta vilka subscribers som är intresserade av detta meddelande. Exemplen i kapitel 4 kommer att ge en djupare förklaring dessa olika kommunikationsmönster. 3.3 Kvalitetsattribut som påverkas av kommunikationsmönster Nedan ger jag min definition av de kvalitetsattribut som oftast står högst upp på prioritetslistan i den typ av stora och verksamhetskritiska system där höga krav på olika kvalitetsattribut ofta finns. Med detta menar jag inte att valet av kommunikationsmönster är oviktigt i mindre system men de högre krav som ställs på ett större system innebär att val som påverkar kvalitetsattribut blir betydligt viktigare för ett lyckat slutresultat. Nedan följer definitioner på några av de viktigaste kvalitetsattributen som sedan kommer att analyseras i kapitel 4:a Prestanda Systemets förmåga att leverera avsedd funktionalitet under last. Viktiga mått kan vara svarstider för anrop, antal hanterade transaktioner/sekund osv Skalbarhet Med skalbarhet avser jag systemet förmåga att förstärkas med ytterligare hårdvara för att kunna hantera ökad last. Typiskt så brukar man tala om att skala upp (Scale up) och skala ut (Scale out). Scale up innebär att hårdvara på befintliga servrar förstärks ex. snabbare och fler processorer, mer minne och snabbare diskar. Scale out innebär att fler servrar lägg till. Typiska mått på skalbarhet är hur mycket mer last kan vi ta per ny server eller per ny processor. Den ultimata skalbarheten är linjär dvs. kapaciteten fördubblas om man går från 1 till 2 servrar denna typ av skalbarhet är oftast svår att uppnå Tillgänglighet Hur stor del at tiden som systemet funktionsdugligt och kan leverera den funktionalitet som användaren förväntar sig. Typiskt mått är procent av tiden som systemet fungerar samt Mean Time Between Failure (MTBF). En viktig faktor som ofta förbises vid beräkning av tillgänglighet är inverkan av externa system. I det fall en applikation har ett direkt beroende till ett annat system så beräknas den slutliga tillgängligheten för systemet som: Egen Tillgänglighet * Tillgänglighet för externt system Om vi tar ett exempel där vi har en egen tillgänglighet på 99.9% men är beroende av 2 andra system som har en tillgänglighet på 99.0% så hamnar den total tillgänglighen på: 99.9 * 99.0 * 99.0 = :43:00 6

7 Så i de fall man har höga krav på tillgänglighet så är det extremt viktigt att designa sina integrationer på ett sådan sätt att direkta beroenden undviks Modifierbarhet Med modifierbarhet syftar jag till hur enkelt systemet ät att anpassa till den förändrade krav som är oundvikliga under ett systems livslängd. I detta begrepp inkluderar jag även hur motståndskraftigt systemet är för förändringar i kringliggande system. Typiska mått kan vara antal kodrader/förändring, antal berörda moduler/ändring Testbarhet Testbarhet syftar till hur enkelt det är att testa det aktuella systemet. Faktorer som påverkar testbarheten är exempelvis möjligheter att kontrollera in och utdata i systemet, skapa stubbar för externa system, tillgång till loggar m.m. för felsökning osv. 3.4 Enterprise Service Bus (ESB) I och med att serviceorienterade arkitekturer blivit mer vedertagna så har de flesta leverantörer av integrationsplattformar anpassat sina produkter för att passa in i arkitekturer där integration inte längre är ett stort problem. Detta har gjort att fokus har flyttats från att möjliggöra kommunikation mellan olika tekniska plattformar och applikationer till att tillhandahålla funktionalitet för att underlätta, övervaka och styra kommunikation mellan tjänster. Dessa produkter kan sammanfattas med namnet Enterprise service bus (ESB). De viktigaste funktionerna i en ESB som är relaterat till valet av kommunikationsmönster är: Garanterad leverans (Durable Messaging) Användandet av denna funktion innebär att ESB:n garanterar att skickat meddelande kommer fram till destinationen även om mottagaren för tillfället inte kan ta emot meddelande. ESB:n ser även till att meddelandet endast levereras en gång Publish and Subscribe ESB ger i detta fall stöd för publicering av meddelanden som andra system kan prenumerera på. Alla hantering av prenumerationer och leverans av dessa meddelanden sköts av ESB:n Dynamisk routing och transformering av meddelanden De flesta ESB:s tillhandahåller funktionalitet motsvarande ett service registry. Detta gör att anrop (synkrona eller asynkrona) av tjänster sker via ESB:n vilket gör att mottagaren kan byta adress utan att anropande system påverkas. En förlängning på denna funktion är att regler kan konfigureras så att meddelanden skickas till olika mottagare beroende på data i meddelandet. En ESB kan även transformera meddelanden for att anpassa formatet för olika sändare/mottagare Övervakning All trafik genom ESB:n övervakas och loggas för spårbarhet. De flesta ESB:s har mekanismer för att hantera eventuella fel på en centraliserat och strukturerat sätt :43:00 7

8 3.4.5 Orkestrering Asynkrona kommunikationsmönster, vägen till ett serviceorienterat nirvana? Med orkestrering så ges användaren möjlighet att inom ESB:n exekvera egenutvecklad affärslogik. Den huvudsakliga användningen är att kombinera olika tjänster till en mer grovkorning tjänst eller för att inom ESB: exekverar olika affärsprocesser. Inom detta område finns det ett flertal standarder, exempelvis Business Process Execution Language (BPEL), som försöker skapa en universal syntax och därmed möjliggöra att importera/exportera denna typ av logik mellan olika ESB-produkter och verktyg. Detta är fördelaktigt då man har komplexa regler för hur meddelande skall hanteras. I de flesta bussar så utvecklas denna typ av funktionalitet med någon form av grafiskt gränssnitt. 4 Exempel på hur kommunikationsvalet påverkar kvalitetsattribut och ESB utnyttjande För att exemplifiera den påverkan som valet av kommunikationsmönster har så har jag valt ett exempel från försäkringsvärlden. Vid tecknandet av en ny bilförsäkring så är en av prisfaktorerna om den aktuella kunden har några tidigare bilskador registrerade. För att veta detta så måste försäkringssystemet få denna information från skadetjänsten som är master för denna typ av data. I exemplet utgår vi även ifrån att denna information är obligatorisk (vilket den är i de flesta fall) för att prisberäkning skall kunna göras. Jag kommer nedan att i tur och ordning presentera tre lösningsförslag som bygger på olika kommunikationstyper. Varje del åtföljs av en diskussion om hur lösningen påverkar kvalitetsattribut samt vilken nytta en ESB kan göra i varje enskilt fall. Figur 1 nedan visar en översikt på hur de olika systemen kommunicerar med varandra via en ESB. Försäkringssystem Enterprise Service Bus (ESB) Skadetjänst Figur 1: Kommunikationsöversikt 4.1 Synkron kommunikation Vi börjar med en lösning som bygger på att försäkringssystemet gör ett synkront anrop till skadetjänsten och sedan inväntar svaret. Denna lösning är oftast den enklaste rent tekniskt och är därmed den som oftast väljs vid denna typ av problem. Figur 2 nedan är ett sekvensdiagram som visar de anrop som görs mellan försäkringssystemet och skadetjänsten :43:00 8

9 Försäkringssystem ESB Skadetjänst Teckna försäkring Finns skador registrerade Resultat ::Användare Beräkna försäkringspremie Figur 2: Synkron kommunikation Som vi ser så väntar försäkringssystemet på svar från skadetjänsten innan den fortsätter med sitt eget flöde. En variant på denna typ kommunikation är så kallad pollning vilket innebär att anropande system inte väntar på svar utan i stället periodiskt frågar anropat system om svaret finns att hämta. Detta göra att exekveringen kan fortsätta i anropande system men gör även att lasten ökar på anropat system samt att resurser hos anropande system krävs för att utföra pollningen. Denna typ av artificiell asynkronitet brukar oftast inte hjälpa och kan leda till försämrad prestanda m.m Påverkan på kvalitetsattribut Synkrona lösningar är oftast enklast att implementera och ger en låg komplexitet. Tyvärr så är priset för denna enkelhet att det externa systemet blir en direkt faktor i anropande systems tillgänglighet, skalbarhet och prestanda. I system med höga krav inom något av dessa områden så gör detta oftast att denna typ av kommunikation är utesluten. Tabell 1 nedan beskriver vilken påverkan synkron kommunikation har på de valda kvalitetsattributen. Kvalitetsattribut Positiv påverkan Negativ påverkan Prestanda - Då försäkringssystemet anropar skadetjänsten så är både svarstider och kapacitet direkt beroende till prestandan i skadetjänsten. Skalbarhet - Då antal anrop till skadetjänsten relaterar 1 till 1 med antalet anrop till försäkringssystemet så är en uppskalning av försäkringssystemet beroende av att skadesystemet har ytterligare kapacitet för att ge positiv effekt. Med andra ord så kan skadesystemet bli en flaskhals försäkringssystemet :43:00 9

10 Kvalitetsattribut Positiv påverkan Negativ påverkan Tillgänglighet - Då anrop görs synkront är försäkringssystemets tillgänglighet direkt beroende av skadetjänsten gör att skadetjänstens tillgänglighet blir en direkt begränsande faktor för försäkringssystemets tillgänglighet. Modifierbarhet Testbarhet Enkelheten gör denna typ av kommunikation snabb att implementera och även relativt lätt att förändra. Denna typ av kommunikation ger ofta lösningar med låg komplexitet som därmed blir enkla att testa. Systemen är hårt knutna till varandra och förändringar i skadetjänstens gränssnitt kräver synkronisering med försäkringssystemet. För att kunna utföra integrationstester så kräv antigen tillgång till det externa systemet eller att en stubbe utvecklas. Tabell 1: Påverkan av kvalitetsattribut vid synkron kommunikation ESB Utnyttjande Vad gäller utnyttjandet av en ESB för att stödja synkron kommunikation så är möjligheterna relativt begränsade då en ESB främst är designad för asynkrona mönster. Dock så kan man få stöd med Dynamisk routing och transformering av meddelanden. Traditionellt har möjligheten att anropa system på andra plattformar varit en viktig feature men i och med Web-Services så är inte detta något som längre motiverar inblandning av en integrationsplattform eller ESB. Tabell 2 nedan beskriver hur valet av synkron kommunikation påverkar hur en ESB kan utnyttjas. ESB Feature Garanterad leverans Publish and Subscribe Dynamisk routing Möjligt utnyttjande För att inte riskera att låsa upp egna resurser och därmed riskera den egna stabiliteten vid uteblivet svar från det anropade systemet så används ofta timeouts vid synkrona anrop. Dessa är i regel i storleksordningen sekunder. Detta är särskilt tydligt i vårt exempel då online-användare väntar på svar från systemet. Detta gör att garanterad leverans inte kan utnyttjas i någon praktisk utsträckning då felaktigheter som gör att mottagaren inte kan svara oftast inte är avhjälpta inom ett sådant kort tidsintervall. Kan inte utnyttjas för synkrona anrop. Kan utnyttjas i viss mån för att uppnå en lösare koppling mellan provider och Consumer. Men den typ av dynamisk routing där innehållet i meddelandet styr till vilken provider meddelandet skickas passar väldigt sällan bra in i synkrona scenarion :43:00 10

11 ESB Feature Möjligt utnyttjande Övervakning/Felhantering Övervakning kan se vilka anrop som går fel. Men eftersom att anropen är synkrona så kan man endast konstatera att fel har uppstått så finns ingen möjlighet till proaktivitet. De åtgärder man kan utföra får i detta fall syfta till att kommande anrop inte skall råka ut för samma fel. Orkestrering Då orkestrering innebär att logik exekveras i ESB:n vilket ofta ger negativ effekt på svarstider så lämpar detta sig inte så väl för synkrona anrop som ofta är svarstidskänsliga. Tabell 2: Möjligheter till ESB-utnyttjande vid synkron kommunikation. Traditionellt sett har synkron kommunikation varit det naturliga valet då de flesta applikationer har exekverat i homogena miljöer och ofta på samma server. Detta har medfört att synkron kommunikation ofta väljs slentrianmässigt utan närmare eftertanke. I de flesta fall visar en djupare analys att kommunikationen med fördel kan bytas ut mot asynkrona alternativ. 4.2 Asynkron kommunikation I detta avsnitt skall vi titta närmare på hur en övergång till ett asynkront anrop påverkar lösningen. Som figuren nedan visar så liknar anropskedjan den i det synkrona fallet med den viktiga skillnaden att försäkringssystemet nu inte längre blockerar sin egen exekvering i väntan på svar från skadetjänsten utan kan nu utföra annan affärslogik under tiden. Rent tekniskt så löses detta ofta med hjälp av trådhantering eller någon form av kömekanism. Figur 3 visar kommunikationen mellan systemen i detta exempel. Försäkringssystem ESB Skadetjänst Teckna försäkring Finns skador registrerade Annan bearbetning i väntan på svar ::Användare Resultat Beräkna försäkringspremie Figur 3: Asynkron kommunikation Påverkan på kvalitetsattribut Då man nu kan utföra annat arbete medan skadetjänsten svarar på anropet så får detta positiva effekter på prestandan då skadeanropet nu längre inte är en lika stor faktor i den totala svarstiden. Tillgängligheten ökar då problem i skadetjänsten bättre kan hanteras än i det synkrona fallet. Exempelvis kan man erbjuda degraderade funktioner då problem i skadetjänsten nu längre :43:00 11

12 inte kan använda upp all den tid som försäkringssystemet har på sig att utföra sin verksamhetslogik. Tabell 3 nedan går i detalj på vilken påverkan asynkron kommunikation har på kvalitetsattributen. Kvalitetsattribut Positiv påverkan Negativ påverkan Prestanda Skalbarhet Tillgänglighet Svarstider och genomströmning förbättras då resurserna i försäkringssystemet kan utnyttjas bättre. Även skalbarheten ökar då försäkringssystemet nu är mindre begränsat av skadetjänstens prestanda. Men skadetjänsten är fortfarande en begränsande faktor för skalbarheten. Då det nu är enklare att begränsa effekterna av störningar i skadetjänsten så minskar detta den negativa påverkan som skadetjänsten har på tillgängligheten. - Fortfarande så utgör skadetjänsten en begränsning för försäkringssystemets skalbarhet även om påverkan är mindre än i det synkrona fallet. Skadetjänstens tillgänglighet är fortfarande en begränsande faktor. Modifierbarhet - Asynkron kommunikation av request/reply typ innebär alltid trådhantering i någon form och detta riskerar att komplexiteten på lösningen ökar och försämrar därmed modifierbarheten Testbarhet - På samma sätt som för modifierbarheten så ökar komplexiteten vilket i sin tur ger negativa effekter på testbarheten. Tabell 3: Påverkan på kvalitetsattribut vid asynkron kommunikation ESB utnyttjande I vårt aktuella exempel så har den asynkrona lösningen i stort sett samma nytta av en ESB som i det synkrona fallet. Detta på grund av att vi måste använda en relativt kort timeout då användaren väntar på svar från systemet. I andra typer av scenarion där längre väntetider är acceptabla så ökar dock värdet av en ESB där funktioner som garanterad leverans samt övervakning/felhantering i större grad kan utnyttjas :43:00 12

13 Tabell 4 nedan beskriver vilken påverkan asynkron kommunikation har på möjligheterna till utnyttjandet av en ESB. ESB Feature Garanterad leverans Publish and Subscribe Dynamisk routing Möjligt utnyttjande I vårt exempel så har asynkron kommunikation inte heller möjlighet att utnyttja garanterad leverans i någon större utsträckning. Men i det fall när asynkron kommunikation används mindre interaktiva scenarios (ex. long running transactions ) där längre svarstider är acceptabla ger asynkron kommunikation möjlighet att i högre grad utnyttja denna typ av funktionalitet. Kan inte utnyttjas då denna funktion kräver kommunikation av typen fire and forget. Exempel på detta tas upp i nästa lösningsförslag nedan. Samma som i det synkrona fallet Övervakning/Felhantering På samma sätt som i fallet med garanterad leverans så är det ingen skillnad mellan synkron och asynkron kommunikation. Men i scenarios av typen long running transactions så kan övervakning ge möjlighet till att aktivt avhjälpa kommunikationsfel och på så sätt undvika att applikationerna tvingas hantera dessa. Orkestrering Samma som i det synkrona fallet Tabell 4: Möjligheter till ESB-utnyttjande vid asynkron kommunikation Sammanfattningsvis så ser vi att asynkrona anrop där man kräver ett svar från anropad tjänst ger en viss fördel över sin sykrona motsvarighet och ger viss positiv effekt vad gäller kvalitetsattribut. Dock så är möjligheten att till fullo utnyttja en ESB fortfarande mycket begränsad. 4.3 Publish and Subscribe I detta sista exempel tittar vi på vilken effekt ett asynkront kommunikationsmönster av typen Publish and Subscribe har på lösningen. Som figur 4 visar så har kommunikationen nu bytt riktning och försäkringssystemet är nu en prenumerant på skadeinformation från skadetjänsten. Detta innebär att försäkringssystem nu alltid har den skadeinformation som behövs för premieberäkning tillgänglig och behöver därmed inte göra ett externt anrop för att hämta denna information :43:00 13

14 Försäkringssystem ESB Skadetjänst Ny eller uppdaterad skada Skadetjänsten publiserar skadeinformation Teckna försäkring Finns skador registrerade ::Användare Beräkna försäkringspremie Figur 4: Publish and Subscribe Då detta kommunikationsmönster ger möjlighet att skapa tjänster som är löst kopplade till varandra så minskar de begränsande effekter som hårt kopplade system 1 har på varandras kvalitetsattribut. Denna lösning har negativ effekt på modifierbarhet då denna typ av lösning ofta är mer komplex än de övriga exemplen. Detta är inte oväntat då det är allmänt känt att prestanda och modifierbarhet ofta motverkar varandra. Så det gäller att hitta en lagom balans mellan dessa. Om man väljer denna typ av kommunikation så är det även viktigt att man utreder vilka funktionella krav som finns vad gäller aktualitet på information. Om det t.ex. inte är accepterbart med data äldre än 24 timmar så måste ett SLA upprättas och övervakas så att åtgärder kan vidtas om skadesystemet inte kan leverera information i den takt som försäkringssystemet kräver. Lösningen inför även en risk att felaktigheter i implementationen gör att informationen misstämmer mellan de olika systemen. Detta ställer givetvis högre krav på övervakning och rutiner än i de tidigare fallen. Vid denna typ av kommunikation är det även viktigt att tänka på det ökade lagringsutrymme som krävs då information nu dubbellagras. För att hantera detta är det viktigt att filtrera och transformera informationen så att ingen onödig information dubbellagras. I vårt exempel kan detta vara att alla fält utom personnummer och skadedatum transformeras bort samt att endast skador som avser privatpersoner (om systemet nu endast hanterar privatpersoner) filtreras bort. 1 se för en diskussion om detta fenomen :43:00 14

15 Tabell 5 nedan ger en mer detaljerad beskrivning av denna påverkan: Kvalitetsattribut Positiv påverkan Negativ påverkan Prestanda Skalbarhet Tillgänglighet Modifierbarhet Testbarhet Inget anrop krävs längre till skadesystemet vilket gör att prestanda ökar i paritet med svartiden för anropet till skadetjänsten. Generellt kan man säga att detta mönster minskar det totala antalet anrop som förekommer inom en SOA. Med denna typ av kommunikation är antalet anrop till skadetjänsten inte längre kopplat till antal anrop i försäkringssystemet vilket gör att skadetjänsten inte längre är en begränsande faktor för skalbarheten Då denna typ av kommunikation skapar en lös koppling mellan subscriber och publisher och detta ger positiva effekter på tillgängligheten. I vårt fall är nu skadesystemet inte längre en begränsande faktor för försäkringssystemets tillgänglighet. Det faktum att en publisher inte har något beroende och inte känner till sina subscribers gör det extremt lätt att utöka listan av subscribers utan någon som helst modifikation av publisher. Det faktum att informationen finns tillgänglig lokalt gör att integrationstester förenklas då man nu inte måste ha tillgång till det externa systemet i fråga för att kunna göra produktionslika tester Detta mönster ger en komplexare lösning än de andra kommunikationsmönstren och ställer högre krav på infrastruktur, styrning och övervakning. Det finns en risk att missa att testa felfall där t.ex. det externa systemet inte levererar data i den takt och kvalitet som krävs. Tabell 5: Påverkan av kvalitetsattribut vid "publish and subscribe" ESB utnyttjande Då syftet med en ESB till stor del är att stödja asynkron kommunikation är det inte överraskande att denna typ av kommunikation har stor nytta av en ESB. Användandet av Publish and :43:00 15

16 subscribe gör att man ofta har ett större tidsintervall på sig att slutföra kommunikationen än de andra mönstren. Detta gör att funktioner som garanterad leverans, orkestrering m.m. i högre grad kan utnyttjas av denna typ av kommunikation. Tabell 6 nedan beskriver detta i detalj. ESB Feature Garanterad leverans Publish and Subscribe Dynamisk routing Möjligt utnyttjande Garanterad leverans är en naturlig förlängning av Publish and subscribe i syfte att minimera risken att uppdateringar till subscribers tappas bort. Detta ger även möjlighet att skicka fire and forget meddelande vilket minskar belastningen på publisher ytterligare. Denna funktion är ju som namnet tyder på specifikt gjord för denna typ av kommunikation. Dynamisk routing kan utnyttjas för att skapa mer intelligenta prenumerationer där en subscriber ex. kan prenumerera på orders med ett ordervärde > 100 SEK eller bara kunduppdateringar där adressen har ändrats. Övervakning/Felhantering Det faktum att man nu har längre tid på sig att slutföra anrop gör att övervakningen nu möjliggör avhjälpning av fel utan att kommunicerande system måste skicka om meddelanden. Detta Orkestrering Denna funktion kan med fördel utnyttjas för att skapa intelligentare integrationer. Tabell 6: Möjligheter till ESB-utnyttjande vid "publish and subscribe" För att lyckas med denna mer händelsestyrda arkitektur så krävs en tydlig strategi och en stark arkitekturavdelning som kan kräva att omliggande system skall tillhandahålla funktionalitet genom Publish and Subscribe. Här är en väl förankrad informationsmodell extra viktig för att undvika eventuella missförstånd av innebörden av den information som flödar mellan system samt att möjliggöra för eventuella framtida subscribers att bedöma om tjänsten passar för deras behov. För att öka chansen till återanvändning så bör man vara lagom generell när man tar fram vilket data som meddelanden skall innehålla så att nya subscribers förhoppningsvis kan utnyttja tjänsten i framtiden men samtidigt vara så specifik så att det blir enkelt för befintliga prenumeranter att använda tjänsten. Kommunikationsmönstret publish and subscribe är överlägsen de andra mönstren vad gäller tillgänglighet, prestanda och skalbarhet men innebär även en ökad komplexitet samt högre krav på rutiner och dokumentation. 5 Slutsatser och rekommendationer Som exemplen i kapitel 4 visar så innebär publish and subscribe stora fördelar för system där kraven på prestanda, skalbarhet och tillgänglighet är höga. Priset för detta är en ökad komplexitet och högre krav på övervakning och felhantering. Ett lämpligt sätt att hantera detta är att införa en ESB som är väl lämpad hjälpa applikationerna att hantera denna komplexitet samt bistå med övervakning m.m. Det faktum att SOA nu börjar bli den dominerande arkitekturparadigmen gör att förutsättningarna för kommunikation mellan system/tjänster drastiskt förändras från att ha befunnit sig i en relativt kontrollerad och homogen miljö till en mer heterogen där svarstider, latens m.m. kan variera drastiskt utan förvarning. Detta gör att de hårda kopplingar mellan :43:00 16

17 system som request/reply kommunikation innebär gör systemen väldig känsliga för störningar. Detta gör att problem i en tjänst ofta sprider sig till andra tjänster vilket kan få ödesdigra konsekvenser tillgänglighet och prestanda i en SOA. För att skapa en robust SOA bör man därför sträva efter att använda asynkron kommunikation och framför allt publish and subscribe i så stor utsträckning som möjligt och använda sig av en ESB för att kompensera för den ökade komplexiteten m.m. Detta är en utmaning som inte bör underskattas då synkron request/reply kommunikation ofta sitter i ryggmärgen systemutvecklare. Som analysen i kapitel 4 visar så har valet av kommunikationsmönster stor inverkan vilken nytta en ESB kan tillföra. Detta är något jag vill trycka särskilt på då jag i mitt jobb ofta stöter på IT-avdelningar som har gått på försäljarnas argument att införandet av en ESB automatiskt leder till en lyckad SOA-implementation utan några övriga insatser. Inget kan vara längre från sanningen då införandet av en ESB bör vara en naturlig del av övergången till en mer händelsestyrd arkitektur där asynkron kommunikation är det dominerande mönstret. Så oavsett vad ESBleverantörerna säger så måste man inse att införandet av en ESB även kräver förändringar av hur man internt utvecklar/införskaffar tjänster och applikationer. Jag tror att nyckeln till en bra arkitektur att hitta en lagom avvägning mellan SOA och händelsestyrd arkitektur. Avslutningsvis vill jag ge några råd som förhoppningsvis bidra till ett ökat användande av asynkrona kommunikationsmönster. Valet av kommunikation är extremt viktigt så analysera situationen noggrant och välj det mönster som passar bäst. Synkron kommunikations långa historia gör tyvärr att den ofta väljs slentrianmässigt Publish and subscribe fungerar särskilt bra vid informationsintegration där det ofta är lämpligt att prenumerera på uppdateringar av olika verksamhetsobjekt. Skolboksexemplet är en kundmaster som publicerar kund och adressuppdateringar. Låt införandet av en ESB drivas av behovet att underlätta asynkron kommunikation mellan dina tjänster och applikationer och inte av en försäljare eller en artikel i ett inflight Magazine Skapa en förståelse för betydelsen av att välja rätt kommunikationsmönster genom att utbilda din personal och själv föregå med gott exempel! 6 Diskussion Att skriva en uppsats var betydligt mer jobb än jag hade förväntat mig. Det jag upplevde som svårast vara att tvingas motivera de olika slutsatser som dras i uppsatsen. I vissa fall så insåg jag att jag hade fel så detta har varit mycket lärorikt. Uppsatsen baseras på den litteratur som jag läst under mina år som arkitekt så underlag och litteratur har varit relativt enkelt att hitta. Om jag hade haft mer tid så hade jag gärna fördjupat mig i hur SOA och händelsestyrd arkitektur påverkar varandra och hur man kan kombinera dessa på ett bra sätt. Arbetet med uppsatsen har stärkt min övertygelse att asynkron kommunikation är en viktig framgångsfaktor för IT-projekt och förhoppningsvis kan uppsatsen hjälpa mig att motivera arkitekter och systemutvecklare att bygga mer asynkrona lösningar i framtiden :43:00 17

18 7 Ordlista Agilitet BPEL Long Running Transaction Routing SLA SMTP Med agilitet i samband med SOA så syftar jag på hur enkelt det är att göra förändringar och anpassningar i arkitekturen för att tillgodose nya verksamhetskrav. Ju enklare det är att göra förändringar desto mer agil är arkitekturen. Business Process Execution Language är en syntax för att definiera affärsprocesser så att dessa kan automatiseras. Long running transaction är affärstransaktioner som pågår under en längre tid och därför inte kan använda sig av normala tekniker för transaktionshantering. Routing är logik som beroende på uppsatta regler bestämmer till vilken mottagare ett visst anrop skall skickas. Ett så kallat Service Level Agreement definierar med vilken kvalitet en viss tjänst levereras. Typiska mått är öppettider, svarstider osv. Simple Mail Transport Protocol är ett protokoll som möjliggör sändning av mellan olika klienter. 8 Referenser [Buschmann 96] Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P., Stal, M. Pattern- Oriented Software Architecture: A System of Patterns. John Wiley, [Hohpe 04] Hohpe, G., Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison Wesley, [Nygard 07] Nygard, M, Release It!: Design and Deploy Production-Ready Software. The Pragmatic Bookshelf 2007 [Khoshafian 06] Khoshafian, S. Service Oriented Enterprises, Taylor & Francis Ltd, USA, 2006 [Udi Dahan Blog] :43:00 18