ark_uppsala_bistånd_v3.ppt Arkitektur för Bistånd Sven-Håkan Olsson, Definitivus AB. 1 Enstaka bild får användas med angivande av källa
ÖTP V2.0 s22 Generellt mönster i ÖTP Medborgare Företag Handläggare etc SOA Service Oriented Architecture Anpassningsskikt (med ev integrationslogik - adaptrar) E-tjänst Ny webbapplikation Existerande verksamhetsapplikation Handläggare etc Exempel på adapter Registerhållande myndighet etc e-leg / e-underskrkoll etc = E-tjänstens definierade informationskontrakt Nyttomeddelanden (anrop via Web Services) = Anpassnings-logik (ev) = Proprietära/specifika 2 anrop per verksamhetsapplikation/tjänst
Demo eansökan 3
Översiktsbild nuvarande eansökan Medborgare Företag Handläggare etc Svårt, för att komma framåt struntar vi i denna integration just nu E-tjänst söka Bistånd Ny webbapplikation Existerande verksamhetsapplikation Handläggare etc Existerande verksamhetsapplikation Registerhållande myndighet etc e-leg / e-underskrkoll etc Mjölkning av ansökningar plus manuell inmatning i första skedet ( +copy/paste)
Demo Multifråga 5
Översiktsbild Multifråga Intern E-tjänst Multifråga Ny webbapplikation Handläggare I detta fall kontrolleras i verksamhetsapplikation att det finns ett öppet ärende. Man får också in hushållets personnumer. Existerande verksamhetsapplikation Registerhållande myndighet etc
Webbläsare Multifråga Webbserver IWSI Lokal SHSnod Säker SHS-kommunikation över Internet med centrala myndigheter (eller möjl. via säkrade Web Services) SHS CSN FK AK DMZ AF Handläggare i socialtjänsten i kommunen SV SHS-kommunikation enligt s.k. IWSI mot internt kommundriftad SHSnod/agent/satellit. (SHS är en specifikation skapad av Statskontoret/Verva/Kammarkollegiet.) Ev. även via extern Infratjänste-leverantör för vidareskickning av SHS till mynd.
Black-boxansvar E-tjänstens black-box-ansvar Procapitas black-box-ansvar E-tjänst Ny webbapplikation Verksamhetsapplikation, t.ex. Procapita Myndighet t.ex CSN CSN:s black-box-ansvar Viktigt att definiera VEM som ansvarar för adapter. Alternativ: - Utvidga Procapita-black-box - Utvidga E-tjänst-black-box - Definiera en mellan-black-box som hanterar anpassningar 8
Några relevanta SOA-aspekter Black-box Inuti boxen har den box-ansvarige full makt över detaljutformning, programspråkval, databasval, intern begrepps/informationsmodell etc Extern användning av boxen ska endast göras via publicerade informationskontrakt (API-beskrivning, filbeskrivning, xml-schema, begreppsmodell, wsdl-fil etc) Informationskontrakten måste versionshanteras Black-boxes måste tillåtas använda olika teknikplattformar interoperabilitet I Sambruks ÖTP väljer vi företrädesvis Web Services inom kommunen och SHS externt mot andra parter Agreement is expensive, således: Försök se till att det bara är ett minimum av saker man måste vara överens om mellan black-boxes (OBS att ordet tjänst är synnerligen dimmigt definierat i IT-branschen jag tenderar att säga black-box eller SOA-domän istället) SOA Service Oriented Architecture, SHS Spridnings/HämtningsSystem 9
ÖTP V2.0 s26 Integration verksamhetsapplikation (3 exempel) E-tjänst Ny webbapplikation Mål: Samma definierade informationskontrakt (nyttomeddelanden) per e-tjänst, oberoende av verksamhetsapplikation = Ex. på olika alternativa verksamhetsapplikationer (vanligen endast en i taget per kommun): X Applikationen har redan infört Sambruksplf. exakta nyttomedd. via Web Service Applikationen har ett högnivå - API, t ex via COM eller RMI Y Anpassningslogiken måste bli olika omfattande (från ingenting till tjock ), beroende på resp. verksamhetsapplikations möjligheter Applikationen har inget API, tvingas gå direkt via SQL mot databasen Z = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). Bör vara på hög nivå ( verksamhetsobjekt ). = Proprietära/specifika anrop per verksamhetsapplikation/tjänst. Helst på hög nivå men kan 10 behöva vara på låg nivå (beroende på resp. verksamhetsapplikations möjligheter).
ÖTP V2.0 s32 Integrations-exempel centrala myndighetsregister WS E-tjänst Ny webbapplikation Potential för att benämna detta skikt för gateway SHS Registerhållande myndighet 1 Registerhållande myndighet 2 Detta maskingränssnitt är troligen på ren tekniknivå, t.ex. SHSSendSync Detta maskingränssnitt bör ha verksam-hetshöjd dvs beskriva en funktionell sak, t.ex. HamtaStudieFormaner 11
Integrations-exempel centrala myndighetsregister E-tjänst Ny webbapplikation Ifall det är lämpligt relativt funktionella krav kan man ibland göra ett anrop som sedan i gateway:en utförs genom flera underliggande anrop. T.ex. HamtaSocFormaner Kallas i SOA-världen Composite Service WS En sådan gateway har ytterligare potential SHS Registerhållande myndighet FK SHS Registerhållande myndighet CSN OBS S.k. icke-funktionella aspekter kan göra att sådana synkrona composite services inte är lämpliga: T.ex. risk för dålig svarstid hos någon myndighet, dålig uptime etc. Antingen får man göra som på förra sidan eller utforma ett asynkront 12 gränssnitt. Troligt fall för Bistånd?
ÖTP V2.0 s28 Problemet med inlåsta verksamhetsapplikationer där leverantören vägrar leverera rimliga maskingränssnitt: Mönstret läs online, skriv till fil E-tjänst Ny webbapplikation Skrivningar via mellan-fil Import-. funktion Verksamhetsapplikaition helt utan API:er Å Läsningar online via SQL mot databasen = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). Bör vara på hög nivå ( verksamhetsobjekt ). = Proprietära/specifika maskingränssnitt 13
Vad är SHS? En specifikation, de facto-standard, för offentligsektorns informationsutväxling, se www.openshs.se Tillkom före SOAP-standarden för Web Services. Protokollet mellan SHSnoder kan kallas http/pox vilket åter blivit en relativt populär variant, parallellt med REST, istället för tunga SOAP. Inom Landstingen har RIV-TA liknande ställning som SHS. Stort fokus på säkerhet, kryptering, att en mottagare bergsäkert vet vem som är sändare (PKI/organisationscertifikat) Stor tydlighet kring när ett meddelande inkommit till en myndighet (ankomststämpling, offentlig handling...) genom loggar. SHS synkront ( nu-kommunikation ) Kan sägas motsvara vanliga Web Services enligt SOAP, men kompletterade med ett stort regelverk/policies kring användningen skulle man använda vanliga Web Services för extern kommunikation måste man tillföra tydliga sådana dokument i informationskontraktet. SHS asynkront ( strax-kommunikation ) Finns ingen praktisk motsvarighet i Web Services (standarden WS-RM har inte slagit igenom). Man får istället kombinera Web Services med en kö (t ex MSMQ) eller använda RSS/Atom etc. SHS Spridnings/HämtningsSystem, POX Plain Old XML 14
SHS översiktlig arkitektur Ev. adapter, funktionell gateway Sändande applikation C-API IWSI SHSnod https/pox FW Säkrad SHSkommunikation Mottagande applikation Mottagande SHSnod Kan t ex använda antingen C-API eller IWSI (Web Service) Internet Kommun X SHS-noderna SHS-noden kan kallas tekniska gateway gateways T.ex. CSN 15
Informationskontrakt Nyttomeddelanden Ex XML Anrop/överföring SBAXyz etc SBAHamtaElevData SOAP WSDL (eller batchfil etc) SBAXyz.wsdl etc Nyttomeddelanden SBNXyz (Element) SBNHamtaElevDataBegar XML-schema SBNXyz.xsd Sambruks Nyttomeddelanden utgör en återanvändningsstruktur för olika sorters XML-element Ska vara oberoende av teknisk transport. Baseras på dåvarande E-nämndens riktlinjer 05:01 för Standardmeddelanden För schema- och wsdl-exempel, se t.ex. Nyttomedd_arendehandelse_v05.pdf Paket SBPXyz (Element) Grupper SBGXyz Element Typer SBTXyz SBPMedborgare SBGPersTel (Ex på element: Mobiltelefon) SBTTelefonnummer XML-scheman (som inkluderas i ovanst.) SBPXyz.xsd (ingen motsv, end. spec-begrepp) XML-typer Sambruk ÖTP V2.0 s83 16
Designprinciper för adapters Ofta ska adaptern ligga mellan interoperabelt och proprietärt gränssnitt då vanligen lämpligast att utveckla adaptern i sig i den proprietära tekniken. Ex: Är ett proprietärt gränssnitt i Java-RMI bör adaptern utvecklas i Java. Ägarskapet/ansvaret för adaptern vara väldefinierat. Vilken black-box hör den till? Helst ska förvaltningsansvaret för adapter läggas hos den part som äger den proprietära delen eftersom denna kan tänkas komma i ny inkompatibel version och adaptern också måste komma i ny version då. Ex: Helst bör en Procapita-adapter förvaltas av Procapita-leverantören. Ibland dock ej möjligt. Adaptrar bör utformas för att inte öka på driftskomplexitet Ex: Se om det går att undvika: Relationsdatabas, speciella applikationsserverar, integrationsmotor/enterprise Service Bus som inte egentligen tillför så mycket, etc Adaptern kan dock bli single-point-of-failure varför man kan behöva fault-tolerance-lösning (välj dock en ENKEL sådan, helst på http-nivå, inte på proprietär-api-nivån). Flera versioner av en adapter bör gå att drifta parallellt så att inte allt måste bytas ut på exakt samma tidpunkt Adaptrar som ska betjäna publik webbsajt kan behöva ha lastbegränsning så att inte en bakomliggande applikation/tjänst blir överbelastad (s.k. throttling ) Adaptrar bör ha mycket väl utbyggd undantagshantering och loggning så att fel kan hittas. Att fördela felansvar mellan black-boxes är ibland ett problem i SOA-sammanhang! Skicka med extraparametrar i xml:en för att underlätta felletning mm Varje adapter bör kunna svara på ett dummyanrop för driftövervakning ( SOA-ping ) samt svara med intern mjukvaruversion det händer ofta att det är fel version man kör emot... De flesta av dessa designprinciper kan återfinnas i ÖTP... 17
Trendspaningar, artiklar, sajter Sambruk (en medlemsförening för kommuner som har idag ca 80 kommunmedlemmar över hela Sverige och av olika storlekar) har en sajt, www.sambruk.se där arkitekturdokument såsom ÖTP (Öppen Teknisk Plattform), Nyttomeddelanden och Begreppsmodeller kan hittas. Kolla gärna in www.trendspaning.se där jag ofta deltar som skribent kring tekniktrender etc På min enkla sajt www.definitivus.se finns också ett artikelarkiv på undersidan för trendspaning som successivt fylls på 18
Sven-Håkan Olsson Styrelsemöte.se / Definitivus AB 0708 84 01 34 sven-hakan.olsson[hos]definitivus.se www.definitivus.se 19