Agenda –  SOA och SOAP e* prak/skt exempel Ekonomiskt Bistånd –  Erfarenheter och lärdomar
SOA Länkar /ll sidor om SOA h*p://en.wikipedia.org/wiki/Service-­‐oriented_architecture Vad är SOA ? Det är e* arkitekturtänkande som bygger på följande principer när det gäller utveckling av IT komponenter (mer om dessa principer i nästa föreläsning) •  Standardized Service Contracts •  Service Loose Coupling •  Service Abstrac7on •  Service Reusability •  Service Autonomy •  Service Statelessness •  Service Discoverability •  Service Composability •  Service-­‐Orienta7on and Interoperability SOA •  Innebär lösa kopplingar mellan olika applika/oner och stödjande infrastruktur genom a*: –  bindningen sker i samband med run/me –  informa/onsutbytet sker med hjälp av meddelanden –  det innebär bland annat a* det blir möjligt a* utbyta tjänster via Internet (Web services) –  OBS ! Web Services är en variant as SOA Web services h*p://www.w3schools.com/webservices/ws_intro.asp •  Exempel på Web-­‐services –  SOAP som avser e* protokoll för utbyte av informa/on i decentraliserade och distribuerade miljöer. SOAP är XML-­‐baserat –  Det kan användas /llsammans med flera överförings/transportprotokoll, men vanligast är a* det används /llsammans med HTTP. –  WSDL -­‐ Web Service Defini/on Language -­‐ e* språk som används för a* beskriva vilka tjänster som erbjuds. Med hjälp av WSDL specificeras åtkomst /ll olika Web Services. Stödjer publicering, uppdatering samt upptäckt. –  OBS! SOAP är inte lika med Webservices, det finns olika protokoll som kan användas: • 
• 
REST SHS Informa/onsinfrastruktur e-­‐infrastruktur (Informa/on infrastructure) enligt Hanseth och Lyy/nen, 2004 Horisontell indelning Verksamhetssystem på kommuner Applika7onsinfrastruktur Register hos myndigheter AnvändargränssniB Mul7fråga Understödj. infrastruktur Data-­‐transport infrastruktur SOAP SOAP Servicesinfrastruktur SOAP WSDL Schema Cerifikat HTTP HTTP HTTP Understödjande infrastrukturen (support infrastructure) består av: -­‐  Serviceinfrastruktur (Iden/fiering och säkerhetsfunk/oner) -­‐ -­‐Data-­‐transpor/nfrastruktur SOAP 1.  SOAP erbjuder således möjligheter a* skicka XML-­‐dokument mellan olika system och därmed erbjuder det möjligt a* kommunicera den informa/on som är nödvändig för a* systemen skall förstå hur XML-­‐dokumenten skall tolkas. 2.  Utny*ja den möjligheten!!!! Det sker inte automa/sk och kräver god informa/onsdesign samt bra skriven XML och dokumenta/on 3.  OBS!! Punkt 2 är en stor brist idag i samband med utveckling av informa/onsinfrastrukturer. De*a gör a* man inte får e* meningsfullt och effek/vt informa/onsutbyte på applika/onsnivå EB SOAP meddelande är alltså eB XML dokument och innehåller följande element: Sökande Ekonomiskt Bistånd (Hushåll) e-­‐infratruktur Ekonomiskt Bistånd e-­‐Ansökan Användar-­‐ STSA Gränssni* Verksamhetssystem Lefi Social Försäkring 1 STSS XML Fråga Register Ekonomiskt Bistånd Kommun-­‐ fråga Verksamhetssystem Studie-­‐ stöd SSBTEK Verksamhetssystem Användar-­‐ Gränssni* XML Svar STSM Mul/fråga Elsie 2 Verksamhetssystem Afli System-­‐/ll-­‐Systemgräns = Öppen System-­‐/ll-­‐Systemtjänst = Öppen Samverkanstjänst = Organisatoriskt Informa/onssystem = Beska*ning Folkbokföring Arbets-­‐ förmedling Verksamhetssystem UBS Arbetslöshets-­‐ kassa Handläggare på Myndigheterna Handläggare på kommunen Användargränssni* Ansökan Socialtjänstesystem Fråga ställd från användare av Mul/fråga 1 Mul/fråga Användargränssni* 1 Mul/fråga STSM Soap envelope 1 Register på myndighet 1 body fråga hamtaBastjanstInforma/on Soap envelope 1 SSBTEK Svar från registerhållande myndigheter 2 Mul/fråga Användargränssni* 2 Register på myndighet 2 SSBTEK Soap envelope 2 body svar hamtaBastjanstInforma/onResponse Soap envelope 2 Mul/fråga STSM WSDL SSBTEK Typ och elementdefini/oner WSDL SSBTEK Fråga Svar Felmeddelande Vilka opera/oner tjänsten kan ugöra och vilka in och utmeddelanden den kan ta emot
Bindning mot anrop och nätverksprotokoll i de*a fall SOAP och HTTP Beskriver hur man kan hi*a och addressera tjänsten h*ps://fmansinfo.forsakringskassan.se:443/ws/FK.EIF.SSBTEK De*a finns beskrivet i den tekniska beskrivningen SSBTEK Utdrag ur Schema Fråga Svar Felmeddelande Programmeringssteg För varje person gör följande 1. 
2. 
3. 
4. 
5. 
Skapa XML-­‐fråga genom a* läsa in informa/on från frågebild Gör SOAP-­‐Anrop /ll SSBTEK via användning av HTTP Invänta SSBTEK-­‐svar och spara temporärt på fil Packa upp SSBTEK-­‐svar som läggs på temporära bibliotek för a* kunna översä*as och presenteras /ll användaren Översä* från XML /ll användargränssni*et i de*a fall görs de*a med XSL 1) Skapa SSBTEK Fråge-­‐XML och lägg in informa7on i XML-­‐filen som användaren knappat in. OBS ! DeBa görs i Visual Basic och med ren stränghantering. 1) Frågebild i Mul7fråga som används som underlag för aB skapa Fråge-­‐fil som skickas 7ll SSBTEK Output steg 1: Fråge-­‐fil som kan skickas 7ll SSBTEK 2) Gör anrop 7ll SSBTEK OBS! EB anrop görs för varje person 2.1) Anrop görs 7ll en metod ”oWSReq.WS_Call” som skall uböra anropet 7ll SSBTEK 2.2) I ”oWSReq.WS_Call” används klassen HBpWebrequest för aB förbereda och anropa SSBTEK med hjälp av HTTP. Klassen kräver en URL och eB request-­‐objekt. URL 7ll SSBTEK finns sedan 7digare i sWSUrl 2.3) I request-­‐objektet måste man ange: HTTP-­‐Metod, user-­‐agent, vad det är för typ av anrop samt cer7fikat. 2.4) Nu är URL och requestobjektet klart, nu måste det skapas en stream som skickar i väg fråge-­‐XML som en byte-­‐sträng med räB encoding-­‐format. Fråge-­‐XML (se 7digare bild) finns sedan 7digare i oNyBomedd. Fråge-­‐XML anges som parameter här 2.5) Nu skickas frågan, anropet 7ll SSBTEK ubörs 3) Vänta på svar och ta hand om det 3.1) Nu måste man skapa den stream i vilken som svaret från SSBTEK ska komma. DeBa läggs in i sSvar 3.2) SSBTEK-­‐Svar har kommit, svaret finns i sSvar som förs över 7ll sResp som skrivs ut 7ll en temporär fil (se nästa bild) Output Steg 3 SSBTEK SVAR-­‐XML Olika format vilket är e* problem 4) Packa upp XML Genom aB SSBTEK-­‐svaret innehåller XML som skickas i olika format: AK, AF och FK enligt ”texbormat” eller CSN ”Byte-­‐format Base64” eller SV enligt ”escape-­‐format” måste SSBTEK-­‐svaret packas upp så aB blir möjligt aB översäBa med hjälp av XSL. 4.1) XML packas upp från SSBTEK-­‐Svar med hjälp av olika klasser 4.2) CSN-­‐ XML packas upp från SSBTEK-­‐Svar i klassen PackaUppCSN 4.3) Uppackad CSN-­‐ XML skrivs ut på fil för aB kunna översäBas (se nästa bild) Exempel på Output steg 4 CSN-­‐Svar Uppackad klar aB översäBas 5) ÖversäBning från XML 7ll användargränssniB med hjälp av XSL Output från steg 5 så här visas det för användaren Det finns även andra sä* a* anropa och överföra informa/on mellan olika applika/oner över Internet SHS Version 1.2.01(2007) Architecture, Verva -­‐ Swedish Administra/ve Development Agency •  SHS (Spridnings-­‐ och Hämtningssystem) är e* koncept för säkert och pålitligt utbyte av informa/on mellan offentliga organisa/oner. Informa/onsutbytet är standardiserat vilket innebär a* samma teknik används vare sig mo*agaren är e* internt verksamhetssystem eller en annan myndighet. –  Protokoll -­‐ SHS-­‐meddelanden skickas mellan olika noder enligt e* standardiserat protokoll. Det är framförallt XML som används (Jämför med SOA) –  Aktör -­‐ Ägaren av en SHS-­‐nod kallas för aktör och meddelanden skickas all/d mellan aktörer/noder. –  Produk*yp -­‐ Alla meddelanden är uppmärkta med en produk*yp som definierar innehållet i meddelandet. (Jämför Schema) –  Katalogtjänst -­‐ Genom en gemensam katalogtjänst publicerar de olika SHS-­‐aktörerna informa/on. (Jämför med WSDL) Informa/onsinfrastruktur e-­‐infrastruktur (Informa/on infrastructure) enligt Hanseth och Lyy/nen, 2004 Horisontell indelning Applika7onsinfrastruktur Verksamhetssystem på kommuner Register hos myndigheter AnvändargränssniB Mul7fråga Understödj. infrastruktur SHS Servicesinfrastruktur SHS SHS Produkt Katalogtjänst Cerifikat Data-­‐transport infrastruktur HTTP HTTP HTTP Understödjande infrastrukturen (support infrastructure) består av: -­‐  Serviceinfrastruktur (Iden/fiering och säkerhetsfunk/oner) -­‐ -­‐Data-­‐transpor/nfrastruktur Vilket ska man välja? •  Web services (SOA,REST) –  Enklare a* installera tekniskt –  Enklare genom a* fler kan de*a •  SHS –  Ger mer funk/onalitet •  Asynkron –  Säkrare Slutsatser Teknisk kompetens •  Det krävs kunskap om vilken typ av Web-­‐services som man bör använda –  Mer om SOAP och REST i nästa föreläsning •  Det är inte så enkelt som man tror, det krävs god teknisk kompetens för a* åstadkomma e* informa/onsutbyte •  Man måste lära sig a* läsa servicespecifika/oner och scheman •  En del av den programmering som beskrivits som handlar om a* skapa och ändra I XML-­‐filer, kan underlä*as med hjälp av LINQ (LINQ i kombina/on med XML är mycket nyngt verktyg) Slutsatser Kompetens med avseende på verksamhet, informa7onsmodellering och design av XML. DeBa handlar om aB: •  Kunna beskriva informa/onsstrukturer och översä*a dem /ll en lämplig hierakisk datastruktur •  Kunna förstå verksamheten och verksamhetsspråket för a* kunna presentera informa/onen på e* bra sä* för användaren •  Lär er a* dokumentera informa/on på e* transparent sä* •  De*a ska vi diskutera ugörligare senare under kursen Slutsatser •  E* dåligt designat informa/onsutbyte både när det gäller teknik och verksamhet leder /ll mycket onödigt extraarbete, onödiga kostnader samt risken för a* informa/onen ska misstolkas, de*a drabbar både programmerare, användare och de som ska betala för de*a. •  Beslutsfa*are och många andra aktörer förstår inte skillnaden mellan tradi/onella inomorganisatoriska verksamhetssystem och informa/onsinfrastrukturer som är inter-­‐organisatoriska och som bygger på SOA-­‐arkitekturer •  Det krävs mycket kunskapsutveckling inom de*a område