Presentation laddar. Vänta.

Presentation laddar. Vänta.

1 Hur stora ska egentligen tjänster vara? Sven-Håkan Olsson, Styrelsemöte.se Tjansteorientering_DF_2011-09-13..ppt.

Liknande presentationer


En presentation över ämnet: "1 Hur stora ska egentligen tjänster vara? Sven-Håkan Olsson, Styrelsemöte.se Tjansteorientering_DF_2011-09-13..ppt."— Presentationens avskrift:

1 1 Hur stora ska egentligen tjänster vara? Sven-Håkan Olsson, Styrelsemöte.se Tjansteorientering_DF_ ppt

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

3 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  3

4 4 Pris/fördel (cost/benefit) SOA $ Fördel 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!

5 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! 5

6 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 6 Fokus i min bild-serie

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

8 8 ACID – ”tekniska transaktioner” •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... Tjänst B Anropande A sammansatt tjänst Anropsgränssnitt Tjänst C 2PC

9 9...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! Tjänst B Anropande A SOA-snitt. Vanligen EJ lämpligt med ACID och 2PC här! Tjänst C X

10 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: 10 How about ACID, all-or-nothing? Bredvidläsning

11 11 Lösning 1: ACID under ytan! •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! Tjänst B ACID under ytan Anropande A SOA-snitt Ej ACID här ACID Nästa bild

12 Två sorters granularitet •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 12 SOA-domäner Maskin- gränssnitt

13 13 Lösning 1a: ACID under ytan + async •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 Tjänst B ACID under ytan Anropande A SOA-snitt Ej ACID här Kö Tjänst C Modul för deferred processing End-to-end async ACID (se nästa sida) Annan SOA-domän Bredvidläsning

14 14 Olika ACID-exempel för integration 2PC-variant, synkont Pgm B Write 1... Write 2 Allt-eller-inget Enkel Pgm A Write 1... Write 2 Allt-eller-inget Pgm C Write 1... Write 2 Allt-eller-inget Pgm D Read & delete... Write Allt-eller-inget Asynk med äkta leveransskydd Allt-eller-inget

15 Om ACID finns så borde väl BASE finnas – bas/syra  •BASE –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 15

16 16 Lösning 1b: BASE i Composite Service •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 Sammansatt Tjänst BC ACID mot två köer oftast ok Anropande A SOA-snitt Ej ACID här Köer Tjänst B Uppdat strax End-to-end ACID Tjänst C Uppdat strax ACID

17 17 Lösning 1c: Read-only, sammansätt utan ACID-behov Tjänst X SOA-snitt Tjänst Y Smörgåsbord av tjänster Tjänst Z Anropare 2 WS 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! Implem. av X WS wrap Implem. av Y Sammansatt tjänst A Anropare 1 WS Bredvidläsning

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

19 19 Lösning 2: Avstämningar! •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 Sums for reconciliation = ?

20 20 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. !?

21 21 Lösning 4: Optimerad sekvens + felupptäckt! •Optimerad variant av ”sista utvägen”: 1.Anropa uppdaterande tjänst först som har sämst sannolikhet att fungera, B i figuren 2.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. 3.Tjänst B måste klara dubletteliminering (s k idempotency)! 4.Anropa sedan C och hoppas att den inte kraschar (dock låg sannolikhet) 5.Ifall det ändå blir fel, larma till lång verksamhetstransaktion för kompensering etc. Tjänst C (uppdat) Anropande A Ej ACID Tjänst B (uppdat) instabilare nät+tjänst stabil Bredvidläsning

22 22 Lösning 5: ”Kontrollerad inkonsistens” •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 Bredvidläsning

23 23 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!

24 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! 24

25 Summering •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! 25 Grov- granu- lärt $  •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)

26 26 (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. Bredvidläsning

27 27 Misslyckad uppdatering -- > larm •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 Bredvidläsning

28 28 Välkända ”långa verksamhetstransaktioner” •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! Bredvidläsning

29 29 Trendspaningar, artiklar •Kolla gärna in där jag regelbundet deltar kring tekniktrender etc •På min enkla sajt 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…

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


Ladda ner ppt "1 Hur stora ska egentligen tjänster vara? Sven-Håkan Olsson, Styrelsemöte.se Tjansteorientering_DF_2011-09-13..ppt."

Liknande presentationer


Google-annonser