presentation - definitivus.se

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
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
ÖTP V2.0 s22
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
Existerande
verksamhetsapplikation
Ny webbapplikation
Existerande
verksamhetsapplikation
Handläggare etc
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
Handläggare
Intern ”E-tjänst” Multifråga
I detta fall kontrolleras i
verksamhetsapplikation
att det finns ett öppet
ärende.
Man får också in
hushållets personnumer
.
Ny webbapplikation
Existerande
verksamhetsapplikation
Registerhållande
myndighet etc
Säker SHS-kommunikation över Internet med
centrala myndigheter (eller möjl. via säkrade
Web Services)
IWSI
Multifråga
Webbläsare
Webbserver
Lokal
SHSnod
CSN
SHS
FK
AK
DMZ
Handläggare i
socialtjänsten
i kommunen
SHS-kommunikation enligt s.k. IWSI mot internt kommundriftad SHSnod/agent/satellit.
(SHS är en specifikation skapad av Statskontoret/Verva/Kammarkollegiet.)
AF
SV
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
8
som hanterar anpassningar
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
Integration
verksamhetsapplikation
(3 exempel)
Ex. på olika alternativa verksamhetsapplikationer (vanligen endast en i
taget per kommun):
Mål: Samma definierade
informationskontrakt
(nyttomeddelanden) per e-tjänst,
oberoende av
verksamhetsapplikation
=
E-tjänst
Ny webbapplikation
ÖTP V2.0 s26
Anpassningslogiken måste bli
olika omfattande (från ingenting
till ”tjock”), beroende på resp.
verksamhetsapplikations
möjligheter
= E-tjänstens definierade
Nyttomeddelanden (anrop
via Web Services). Bör vara på
hög nivå (”verksamhetsobjekt”).
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
Applikationen har
inget API,
tvingas gå
direkt via SQL
mot databasen
Z
= 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).
Integrations-exempel
centrala myndighetsregister
E-tjänst
Ny webbapplikation
Potential för
att benämna
detta skikt för
gateway
WS
ÖTP V2.0 s32
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
En sådan
gateway har
ytterligare
potential
WS
SHS
Registerhållande
myndighet FK
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
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?
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
ÖTP V2.0 s28
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
Kan t ex använda
antingen C-API eller
IWSI (Web Service)
FW
https/POX
Säkrad SHSkommunikation
Mottagande
SHSnod
Mottagande
applikation
Internet
Kommun X
T.ex. CSN
SHS-noderna
kan
SHS-noden kan
kallas ”tekniska
kallas
”teknisk
gateways”
gateway”
15
Informationskontrakt
Nyttomeddelanden
Anrop/överföring
SBAXyz etc
Nyttomeddelanden
SBNXyz
(Element)
Ex
XML
SBAHamtaElevData
SOAP – WSDL
(eller batchfil etc)
SBAXyz.wsdl etc
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”
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
För schema- och wsdl-exempel, se t.ex.
Nyttomedd_arendehandelse_v05.pdf
16
Sambruk ÖTP V2.0 s83
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.
–
•
•
Ä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: 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.
–
–
–
•
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: Är ett proprietärt gränssnitt i Java-RMI bör adaptern utvecklas i Java.
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