IT-arkitekt A5 Hur stora ska egentligen tjänster vara? Sven-Håkan Olsson, Styrelsemöte.se Tjansteorientering_DF_2011-09-13..ppt © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Vad är nu en ”tjänst”? ”Tjänst” kan betyda lite vad som helst Att köpa IT-lösningar som tjänst – dvs en slags outsourcing… molntjänster, servicebyrå etc. Ett nutida sätt att strukturera IT-applikationer; tjänsteorientering – Service Oriented Architecture, SOA. SOA passar ofta bra både för tjänsteköp och för interndriftning. Då det finns stora integrationsbehov mellan köpt tjänst och interna system ger SOA extra fördelar. SOA-tjänsters förvaltning , versionering, drifthantering och kontraktshantering är ett stort och ibland eftersatt område.

SOA upp som en sol… Överdrifter: Precis som man överdrev potentialen med objektorientering i slutet av 80-talet, BPR i början på 90-talet, webb i slutet av 90-talet, så överdrev man kraftigt potentialen med SOA i mitten av 2000-talet  Rekylen och besvikelsen blev kraftig. Numera vågar man knappt säga SOA… Men fortfarande kan fördelarna med SOA bli stora, rätt använt 

Pris/fördel (cost/benefit) SOA $ Man överdrev alltså ofta fördelarna – systemflexibilitet som skulle leda till verksamhetsflexibilitet var det viktigaste argumentet för SOA, men gick aldrig att sätta mätetal på. Ökade kostnader för SOA togs sällan med i kalkylen!

Små, ”fingranulära” tjänster Ju mindre legoklossarna blir, desto fler helt olika saker går det att bygga av dem, resonerade många – jääättestor flexibilitet Resulterade i små, fingranulära tjänster T.ex. det som i traditionell design varit varsin SQL-tabell kunde nu bli varsin liten ”tjänst”, en ”SOA-domän”… Fingranulär SOA kunde bli jättedyr!

Vad blir dyrt med fingranulärt? Hopmonteringen av tjänsterna vid användning kunde bli dyr därför att väldigt många tjänsteanrop behövdes, även för enkla saker. Dvs ökad programlogik! (Kan i o f s bemötas med komposit-tjänster.) Prestanda kunde bli dåliga pga pratiga tjänsteanrop – tog tid att lösa, kostade dyrare hårdvara! Risk för uppsplittrad förvaltning , versionering, drifthantering och kontraktshantering! Trassel med datakvaliteten! …fel eller ofärskt data Fokus i min bild-serie

Hm, vad blir dyrt med grovgranulärt då, å andra sidan? Kan behövas ett ökat antal maskingränssnitt till tjänsterna pga att varje kombination av behov riskerar ge varsitt. Kan ev. bemötas genom frivilliga fält etc. Se dock upp med ”schweiziska armékniven” (där ETT enda maskingränssnitt döljer en jättestor kommando-repertoar) eftersom tjänstekontraktet riskerar bli helt urvattnat. Om maskingränssnitten blir mycket komplexa (och kanske dokumenteras dåligt) blir det svårt och därmed dyrt att lära sig att använda dem. Hitta kompromissen grovgranulärt – enkelhet. Dokumentera lättläst och noga.

ACID – ”tekniska transaktioner” IT-arkitekt ACID – ”tekniska transaktioner” A5 Atomicity, Consistency, Independency, Durability Kallas även atomära transaktioner, before-image-journaling eller allt-eller-ingen-uppdatering. Ibland behövs two-phase-commit (2PC Uppdateringar garanteras att inte kunna bli ”halva” Självklart för relationsdatabasuppdateringar men inte för systemintegration/SOA Utan ACID finns risk att t ex en försäljning registreras i handelssystemet men tappas bort i ekonomisystemet Egentligen borde man väl alltid sträva mot ACID, men... Anropande A sammansatt tjänst Anropsgränssnitt 2PC Tjänst B Tjänst C © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

...men synkron ACID för integration kan ge problem IT-arkitekt A5 ...men synkron ACID för integration kan ge problem Inkompatibla teknikmiljöer (trots XA-initiativet t ex) En del system-integrationsprodukter stöder inte alls ACID Ger hårda sw-beroenden (versionsbyten, leverantörsinlåsning etc) Risk får dålig ”uptime” Kan bli riktigt långsamt (faktor 10 för 2PC kan vara realistiskt) Dålig skalbarhet för 2PC pga långa databasinterna lås vilket ger deadlock-timeout Generellt sett alltför “hård koppling” – de flesta anser nog att SOA och synkron ACID vanligen är svårförenligt! Anropande A SOA-snitt. Vanligen EJ lämpligt med ACID och 2PC här! X Tjänst B Tjänst C © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

The Composite Service Pattern Bredvidläsning The Composite Service Pattern Very often Composite Service layers are included in architectures This is a picture from an IBM whitepaper, but many others use the same principles: How about ACID, all-or-nothing?

Lösning 1: ACID under ytan! IT-arkitekt Lösning 1: ACID under ytan! A5 Modellera tjänsterna så att inte flera skulle behövt anropas inom en uppdaterande ACID-transaktion (om nu detta är möjligt) Ha gärna ACID under ytan, inom tjänsten Ex 1: Modellera Kontoöverföring (inte Kontotrans och varsitt anrop med plus- och minusbelopp) Ex 2: Modellera fakturahuvud och fakturarader tillsammans i ett anrop Alltså motiv för TVÅ saker: Grov granularitet på tjänstegränssnitt (dvs större-men-färre anrop)… Grov granularitet på tjänsterna (dvs stora “SOA-domäner”) Men återanvändning etc är istället lättare med liten granularitet så denna fråga måste balanseras och optimeras! Anropande A SOA-snitt Ej ACID här Tjänst B ACID under ytan Nästa bild ACID © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Två sorters granularitet SOA-domäner Maskin- gränssnitt Grov granularitet på maskingränssnitt till tjänsten (dvs större-men-färre anrop) Krävs alltså ifall man ska kunna ha ACID inom tjänsten… fakturahuvud/fakturarader i ett skrivanrop Grov granularitet på tjänsterna (dvs stora SOA-domäner) Krävs i sin tur för att ovanstående ska gå; fakturahuvud och fakturarader måste lagras inom samma ”teknikruta” – SOA-domän – där ACID funkar Granularitetsdebatten blandar ofta ihop dessa två granulariteter

Lösning 1a: ACID under ytan + async Bredvidläsning IT-arkitekt Lösning 1a: ACID under ytan + async A5 Liknar Lösning 1, fast för att slippa så hård koppling mellan två lagringar görs den andra lagringen via äkta leveransskyddad asynkron kö Kallas ibland deferred processing – senarelagd bearbetning B måste ta ansvar även för C Bara ok ifall färskhetskraven är lägre i C Anropande A SOA-snitt Ej ACID här Tjänst B ACID under ytan Tjänst C Modul för deferred processing End-to-end async ACID (se nästa sida) Annan SOA-domän Kö © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Olika ACID-exempel för integration IT-arkitekt Olika ACID-exempel för integration A5 Pgm C Write 1 . . . Write 2 Allt-eller-inget Pgm D Read & delete . . . Write Asynk med äkta leveransskydd Enkel Pgm A Write 1 . . . Write 2 Allt-eller-inget 2PC-variant, synkont Pgm B Write 1 . . . Write 2 Allt-eller-inget © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Om ACID finns så borde väl BASE finnas – bas/syra  Basically Available - Soft-state - Eventual consistency Teoribygge kring principen att uppdatering kan tillåtas få ske strax istället för nu Föregående bild 1a:s “deferred processing” är ett exempel på BASE-principen Extra populärt i REST-världen och när man behöver massiv skalbarhet och hög tillgänglighet Se exempelvis http://queue.acm.org/detail.cfm?id=1394128

Lösning 1b: BASE i Composite Service IT-arkitekt A5 Lösning 1b: BASE i Composite Service Anropande A En mer generaliserad variant av 1a, där B och C ligger ”på samma nivå” Bara ok ifall färskhetskraven är lägre i både B och C. BASE – deferred update Obs, ifall A också har en databas så måste man lösa även den ACID/BASE-frågan Alternativ till säker kö kan kanske vara avancerad omsändnings-hantering + dublettkontroll (idempotency)… många REST- förespråkare gillar detta SOA-snitt Ej ACID här Sammansatt Tjänst BC ACID mot två köer oftast ok ACID Köer End-to-end ACID Tjänst B Uppdat strax Tjänst C Uppdat strax © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 1c: Read-only, sammansätt utan ACID-behov Bredvidläsning IT-arkitekt A5 Sammansatt tjänst A Anropare 1 WS Anropare 2 WS Smörgåsbord av tjänster SOA-snitt Se upp med sammansatta tjänster (composite services), det ser ju så förledande snyggt ut i Powerpoint fast kan ge problem. Men read-only är OK! Tjänst X Tjänst Y Tjänst Z WS wrap WS wrap Implem. av X Implem. av Y © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 1d: ”Fuska”, sammansätt med ACID i en teknik Bredvidläsning IT-arkitekt A5 Lösning 1d: ”Fuska”, sammansätt med ACID i en teknik Anropare 1 Anropare 2 WS WS Smörgåsbord av tjänster SOA-snitt Ej ACID Sammansatt tjänst A OO-anrop m uppdatering ACID Implem. av X WS wrap Implem. av Y Funkar endast bra ifall samma programmerings- miljö i A, X, och Y ! Överväg noga – kan ge alltför hård koppling  Tjänst X Tjänst Y Tjänst Z Samma db eller 2PC  © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 2: Avstämningar! IT-arkitekt A5 = ? Sums for reconciliation Välfungerande 60-talslösning Skapa buntsummor, dagssummor e dyl i bägge ändar, skicka dessa en annan kommunikationsväg Manuell koll eller automatiskt larm Korrigera manuellt eller automatiskt Manuell korrigering kan mycket väl vara optimalt! Logga! Behövs för att kunna göra detektivarbete. Avstämning = eng. reconciliation © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 3: Visa upp uppdateringsfelen i användargränsnsittet !? Lösning 3: Visa upp uppdateringsfelen i användargränsnsittet Ifall det är ett användargränssnitt ovanpå tjänsteanropen går det ibland att låta felsituationen och efterföljande åtgärdsbeslut direkt överlämnas till användaren Kräver god felupptäckt Kräver användarvänlig dialogdesign Kräver tillräckligt kunniga användare Funkar inte bra server-till-server Logga! Behövs för att kunna göra detektivarbete.

Lösning 4: Optimerad sekvens + felupptäckt! Bredvidläsning IT-arkitekt Lösning 4: Optimerad sekvens + felupptäckt! A5 Anropande A Optimerad variant av ”sista utvägen”: Anropa uppdaterande tjänst först som har sämst sannolikhet att fungera, B i figuren Ifall det skulle bli fel i B, ha begränsad retry-loop i A eller låt användaren göra retry. Gör ej C-anrop. Tjänst B måste klara dubletteliminering (s k idempotency)! Anropa sedan C och hoppas att den inte kraschar (dock låg sannolikhet) Ifall det ändå blir fel, larma till lång verksamhetstransaktion för kompensering etc. Ej ACID stabil Tjänst C (uppdat) instabilare nät+tjänst Tjänst B (uppdat) © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 5: ”Kontrollerad inkonsistens” Bredvidläsning IT-arkitekt Lösning 5: ”Kontrollerad inkonsistens” A5 Tillåt ”kontrollerad inkonsistens” Modellera så att relaterade objekt kan få vara inkonsistenta innan de verkligen behövs T.ex. tillåt fakturarader utan fakturahuvud temporärt (ifall separat fakturahuvudskrivning skulle misslyckas) Kräver felupptäckt och rättningsåtgärd innan fakturan kan sändas ut Dyr och komplex undantagshantering Inte ovanlig i praktiska fall, t ex bokföring: Avstämningar före bokslut © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Lösning 6: Långa verksamhetstransaktioner! IT-arkitekt A5 Lösning 6: Långa verksamhetstransaktioner! Klar trend nu att koppla lösare vid system-integration (delvis pga SOA/Web Services-ökningen) Måste därvid tänka att en ”transaktion” kan pågå i timmar, dagar eller veckor innan den är definitiv Eng. Long Running Transaction (ordet transaktion här är alltså inte ett tekniskt begrepp som i SQL) Flera av de tidigare lösningarna i bildserien är i själva verket varianter av långa verksamhets-transaktioner Behövs ”compensation schemes”, dvs backnings-funktioner insystemerade i applikationerna (radera inte – betona spårbarhet jmfr kreditfaktura)! Dessa initieras manuellt eller automatiskt Håll ev ordning på dem med tekniskt workflow / orchestration, gärna baserat på BPEL etc OBS att modellering, programmering och testning av långa verksamhetstransaktioner är mycket tidskrävande och dyrt! Se alltså dessa som en sista utväg! © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Summering Naiv användning av tjänsteorientering leder till borttappade uppdateringar, ofärskhet – sämre infokvalitet! Ibland tas inte detta på allvar alls. Om möjligt, bäst är 1: ACID under ytan Därefter 1a/1b: BASE (men drar mer anropskod + idempotency-kod) De andra lösningarna kan vara nyttiga men de knuffar över undantagshantering till verksamhets-processerna och därmed till användarna! Asynk är mer stabilt men leder till mindre färskt data All asynkron felhantering är mycket dyrare att utveckla/testa och riskerar ha fler kvarvarande buggar Alla långa verksamhets-transaktioner är dyra att utveckla/testa, håll nere antalet!

Summering Naiv användning av tjänsteorientering leder till borttappade uppdateringar, ofärskhet – sämre infokvalitet! Ibland tas inte detta på allvar alls. Om möjligt, bäst är 1: ACID under ytan Därefter 1a/1b: BASE (men drar mer anropskod + idempotency-kod) De andra lösningarna kan vara nyttiga men de knuffar över undantagshantering till verksamhets-processerna och därmed till användarna! Asynk är mer stabilt men leder till mindre färskt data All asynkron felhantering är mycket dyrare att utveckla och testa och riskerar ha fler kvarvarande buggar Alla långa verksamhets-transaktioner är dyra att utveckla/testa, håll nere antalet! $  $  Grov-granu-lärt $  $  $ 

(Glöm inte bort transaktionslogg också, brorsan till ACID) Bredvidläsning (Glöm inte bort transaktionslogg också, brorsan till ACID) Alternativa namn: Skrivjournal, förändringslogg, deltalogg, after-image-journaling Säkerställer att information inte ska försvinna. Skyddar mot filsystemskrasch, applikationsfel och mot operatörsmissgrepp etc. Ibland vill man även kunna skydda från användarmissgreppp (ta tillbaka läget som det såg ut för tre dagar sen t.ex, gärna selektivt vilket är svårare) Transaktionsloggen ska finnas separat lagrad så den kan ”återspelas” (s.k. roll-forward) efter att en backup tagen en viss tidpunkt återlagts Måste utformas noga i samklang med backuprutinen (Obs att ett s.k. journaling file system normalt är en enklare sak, för ett annat ändamål - directorykonsistens) Transaktionslogg finns vanligen inbyggd i relationsdatabaser, men ibland kan man vilja designa in en till, på tjänstenivå. Kan dessutom ge fler parallella nyttigheter: Kunna injicera last för test. Felletning. Möjlighet till fördjupad missbruksanalys (auditing). Ej så SOA-problematisk som ACID.

Misslyckad uppdatering --> larm Bredvidläsning IT-arkitekt Misslyckad uppdatering --> larm A5 Undantaget kan vara logiskt. T ex: Inga pengar på kontot Slut på varan i lagret Undantaget kan vara tekniskt. T ex: Ena databasservern har hög last och ger timeout En uppdaterande Web Service över Internet ger timeout medan lokal uppdatering gått vägen Löser ut olika logik beroende på behov, t ex compensation-verb © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Välkända ”långa verksamhetstransaktioner” Bredvidläsning IT-arkitekt Välkända ”långa verksamhetstransaktioner” A5 Inneboende affärslogik – saker går inte att göra exakt samtidigt Kreditkort: Hämtar ut hyrbil, prel-debitering görs, kompenseras bort när slutlig summa debiteras Lägenhetsköp Handpenning först Alla lån-handläggningar görs ofta hos en bank med säljare/köpare närvarande, skulle nåt inte funka får banken kompensera alla transaktionerna Aktiehandel Flera anledningar till att köp kan backas på kvällen T ex pga säkerhetsövervägande Sedeltrassel i bankomat Debitering görs på kontot, bankomaten registrerar problemet i sin logg, nästa dygn kompenseras debiteringen Dagens IT-värld har delvis glömt bort de här idéerna! © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Trendspaningar, artiklar Kolla gärna in www.trendspaning.se där jag regelbundet deltar kring tekniktrender etc På min enkla sajt www.definitivus.se finns också ett artikelarkiv för trendspaningarna och annat som successivt fylls på, exempel på ämnen: Lösa transaktioner och rätt data REST och sånt… Facebook eller eID för inloggningen? Hur den lösa kopplingen ändå blir hård Till den som sitter med klistret ESB:n är död – leve ESB:n! + denna bildserie Här gärna av er med kommentarer etc…

Deltagare i styrelse eller nämnd IT-arkitekt A5 Mötessekreterare / dokumentsystem Tack för mej! Dok Styrelsemöte.se Struktur, hantering, säkerhet, loggning… Sven-Håkan Olsson www.styrelsemote.se www.definitivus.se 0708-840134 sven-hakan.olsson[hos]styrelsemote.se Dok Dok Läsplatta Persondator © Dataföreningen Kompetens / Sven-Håkan Olsson. Enstaka bilder får användas om källan anges Deltagare i styrelse eller nämnd © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson