Transcript SHS version 2.0 Håkan Svenson, CTO Vad är SHS? • Toppledarforum 1996 ”Gemensamma ITplattformar för informationsutbyte” – SHS = Spridnings och HämtningsSystem” • Några år.

SHS version 2.0
Håkan Svenson, CTO
Vad är SHS?
• Toppledarforum 1996 ”Gemensamma ITplattformar för informationsutbyte”
– SHS = Spridnings och HämtningsSystem”
• Några år senare ”återfann” man begreppet då
RFV, RSV och Statskontoret specificerade och
upphandlade en ”produkt” för säker
kommunikation
• Det är en teknisk specifikation och har också
blivit ett begrepp
Bakgrund
• SHS tuffar på i det tysta, säkert och med stora
volymer
• Men det har länge funnits ett behov och ett tryck
att modernisera konceptet
• SHS NG har länge varit i vardande
–
–
–
–
European eLink
FGS Verva projekt SHS 2.0
Samarbete med vården på G med RIV 1.0…
… men det blev verklighet kring RIVTA 2.0
• Det har hänt en del sedan 1998. Det fanns saker
som behövde moderniseras
Bakgrund
• Försäkringskassan har tagit över ansvaret för
SHS-specifikationen från Kammarkollegiet 2010
• Ett SHS-råd med myndigheter och leverantörer
har bildats och träffats ett par gånger per år
• En hopsamling och uppstädning av
specifikationen kallad ”SHS 1.3”
• Arbetat med SHS version 2.0
• Under våren 2013 fastslog man version 2.0 av
SHS
Utgångspunkter
• Samarbeta/samordna med liknande arbeten
inom vården (Inera) dvs RIVTA 2.0
• Stärk SHS där det behövs, behåll det som är
bra
• Undvika stora ingrepp i såväl specifikation som
implementeringar
• Ta ett steg i taget
SHS starka och svaga sidor
• Styrkor
– Känd säkerhet
– Filöverföring, speciellt stora filer
– Ostrukturerat innehåll
– Asynkron hantering
• Svagheter
– Direktåtkomst/synkron hantering
– Strukturerat innehåll
SHS-stacken från version 2.0
Katalog
”Classic”
Web Service
(från RIVTA)
Syncengine
Asyncengine
Gemensamt SHS
(produkttyp, avsändare,
mottagare, katalog, adressering,
spårbarhet…)
SHS version 2.0
•
•
•
•
Tillägg till specifikationen (SOAP-based protocol)
Baserat på Inera’s RIVTA 2.0 (och i någon mån SSEK)
Som är baserat på WS-I Basic Profile 1.1
Som är:
– The WS-I Basic Profile (official abbreviation is BP), a
specification from the Web Services Interoperability
industry consortium (WS-I), provides interoperability
guidance for core Web Services specifications such as
SOAP, WSDL, and UDDI. (Wikipedia)
• Samt hantering av bilagor enligt XOP/MTOM
• Mappning till SHS-koncepten
• Samt allt från ”Classic” SHS
Användningsscenarie 1 Infrastruktur
• Stor aktör kommunicerar med en annan stor aktör via sina
SHS-noder
– Inblandade verksamhetssystem kommunicerar alltid via
noderna
– Soap:Header med Adressinformation, korrelationsid mm
– Typ direktåtkomst mellan myndigheter
– Klassiskt SHS scenario
• Bilateralt (eller många till en) med routing
Application A
SHS A
SOAP with shs.label
SHS B
Backbone
communication.
SOAP with
shs.label
Application B
Synchronous
plugins
Användningsscenarie 2 Liten aktör
• Liten aktör kommunicerar med stor aktörs SHS-nod
– Det är ett verksamhetssystem knutet till noden som tar
emot eller besvarar
– Man vill använda renodlad Web Service, d.v.s. utan
soap:Header
– Typ FK Tanden
• Bilateralt eller många till en, utan routing
Application A
SOAP without shs.label
SHS A
Application B
Synchronous
plugins
Saknad shs.label = ”implicit addressing”
Tjänsteinteraktionstyper
• Fråga-svar (requset-response)
– Alltid ett helt igenom synkront anrop beskrivet i ett tjänstekontrakt
• Informationsspridning (oneway)
– I grunden ett synkront anrop beskrivet i ett tjänstekontrakt. Svaret har ingen semantisk
betydelse utöver ok eller fel.
– Hanteras SHS-mässigt synkront. Genom lokal konfiguration (regel) i den nod som servar
anropet kan man välja om ev. fortsatt bearbetningen skall vara synkron eller asynkron
men det är utanför specifikationen
• Uppdrag-resultat (request-reply)
– Två från varandra fristående synkrona anrop, oftast av typen Informationsspridning
– Hanteras SHS-mässigt synkront. Genom lokal konfiguration (regel) i den nod som servar
uppdrag eller resultat-anropet kan man välja om ev. fortsatt bearbetningen skall vara
synkron eller asynkron men det är utanför specifikationen
– De inblandade noderna behöver inte ha någon kunskap om att en relation finns mellan
uppdraget och resultatet. En stark rekommendation är dock att av spårbarhetsskäl
relatera dessa med varandra genom samma värde på korrelationsid
• Allt är i grunden synkront (Web Service är i grunden synkront)
Produkttyper och adressering
• SHS-label
– Kan utelämnas. Det tolkas som till den lokala noden
– Avsändare. Kontrolleras mot certifikat (funktion från SSEK)
alternativt skapas från certifikat
– Mottagare
– Produkttyp (skapas av 1’a nod)
– TxId (skapas av 1’a nod)
– CorrId (optionellt)
• Fysisk Adressering
– Sker via katalogen pss som tidigare, dvs en ändpunkt slås
upp i adressobjektens attribut ”shsDelieveryMethods”
med mottagare och produkttyp som nyckel
Hur bestäms produkttyp?
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tan="http://fk.se/SHS/xsd/tanden">
<soapenv:Body>
<tan:FK.TV.TestRoundTripRequest
organization-number="1234567898"
request-id="a4924e42-4214-ba93-0014-98739237ba27"
shs-invoked-interface="Submit Claim v2"
vendor-name="Klinik X"
product-name="Undersökning Y"
version-number="1"
Root-element och/eller rootuser-id="197701011234">
elementets namespace slås upp i en
regeltabell som ger produkttyp.
<tan:clinic-id>33312341</tan:clinic-id>
</tan:FK.TV.TestRoundTripRequest>
</soapenv:Body>
</soapenv:Envelope>
Felhantering
• Den totala bilden är ganska komplex
– Två skikt är inblandade, SHS och applikation. Behoven i dessa är olika
och vi vill inte heller att de ska blanda sig i varandras göranden
– I applikationerna används olika verktyg och programvaror som har sina
olika egenheter i t.ex. hur exceptions hanteras i genererad kod
– Vi har två olika scenarier med olika målgrupp av utvecklare
•
Vi vill ha :
1.
2.
3.
4.
•
Bra felhantering inom SHS
Möjlighet till bra felhantering appl till appl
Möjlighet till bra mappningar av fel till exceptions i olika verktyg
Att i största möjliga mån slippa se något av SHS-skiktet vid
utveckling av tjänster i applikationer
Man kanske inte alltid kan få allt utan måste kompromissa
Att se eller inte se SHS
Application A
SHS A
SOAP without shs.label
Application A
Application B
Synchronous
plugins
SHS A
SOAP with shs.label
SHS B
Backbone
communication.
SOAP with
shs.label
I det här enkla scenariot vill vi helst
inte se något alls av SHS i
tjänstekontrakten. Varken header eller
faultMessages.
Risken för SHS-relaterade fel är även
ganska liten
Application B
Synchronous
plugins
I det mer komplexa scenariot måste vi
hantera ett schema för SHS
headerelement i tjänstebeskrivningen.
Då är det ingen stor sak att även
hantera ett extra faultMessage för SHS
Att komponera tjänstekontrakt
(mycket översiktligt)
WSDL
SHS header elements
schema
MyServiceRequest
schema
MyServiceRequestMessage
MyServiceResponseMessage
MyServiceFaultMessage
SHSServiceFaultMessage
MyServiceResponse
schema
MyServiceFault
schema
SHSServiceFault
schema
Felhantering
• Interna fel inom SHS hanteras med en fördefinierad
faultData-struktur som innehåller relevanta uppgifter om
felet
• Specifikationen innehåller ett schema för faultData
• Felhantering mellan applikationer end-to-end är öppet för
tjänsteutvecklarna att själva bestämma
– Använda soapFault eller…
– …använda andra (egna) mekanismer för felhantering
• Felhantering mellan applikationer är inte svart eller vitt
utan ett ganska så grått område. Det finns goda skäl att i
olika fall hantera det på olika sätt
• SHS version 2.0 tillåter olika felhanteringsstrategier i
applikationsutvecklingen
17
Smått och gott
• Skillnader mot RIVTA minimala
– Interoperabilitet mellan statliga myndigheter,
kommuner och landsting inom räckhåll
– Samarbetsgrupp SHS-RIVTA diskuteras
• Promotas av e-delegationen och passar in i EU’s
arkitektur-ramverk (EIF)
• Från RIVTA har SHS ärvt en handboksdel med
riktlinjer om hur man konstruerar scheman mm
för tjänster
– FK kommer att ta fram en exempeltjänst inklusive en
guide för utvecklare av tjänster
SHS version 2 till iipax 5.3
• Som ny protokollmodul
• Stöd för SHS 2.0 standarden
• Samt
– Produkttypsmappning från url (finns i spec WSGW
men inte SHS 2.0)
– Standardplugin för vidareanrop Web Service
– Standardplugin för lokal lagring (asynkron
överföring)
– Protokollbryggningar