1 IIR SOA Web Services för SOA-införanden IIR_WS_ _v2.ppt Sven-Håkan Olsson Transacsation

2 Teknik- eller verksamhetsorientering? •BÅDADERA! •Det ska inte behöva finnas en motsättning här •Båda delarna är nödvändiga villkor för att lyckas med IT-stödet till verksamheten

3 SOA = Web Services !? •SOA är främst en princip för applikations- samverkan, inte en teknik •SOA kan egentligen utföras med löst kopplad användning av många gamla tekniklösningar, t ex: –Unix-RPC –MS Named Pipes –IBM LU6.2 –CORBA –Java-RMI –MS DCOM •Men Web Services har oöverträffad kompatibilitet / interoperabilitet mellan olika teknikplattformar •Nästan alla organisationer har blandade teknikplattformar •SOA som smörgåsbord förutsätter därmed interoperabilitet  tekniken Web Services stämmer bra!

4 Web Services (WS) •Web Services har förstås inget med webb-tjänster att göra ;-) olyckliga ordval, sammanblandningsrisk •WS är datakommunikation maskin-till-maskin, med teknikdetaljer lånade från webben (protokollet http) •WS används vanligen server-till-server (men kan även vara klient-till-server)

5 Anropsmässig trelagers-stack ”Ren datakom”TCP/IP dominant idag”Ren datakom” HW Kommuni- cerande applikation Web Services t ex Integrations- teknik Jämför med den ”mera nertill detaljerade” sjulagers OSI- stacken

6 Definitioner i femlagers-stack ”Ren datakom”TCP/IP dominant idag”Ren datakom” HW XML-schema t ex Syntax- definition Semantik- definition Word-dokument eller RDF etc Semantik- definition Svårt Process- definition Visio-fil eller BPEL etc Process- definition Svårast Web Services t ex Välj integrations- teknik Överenskommelser Kontrakt

7 Definitioner i femlagers-stack ”Ren datakom”TCP/IP dominant idag”Ren datakom” HW XML-schema t ex Syntax- definition Semantik- definition Word-dokument eller RDF etc Semantik- definition Svårt Process- definition Visio-fil eller BPEL etc Process- definition Svårast Web Services t ex Välj integrations- teknik Överenskommelser Kontrakt

8 Svaret på frågan om SOA, EAI och Allting ”Ren datakom” Syntax- definition Semantik- definition Process- definition Välj integrations- teknik EAI, ESB WS Grov mappning 42 SOA EAI = Enterprise Application Integration, ESB = Enterprise Service Bus

9 ”Tekniska transaktioner” •Uppdateringar garanteras att inte kunna bli ”halva” - utan tekniska transaktioner risk att t ex en försäljning registreras i faktureringen men tappas bort för lagersaldot •Kärt barn har många namn: atomära transaktioner, obrytbara uppdateringar, ACID, unit-of-work, allt-eller-inget-uppdatering, commit/rollback, varianten two- phase-commit (2PC) eller distribuerad transaction... •Självklart för uppdateringar mot en relationsdatabas men inte för applikationsintegration och SOA •Egentligen borde man alltid sträva mot tekniska transaktioner, men det ger för hård koppling, prestandaproblem, interoperabilitetstrassel mm mm Tjänst X t ex fakturering Tjänst Y t ex lagersaldo SOA-smörgåsbord av tjänster (Web Services) Anropare t ex ett köp  två uppdateringar

10 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 kompensations-verb

11 ”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

12 Tekniken sticker upp sitt fula tryne... Verksamhet Teknik När saker inte GÅR att göra obrytbart eller exakt samtidigt Verksamhetsmässigt orsakade långa verksamhetstransaktioner Tekniskt orsakade långa verksamhetstransaktioner Kräver Funktionalitet i verksamhetsstödet (kompensation etc) Kräver

13 Ta hand om larmet: 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) •Behövs ”compensation schemes”, dvs backnings- funktioner insystemerade i applikationerna! •Dessa initieras manuellt eller automatiskt •Håll ev ordning på dem med tekniskt workflow / orchestration, gärna baserat på BPEL etc

14 Processdefinitions-lagret detaljerat ”Ren datakom” HW Syntax- definition Semantik- definition Process- definition. Visio-filer eller BPEL etc Välj integrations- teknik Överenskommelser Kontrakt Workflow, orchestration, business process automation, choreography, arbetsflöden, ärendehantering etc – behandlas här som ungefär samma begrepp Business workflow Ta om hand verksamhetsmässigt orsakade långa verksamhetstransaktioner Business workflow Technical workflow Technical workflow Ta om hand tekniskt orsakade långa verksamhetstransaktioner

15 Balansplattan för säkerhetsoptimering Slutkundnytta/enkelhet Risk/skade- konsekvenser Verksamhetsnytta Lag/regel- krav Resurser /ledtid 100% säkerhet existerar inte, i all verksamhet handlar det om avvägning!

16 Säkerhet: Identifiering & rättigheter •(Eng. Authentication & Authorisation) •WS används vanligen server-till-server. Normalt: –Därmed ligger identifieringsansvaret utanför WS/SOA –Delegerad rättighetshantering – kontrakt •Ett anropat serverprogram får lov att lita på att anroparen känner till rätt identitet hos användare •Varje serverprogram måste dock hålla ordning på användares rättigheter (och roller) Användar- gränssnitt (inkl identifiering) Serverprogram A (inkl rättighetshant.) Serverprogram X (inkl rättighetshant.) Serverprogram Y (inkl rättighetshant.) c/s WS – SOA

17 Säkerhet: Insyn/intrång •Nya standarden WS-Security kanske slår igenom, men annars kan man säkra upp kommunikationen mellan applikationerna genom beprövade infrastrukturåtgärder: •SOAP/https •VPN-tunnel •Nätsegmentering med VLAN- teknik •Hyrd förbindelse eller helt egen sladd mellan maskiner •Ger dock ej end-to-end-skydd vid vidareförmedling Infrastruktur-skydd Server AServer B Server C Oskyddat!

18 WS och asynkront/kö •Enkla WS har ingen inbyggd kö, att då säga att man skickar ett meddelande med WS är ”halvsanning” – det man gör är ett synkront anrop! •Vid låga krav på stabilitet må ju detta duga, men... •I o f s rätt enkelt att lösa med programmering, då anropad part direkt lägger datat: –i kö-tabell i relations-databas –i kö-lösning som MQ, JMS, MSMQ, ebMS –i EAI-lösning som har inbyggd kö –etc •Framväxande kö-standard: WS-RX (dock ej persistent kö)

19 Web Services och avancerad integration •Observera att enkla Web Services (SOAP/http) såsom det är rimligt realiserbart idag/snart inte alls har samma kompletta scope som t ex EAI- eller ESB-produkter (eller SHS, myndighetsvärldens kommunikationsstandard) har, t ex vad gäller: –Asynkron hantering –Händelsestyrning –Routing –Konvertering –Affärslogik och processtyrning ”på vägen” –En-till-många, många-till-en –Tekniska transaktioner –mm •Däremot kan WS med fördel kombineras med EAI/ESB...

20 Hur ska man se på de nya ”komplexa” WS-standarderna? •Den stora fördelen med ”enkla” WS är just deras tekniska enkelhet! •WS-Transactions (tekniska transaktioner, 2PC) är mycket komplex •WS-Security verkar också komplex •WS-RX (kö) en kompromiss av två konkurrerande standardförsök •Risk för att interopera- biliteten blir dålig –Dels att få med alla på samma specar –Dels att få bugg- kompatibilitet! –Risk för detaljerat versionsberoende –Se hur det gick för XA- standarden eller CORBA... •Gå försiktigt fram, gör tekniska prototyper och interop-test

21 Övervakning, versionering, underhåll •Snabbhet, återanvändning och dynamik är mycket bra, men risk att WS resp SOA ger inter-application spaghetti! •WS innehåller i sig inget för driftövervakning, det måste tillföras •Använd t ex: –Anropad-utav (oblig. sidoparameter) –Applikations-ansvarig hos anropande (oblig. sidoparameter) –SOA-ping (för test, för driftövervakning, kan ge svar på versioner) –Skapa SOA-nav? Integration Broker? (Dock single-point-of-failure.) –Ha noga uttänkt strategi för versionering (både anrop och meddelanden – XML är faktiskt råddigt härvidlag)) –mm mm

22 Sammanfattning WS •Web Services är fantastiskt nyttiga för SOA i o m att de ger oss fungerande interoperabilitet – ”alla” leverantörer är med på tåget •Liksom med all lös koppling utan allt-eller-inget-uppdatering måste man ta hand om uppdateringsundantag, t ex med mönstret långa verksamhetstransaktioner •Tillför köhantering när så behövs •Var försiktig med framväxande komplexa standarder, testa mycket noga •Se upp med genererade Web Services så de blir interoperabla samt driftvänliga/underhållbara •Undvik WS för uppenbart “pratiga” client/server-protokoll

23 Sven-Håkan Olsson, CTO 0708 – Även kursledare 3-dagars DF-kurs SOA, WS, EAI Säkerhet Enkelhet Sänkta kostnader Enklare, säkrare och billigare inloggning baserat på telefoni Minskar kostnader för utskrift och porto Transacsations ledord