JHS 179 Planering och utveckling av en övergripande arkitektur Bilaga 8. Beskrivning av integration och gränssnitt

JHS 179 Planering och utveckling av en övergripande arkitektur Bilaga 8. Beskrivning av integration och gränssnitt Version: 2.0 Publicerad: 7.2.2017 Giltighetstid: tills vidare Innehåll 1Inledning...2 2Analys av integrationshelheten...5 3Komplettering av verksamhetsarkitekturen ur integrationernas perspektiv...6 3.1Funktionella tjänster...6 3.2Interaktion mellan aktörer...7 3.3Interaktion mellan processer...7 4Planering av informations- och informationssystemarkitektur ur integrationssynvinkel...8 4.1Logiska datamodeller och tillämpningsprofiler...8 4.2Interaktion mellan informationssystem...9 4.3Beskrivning av gränssnitt...11 4.3.1Exempel på användning av ESB-tjänst (VIA)...16 5Teknikarkitekturen ur integrationsperspektiv...18 5.1Datakommunikationsarkitekturen som en del av IT-infrastrukturen...18 5.2Datakommunikationsarkitekturen ur nätverkets perspektiv (nerifrån och upp)...19 5.3Datakommunikationsnäts anslutningsgränsytor (RP=ReferensPunkt)...20 5.4Datakommunikationsarkitekturens nätverksbeskrivningar...20 5.5Datakommunikationsarkitekturen ur applikationsmodellerarens perspektiv (uppifrån och ner)...22 6Nationella servicearkitekturen ur ett integrationsperspektiv...25 1/27

1 Inledning Denna bilaga kompletterar JHS 179 -rekommendationen genom att ge anvisningar för planering och beskrivning av integrationsarkitekturen som ingår i den övergripande arkitekturen. Strukturer i anslutning till olika slags kopplingar och sammanläggningar, det vill säga integrationer, utgör en del av den övergripande arkitekturen och grunden för interoperabilitet. Anvisningarna för integrationsplanering gäller alla aspekter av den övergripande arkitekturen och går från verksamhetsarkitekturen mot mera detaljering på teknikarkitekturens fysiska nivå. I granskningen har också lösningsarkitektur inkluderats, eftersom de tekniska kraven för interoperabilitet påverkar just den. En organisation kan använda anvisningarna till den detaljeringsnivå som motsvarar dess krav. Kraven på integrationsarkitekturen härleds ur verksamhetens behov av informationsutbyte. Integrationer kan beskrivas ur många arkitekturaspekter och på många detaljeringsnivåer. Den centrala målsättningen är att säkerställa interoperabiliteten enligt EU:s EIF-ramverk1 (The European Interoperability Framework). Integrations- och gränssnittsbeskrivningar upprättas som preciseringar av den övergripande arkitekturen t.ex. genom beskrivningar av gränssnitt och datakommunikationsarkitektur. Integrationsplaneringen börjar med att identifiera tjänsternas och tjänstehelheternas integrationsbehov, genom att utnyttja den övergripande arkitektur som utarbetats för det objekt som ska utvecklas samt identifiera och analysera de för integrationen viktiga punkterna i målarkitekturen, som: målsättningar, tjänster och tjänstemodell med hjälp av verksamhetsmodellen allmänna målsättningar och randvillkor för integrationsarkitekturen riktlinjer och krav gällande integrationer och som ges av arkitektur- och datasäkerhetsprinciperna (enligt JHS 179-rekommendationen) organisering och ansvarsfördelning för integrationsfunktioner utvecklingskarta för integration beroenden av andra aktörer och intressentgrupper krav gällande integration, som prestanda och datasäkerhet beskrivning av datamodellen det vill säga dokumentation av det datainnehåll som hanteras i integrationen strategiska teknikval, t.ex. XML, JSON, REST. När olika informationssystem integreras sinsemellan ska skyddsnivåklassificeringen för systemen och de uppgifter som hanteras i dem beaktas. Information på högre skyddsnivå får inte flyttas till ett system på lägre skyddsnivå. Uppgifter, även om de kräver samma skydd, ska kunna hållas separerade. Detta betonas särskilt när information som kräver högre skyddsnivå hanteras, då ska de kunna hållas även fysiskt separerade från varandra. Ytterligare information finns i VAHTI-anvisningarna2. Dataöverföringen ska ske med det skydd som klassificeringarna förutsätter och med ett överföringssystem som uppfyller skyddet. Skyddsnivån för den överförda informationen måste föras över till den mottagande parten, liksom även annan metadata som är nödvändig för användningen och verksamheten. Vid överföring av information mellan system på olika datasäkerhetsnivå, ska man beakta förbindelselösningarna och säkerställa att endast den information överförs som det är tillåtet att överföra. 1 http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf Se t.ex. VAHTI 3/2012, https://www.vahtiohje.fi/web/guest/keskeiset-vaatimukset-ict-ympariston-tietoturvallisuudentoteuttamiseksi 2 2/27

Nödvändigt skydd i informationsöverföring mellan informationssystem hanteras genom kryptering eller andra metoder, meddelandestrukturen ska ej förändras, jmf. suomi.fi-servicekanalen. Organisationens ledning, planerare av tjänster och verksamhet, programmerare samt datasäkerhetsspecialister och -arkitekter behöver alla beskrivningar som lämpar sig för deras perspektiv. Samma objekt granskas i dessa beskrivningar ur olika utgångspunkter och behov. Typiskt gäller beskrivningar avsedda för ledning och specialister på kärnverksamhet helheten, tjänster, processer och informationsflöden. Beskrivningar avsedda för leverantörer, programmerare och ansvariga för teknisk datasäkerhet är i allmänhet teknikorienterade och mera detaljerade. Dessutom är det typiskt för arkitekturstyrning i agil utveckling att beskrivningarna görs först på hög nivå och detaljerna preciseras i samband med implementeringen. Hanteringen av integrationernas livscykel, versioner och underhåll ska beaktas redan när integrationsplaneringen påbörjas för att bl.a. kostnaderna ska kunna hållas under kontroll. Det är bra att förutse förändringssituationer i tid, till exempel hur konsekvenserna av förändringar i data hanteras. Också mätning av integrationsfunktionens prestanda är bra att beakta redan från början. Användning av standarder, referensramar och modelleringssätt skapar en grund för enhetliga planerings- och beskrivningssätt. Bland annat följande referensramar och beskrivningsspråk finns tillgängliga: TOGAF (The Open Group Architecture Framework, referensram 3) ArchiMate 4 BPMN5 UML6 Som en del av lösningsarkitekturen väljs den teknik som integrationen implementeras med. Alla tekniska integrationer förutsätter en tillförlitlig datakommunikationsarkitektur som beskrivs närmare i kapitel 5. Den nationella servicekanalen har behandlats ur integrationsperspektiv i kapitel 6. I tekniska integrationer ingår alltid omsorgsfull planering och beskrivning av övervaknings- och monitoreringslösningar. Planeringsfaserna för integration är: 1. Identifiera den tjänstehelhet som utgör objekt för integrationen samt integrationsbehovet. 2. Identifiera och beskriv de punkter i integrationsobjektets övergripande arkitektur som påverkar integrationen och andra väsentliga punkter (t.ex. ansvar och roller, master data-praxis för uppgifterna, tillämpningsprofiler osv.). 3. Planera och beskriv interaktionen mellan aktörerna och processerna. 4. Definiera och beskriv interaktionen mellan informationssystem och applikationer. 5. Definiera och beskriv varje gränssnitt med hjälp av tidigare definitioner och riktlinjer. 6. Planera och beskriv lösningsmodellen (med hänsyn tagen till olika slags integrationstjänster, nätstrukturer, brandväggspraxis osv.). 7. Definiera och beskriv anslutningar i det logiska och fysiska nätet, systemtjänster som stöder nätverkstrafiken, referenspunkter och kontaktpunkter. Det detaljerade innehållet i planeringsfaserna presenteras i kapitlen 2 5. I intilliggande tabell har samlats de av den övergripande arkitekturens 1) grundläggande beskrivningar och 2) utökade beskrivningar som används och 3) skapas i integrationsplaneringen. 3 http://www.opengroup.org/subjectareas/enterprise/togaf http://www.opengroup.org/subjectareas/enterprise/archimate 5 http://www.bpmn.org/ 6 http://www.uml.org/ 4 3/27

1) Grundläggande beskrivning (JHS 179) - beskrivningar som behövs i integrationsplanering 2) Utökade beskrivningar (JHS 179) beskrivningar som behövs i integrationsplanering Beskrivning av verksamhetsarkitekturen Servicekarta Interaktion mellan aktörer Processkarta Interaktion mellan processer Processbeskrivningar Beroenden mellan tjänster och processer (Verksamhetens tjänstermatris) Beskrivning av verksamhetsarkitekturen Funktionella tjänster Beskrivning av informationsarkitektur Begreppssystem Konceptuell modell Ordlistor Beskrivning av informationsarkitektur Informationsflöden Logiska datamodeller Tillämpningsprofiler Processer-informationberoenden (matris) Aktörer-information-beroenden (matris) Beskrivning av informationssystemarkitektur Informationssystemens logiska gränssnitt (ÖA-tabeller, Logiska gränssnitt) Informationssystemens fysiska gränssnitt (ÖA-tabeller, Fysiska gränssnitt) Beskrivning av informationssystemarkitektur Arkitekturlagervy Interaktion mellan informationssystem Beskrivning av teknikarkitekturen Teknikval Beskrivning av teknikarkitekturen Tekniktjänster 3) Integrationer och gränssnitt slutresultat av integrationsplanering Principiell nivå Beskrivning av integrationsbehov Beskrivning av integrationsobjekt Identifierade beskrivningar på principiell nivå enligt JHS 179rekommendationen som påverkar integration Beskrivning av verksamhetsarkitekturen Vid behov footprint-diagram enligt TOGAF Precisera diagrammet Interaktion mellan aktörer (Visualisering av ÖA-beskrivningar, Interaktion mellan aktörer) Precisera beskrivningen Interaktion mellan processer för utvecklingsobjektet (Visualisering av ÖA-beskrivningar, Interaktion mellan processer) Beskrivning av informationsarkitektur Det centrala begreppssystemet för integration Tillämpningsprofiler Beskrivning av informationssystemarkitektur Arkitekturlagervy Precisering av beskrivningen av interaktion mellan informationssystem (Visualisering av ÖA-beskrivningar) Interaktion mellan informationssystem och integrationer Detaljerad integrationsbeskrivning Applikationernas gränssnitt Sekvensdiagram på grov och detaljerad nivå Logiska gränssnitt (ÖA-tabeller, Logiska gränssnitt) Fysiska gränssnitt (ÖA-tabeller, Fysiska gränssnitt) Beskrivning av teknikarkitekturen Preciserade teknikval 4/27

Logisk plattformsstrukturering Beskrivning av logiskt nätsverksdiagram (ÖA-tabeller, logiskt nätverksschema) Fysiskt nätverksdiagram i form av en lämplig figur Datakommunikationsarkitekturens struktur Logiskt nätverksdiagram beskrivning inklusive domäner (interna, externa) Domängränssnitt och referenspunkter Tabellen Logiskt nätverksdiagram Datakommunikationsförbindelser Applikationslagertjänster kopplade till datakommunikationsförbindelser (tillhandahållna/utnyttjade) Klassificering av datakommunikationsförbindelser att motsvara kraven Uppgifter om det fysiska nätverksdiagrammet (hör till det logiska nätverksdiagrammets datakommunikationsförbindelser) ID för fysisk förbindelse/kabel ID för gatewayapparat/kort/port Uppgifter om datakommunikations- och serverutrustning 2 Analys av integrationshelheten Integrationsplaneringen bör inledas genom en tydlig och systematisk analys av den tjänstehelhet som är föremål för integrationen och interaktionen för dess centrala element (integrationsprocessens faser 1 och 2). En del av de nödvändiga interaktionsdiagrammen har ofta redan gjorts under planeringen av verksamhetsarkitekturen. Nu behöver diagrammen bara vid behov kompletteras ur integrationsaspekten. Nätverkande vid produktion av en tjänst förutsätter att gemensamma integrationslösningar och gränssnitt eller gränssnittstjänster tas i bruk och leder ofta till strategiska val, som exempel Nationell servicekanal Suomi.fi7. Från beskrivningarna av verksamhets- och informationsarkitektur fortsätter man mot detaljerade och tekniska lösningar. Alla beskrivningar ska grundas på praktiska behov och finnas på en logiskt tydlig plats i integrationshelheten som i sin tur kan utgöra en del av en ännu större tjänstehelhet. Ett exempel på en tjänstehelhet är behandlingen i den offentliga förvaltningens elektroniska ärendehantering av en ansökan från en medborgare. Informationshelheten med anknytning till ansökan skapas och överförs genom olika behandlingsfaser och system till slut till slutförvaringsplatsen för informationen, till exempel ett elektroniskt arkiv. I integrationsbeskrivningar talar man om vilken tjänst och funktionellt behov integrationshelheten finns till för. I dataflödesbeskrivningar koncentrerar man sig på att analysera längs vilka vägar informationen rör sig mellan de centrala elementen i helheten. I informationsarkitekturen beskrivs strukturerna för den information som behövs i integrationen (logiska informationslager, begreppsmodeller, scheman osv.). För uppdatering av ordlistor och begreppssystem i anslutning till informationsinnehållet samt för utarbetande av begreppsmodeller kan man använda interoperabilitetsmetoden. Dess målsättning är att komplettera gemensamma ordlistor till att täcka hela den offentliga förvaltningen. Med hjälp av interoperabilitetsmetoden utarbetar den övergripande arkitekten en begreppsmodell som beskriver den helhet som granskas. I begreppsmodellerna bör man i så stor utsträckning som möjligt använda gemensamma begrepp som beskrivs i metodens datakomponentbibliotek. Med de harmoniserade begreppsmodellerna som grund utarbetas 7 https://esuomi.fi/palveluntarjoajille/palveluvayla/ 5/27

tillämpningsprofiler och meddelandestrukturer för den information som ska överföras. Begreppssystemet och ordlistan kan utökas vid behov. (Se bilaga 7 Metodanvisning för semantisk interoperabilitet). Tjänstehelheten kan struktureras med hjälp av Arkitekturens lagervy. Lagervyn är en visuell och tjänsteorienterad presentation och vy som sammanfattar organisationens eller utvecklingsobjektet övergripande arkitektur (se bilaga 6 punkt Arkitekturens lagervy). Figur 1. Ett renodlat och generaliserat modellexempel på arkitekturens lagervy. I den integrationshelhet som beskrivs finns typiskt flera gränssnitt mellan systemen. 3 Komplettering av verksamhetsarkitekturen ur integrationernas perspektiv 3.1 Funktionella tjänster I planeringen av verksamheten definieras aktörer, interaktion mellan aktörerna samt tjänster. För tjänster kan man till exempel skapa tjänstehelheter efter klientens livssituation. Relationerna mellan tjänstehelheterna är det i allmänhet vettigt att beskriva som interaktioner mellan de processer som krävs för att producera tjänsterna (se punkt 3.3). Identifierade funktionella organisationsgränssnitt stöder specifikationsarbetet i planeringsfasen av tjänster. I utvecklingsobjektets arkitektur är funktionella tjänster beskrivna i bilaga 5 ÖA-tabeller på fliken Funktionella tjänster. Bilaga 6 ÖA-Visualisering av ÖA-beskrivningar punkt Servicekarta visar tjänsterna i en kartliknande form. Beroenden för verksamhetens tjänster och processer beskrivs i bilaga 5 ÖA-tabeller på fliken Funktionella tjänster-processer. 6/27

Tjänsteproduktionshelheten kan också beskrivas mera detaljerat med Business Footprint Diagram8 enligt TOGAF. Diagram av det här slaget beskriver länkar mellan verksamhetsmål, organisationsenheter, tjänster och funktioner samt kopplar dessa funktioner med den teknik som krävs för att realisera önskade förmågor. Slutresultaten från fasen är: 3.2 Business Footprint Diagram-beskrivningar (vid behov). Interaktion mellan aktörer Klarläggande av interaktionen mellan aktörer (integrationsplanering fas 3) utgör grunden för att bestämma integrationsbehov och -krav. För interaktionen beskrivs tjänsternas användare (klienter) och tjänsternas producenter samt verksamheten mellan dessa. Resultatet presenteras som ett interaktionsdiagram som kan användas också vid planering av tjänsteproduktion, tjänstekedjor och -nätverk som överskrider organisationsgränser. De centrala informationsflödena i interaktionen och den information som överförs beskrivs på en allmän nivå med verksamhetens språk. För informationsflöden noteras också på en överskådlig nivå uppgifter om avtal, varu- och penningflöden samt andra motsvarande informationskällor för interaktion som hör ihop med tjänster. Beskrivningen utarbetas med hjälp av bilaga 6 Visualisering av KA-beskrivningar punkt Interaktion mellan aktörer. Anvisningar för användning av diagrammet över interaktion mellan aktörer finns i kapitel 7.2 Beskrivning av verksamhetsarkitekturen. Diagrammet över interaktion mellan aktörer kan vid behov kompletteras med användningsfallsdiagram för verksamheten (UML Business Use Case) där användningssituationer och -sätt för tjänster presenteras mera detaljerat. Slutresultaten från fasen är: 3.3 interaktionen mellan aktörer med hjälp av bilaga 6 Visualisering av KA-beskrivningar punkt Interaktion mellan aktörer. användningsfallsdiagram för verksamheten vid behov. Interaktion mellan processer Interaktionen mellan processerna ska klarläggas (integrationsplanering fas 3) för att optimera tjänsteproduktionens interna tjänstekedjor. Viktigt är att planera informationsutbytet och informationsflöden mellan processer och granskning av olika alternativ. För klarläggande av interaktionen kan processerna också betraktas som logiska processgrupper, till exempel: verksamhetsområdesvisa grupper eller processer som är knutna till en viss tjänst som granskas. Interaktionen mellan processer presenteras på logisk nivå med hjälp av bilaga 6 Visualisering av KAbeskrivningar punkt Interaktion mellan processer på det sätt som anges i rekommendationens kapitel 7.2.2 Beskrivning av verksamhetsarkitektur. Med hjälp av interaktionsdiagrammet för processer kan man gestalta i processen verkande aktörer som kan vara t.ex. roller och applikationer. Ur diagrammet ska informationsflöden mellan processer framgå klart och entydigt för att beskrivningen ska vara användbar i integrationsplaneringen. Slutresultaten från fasen är: 8 http://www.togaf.info/togaf9/togafslides9/togaf-v9-sample-catalogs-matrics-diagrams-v2.pdf 7/27

interaktionen mellan processer med hjälp av bilaga 6 Visualisering av ÖA-beskrivningar punkt Interaktion mellan processer. 4 Planering av informations- och informationssystemarkitektur ur integrationssynvinkel I detta kapitel behandlas planering av informationssystemarkitektur ur interoperabilitetens och integrationsarkitekturens synvinkel. Med integrationsarkitektur avses en grupp strukturelement i den övergripande arkitekturen som har informationsöverföring och inbördes interaktion mellan strukturdelarna som gemensam nämnare. Integrationsarkitekturen berör de fyra aspekterna i den övergripande arkitekturramen. I kapitlet används som genomgående exempel integrationsbeskrivningar från den nationella servicearkitekturen (KaPA). I kapitlet behandlas inte datakommunikationsprotokoll och motsvarande saker som hör till lösningsarkitekturens tekniska nivå. Planering av informationsarkitektur och beskrivningar presenteras i rekommendationens kapitel 7.3 Beskrivning av informationsarkitektur. Planering av informationssystemarkitektur och beskrivningar behandlas i rekommendationens kapitel 7.4 Beskrivning av informationssystemarkitektur. 4.1 Logiska datamodeller och tillämpningsprofiler För informationsutbytet kan man av datamodellerna bilda en eller flera tillämpningsprofiler på vars grund meddelandestrukturen skapas. För att säkerställa den semantiska och tekniska interoperabiliteten ska meddelandestrukturen beskrivas i form av en tillämpningsprofil vars utformande beskrivs närmare i bilaga 7 Metodanvisning för semantisk interoperabilitet. I arbetsflödesdiagrammet nedan visas hur interoperabilitetsmetoden används i integrationsplanering ur informationsarkitekturens perspektiv. Figur 2. Arbetsflödesdiagram för användning av interoperabilitetsmetoden i informationsintegration. 8/27

Vid utarbetandet av tillämpningsprofilen ska branschspecifika, nationella och internationella rekommendationer och standarder som stöder interoperabilitet beaktas. Det är särskilt viktigt att ta hänsyn till interoperabilitet vid tväradministrativa integrationer som förenar organisationer eller branscher. Tillämpningsprofilernas tekniska strukturdefinitioner kan anges som XML-scheman enligt rekommendationen JHS 170 XML-scheman för den offentliga förvaltningen9 eller annat alternativt beskrivningsspråk för meddelandestruktur, som JSON. 4.2 Interaktion mellan informationssystem Med hjälp av diagrammet för interaktion mellan informationssystemen (integrationsprocessens fas 4) visas informationsflöden mellan informationssystem och vid behov på en mera detaljerad nivå mellan applikationskomponenterna. I diagrammet specificeras dock inte i detalj hur informationen går mellan systemen. De informationssystem eller applikationskomponenter som valts till interaktionsdiagrammet kan grupperas och diagrammets informationsinnehåll kan ökas till exempel på följande sätt: informationssystem eller applikationskomponenter grupperas och färgas enligt applikationskartans logik. till dataflöden läggs rubriktext om de överförda uppgifterna åtminstone på nivån huvuddatagrupper eller datagrupper. Figur 3. Interaktion mellan informationssystem (källa: Jyväskylä stad). I figur 3 visas informationsflöden mellan applikationer och applikationskomponenter (t.ex. Effica-hemvård) (se bilaga 6 Visualisering av ÖA-beskrivningar punkt Interaktion mellan informationssystem och rekommendationens kapitel 7.4 Beskrivning av informationssystemarkitektur). Vid planering av integrationen mellan informationssystem beskrivs de informationssystem eller applikationskomponenter som ska integreras samt de uppgifter som överförs mellan dem. Beakta begränsningar och möjligheter för de system som ingår i integrationsramen. I rekommendationen JHS 166 Avtalsvillkor för IT-upphandlingar inom den offentliga sektorn bilaga 9 (Stödmaterial: Öppna 9 http://www.jhs-suositukset.fi/suomi/jhs170 9/27

gränssnitt vid upphandling av IT-system eller -tjänster )10 finns en definition på vad som avses med öppna gränssnitt i offentliga upphandlingar och vilka krav som ställs på öppna gränssnitt. Beakta också dessa krav. Som exempel (se figur 4) beskrivningen av Jyväskylä stads hemvårdstjänster där varje integration har en identifierare (id, APn). Figur 4. Informationssystemens interaktion och integrationer (källa: Jyväskylä stad). I figurer refereras det till servicekanaler, integrationsplattformar o.dyl. på logisk nivå, ett exempel visas i figur 5. Figur 5. Detaljerad integrationsfigur (VTJ-förfrågan, Servicekanalen). Slutresultaten från fasen är: 10 interaktionen mellan informationssystem med hjälp av bilaga 6 Visualisering av ÖA-beskrivningar punkt Interaktion mellan informationssystem interaktionsdiagram för informationssystem med identifierade gränssnitt mera detaljerade beskrivningar av integrationslösningar. http://www.jhs-suositukset.fi/suomi/jhs166 10/27

4.3 Beskrivning av gränssnitt Allmänt Integrationsbeskrivningar på detaljerad nivå behövs för implementeringsarkitekturen. En integration (anslutning, interaktion, samverkan) kan använda flera gränssnitt, anpassningstjänster eller anslutningstjänster. Viktiga planeringsobjekt i tekniska gränssnittsbeskrivningar är standardiserade programmeringsgränssnitt som Web Services, REST eller JSON, kodade strukturer för gemensam information samt integrationspatterns, integrationsplattformar och servicekanaler. Interaktionen mellan gränssnitten och strukturen för den överförda informationen beskrivs till exempel med UML-sekvensdiagram, WSDLdefinitioner och XML-scheman. Gränssnitt bör i framtiden utvecklas som gränssnittstjänster som utöver den tekniska implementeringen innehåller en servicenivå, dokumentation, beaktande av utvecklarupplevelse och anpassning som en del av verksamheten och organisationens tjänsteutveckling. En organisation inom den offentliga sektorn bör implementera ett öppet gränssnitt som en del av sin API-familj alltid när detta är möjligt (läs mer på adressen avoinrajapinta.fi). När det gäller ett gränssnitt som tillhandahåller öppna data ska rekommendationen JHS 189 Användarrättighet för öppen data11 tillämpas. Gränssnitten till centrala informationslager och funktioner ska betraktas som produkter som i sig själva har en livscykel och ett värde. Till livscykelhanteringen för gränssnitt och gränssnittstjänster hör agil planering, implementering med moderna metoder, kontrollerad ibruktagning, administration av gränssnitt och planerad avveckling samt tydlig versionshantering. Planering av gränssnitt I planeringen av gränssnitt kan man använda bl.a. uppdaterad listning av gränssnitt och anslutningar dokumentation från eventuellt ESB-verktyg dokumentation från eventuellt CMDB-verktyg UML-beskrivningar integrationsprofiler. För aktuellt delområde utarbetas beskrivningar som innehåller gränssnitt, integrationselement, adaptrar och eventuella integrationsprofiler som används. En integrationsprofil beskriver typiskt på detaljnivå transaktioner, stödda filformat, kombinering av förfrågningar eller behandling av komplicerade händelser. Varje gränssnitt beskrivs för sig (integrationsprocessens fas 5). Beskrivning av gränssnittstjänster Gränssnittstjänster är digitala tjänster som programmerats för allmänt utnyttjande av tekniska, statiska gränssnitt, som till exempel överföringstjänst för information som söks genom gränssnittet. Gränssnittstjänsterna kan sammanställas av flera olika erbjudna gränssnittstjänster av vilka bara en del väljs ut (t.ex. tas inte alla olika dataformat i bruk). Gränssnittstjänster kan beskrivas och samlas i bilaga 5 ÖAtabeller på fliken Informationssystemtjänster. Med informationssystemtjänst avses i JHS 179-rekommendationen slutanvändartjänster som innehåller användargränssnitt samt automatiserade applikationstjänster som innehåller ett gränssnitt. Applikationer i aktörens eget bruk använder också samma gränssnittstjänster som tillhandahålls åt andra applikationer, det vill säga användare är interna applikationer, kundapplikationer som aktören erbjuder och vidareförädlares applikationer. 11 http://www.jhs-suositukset.fi/suomi/jhs189 11/27

För implementering av gränssnittstjänster finns anvisningar till exempel i Kansallisen palveluarkkitehtuurin liityntäkatalogiohjeissa12 eller aktörernas egna anvisningar. I en gränssnittstjänst ingår bl.a.: beskrivning av tjänsten specifikation av servicenivån dokumentation administration av åtkomst och användarroller beaktande av utvecklarupplevelse versionshantering livscykelhantering. Gränsytan för applikationslagrets tjänster (informationssystemtjänst) ska beskrivas på ett så enhetligt sätt som möjligt när det gäller data som ingår i ÖA-tabeller (se bilaga 5 ÖA-tabeller på fliken Informationssystemtjänster). Till exempel när det gäller uppgifter gällande tillgänglighet, servicenivå och datasäkerhet möjliggör ett enhetligt beskrivningssätt jämförelser och analyser mellan flera tjänster. Vidare borde tillgänglighet, servicenivå och datasäkerhet beskrivas på ett så enhetligt sätt som möjligt även i andra uppgifter som ingår i ÖA-tabellerna. Grunduppgifterna för varje gränssnitt anges enigt bilaga 5 ÖA-tabeller flik Logiska gränssnitt. För fysiska gränssnitt beskrivs de gränssnitt som implementeras i dataöverföring, t.ex. WSDL- och/eller REST-scheman (se bilaga 5 ÖA-tabeller, Fysiska gränssnitt). Dataöverföringsscheman ska baseras på logiska datamodellbeskrivningar, till exempel tillämpningsprofiler, som skapas på det sätt som visas i referensramen Semantisk interoperabilitet (se bilaga 7 Metodanvisning för semantisk interoperabilitet). Beskrivning av gränssnittens interaktion För beskrivning av gränssnittens interaktion kan man använda diagram enligt UML-modellering, till exempel UML Interaction Overview Diagram enligt figur 6. I diagrammet läggs flera sekvensdiagram samman i ett diagram. 12 https://liityntäkatalogi.suomi.fi 12/27

Figur 6. UML Interaction Overview Diagram. Verksamhetsarkitekturen preciseras vid behov i integrationsarkitekturen med t.ex. sekvensdiagram. På samma sätt preciseras teknikarkitekturen vid behov med definition av den tekniska meddelandestrukturen. Delar som i figur 6 har noteringen ref, beskrivs noggrannare som sekvensdiagram. Ett sekvensdiagram är ett diagram som används i UML-modellering för att beskriva interaktionen mellan objekt. På applikationsnivån kan man först utarbeta ett sekvensdiagram på hög nivå enligt figur 7 som preciseras med ett UML-sekvensdiagram. Sekvensdiagram utarbetas för centrala operationer och situationer där användningen av diagram främjar förståelsen av strukturerna. I UML-sekvensdiagram beskrivs ordningsföljden för meddelande mellan komponenter/objekt i en viss applikation. 13/27

Figur 7. Exempel på sekvensdiagram på hög nivå. Sekvensdiagrammet kan också göras upp på mera detaljerad nivå, ett exempel visas i figur 8. 14/27

Figur 8. Exempel på mera detaljerat sekvensdiagram. Molntjänsters gränssnitt Integrationen och gränssnitten för en informationssystemtjänst som anskaffas som molntjänst beskrivs på logisk och fysisk nivå för informationssystem som är under såväl egen som leverantörens kontroll. Ytterligare information om molntjänster och t.ex. SaaS-tjänst (Software as a Service) finns i rekommendationens bilaga 9 Virtualisering och molntjänster vid planering av teknikarkitektur. Figur 9. Modellering av SaaS-tjänster. 15/27

4.3.1 Exempel på användning av ESB-tjänst (VIA) Med hjälp av statens gemensamma integrationstjänst (VIA) kan organisationer inom statsförvaltningen överföra data (meddelanden) antingen mellan sina egna datasystem eller mellan egna datasystem och andra organisationers datasystem. Integrationstjänsten VIA är en centraliserad tjänst för förmedling av meddelanden med vars hjälp organisationer kan implementera integrationer. En centraliserad tjänst kan minska antalet olika slags integrationer mellan datasystemen och underlätta övervakning av dem. Genom att använda VIA kan man uppnå en mera hanterbar integrationsarkitektur och en tydligare övergripande arkitektur. VIA är ett system med hög säkerhetsnivå och kan användas för att överföra material på skyddsnivå III. VIA (eller en traditionell busslösning) lämpar sig bäst för fall där något av följande gäller: man vill göra överföringarna med REST-protokollet överförda meddelanden är stora eller innehåller bifogade filer traditionella satsvisa överföringar krävs (SFTP-överföringar) det överförda materialet har skyddsnivå III eller så krävs höjd datasäkerhetsnivå man vill göra överföringarna inom VY-nätverket det krävs överföringar mellan nivå IV och nivå III validering av meddelanden krävs virusscanning krävs det krävs transformationer av meddelandeinnehåll, som: - CSV -> XML/JSON. - Fast längd/flatfile -> CSV/XML/JSON. - XML -> JSON -> XML. Den nationella servicekanalen lämpar sig väl för den integration som ska implementeras, om meddelandeförmedlingen kan göras med 4.3.1.1 SOAP-protokoll små meddelanden material som är offentligt eller på nivå IV. Meddelandebaserade integrationer VIA stöder grundintegrationspattern, som: routing baserad på innehåll protokolltransformering dataöverföring meddelandetransformering utökning/filtrering av innehåll begäran-svar (asynkron) begäran utan returvärde (fire-and-forget) Transformationer av meddelandebaserade meddelanden kan vara till exempel att göra om ett meddelande som kommer in med REST-protokoll till ett SOAP-meddelande. I figur 10 nedan skissas på olika slags transformationsscenarier. 16/27

Figur 10. Transformationer av SOAP/REST-meddelanden med hjälp av VIA. 4.3.1.2 Överföring av stora bilagematerial i SOAP/REST-anrop För överföring av stora bifogade filer har VIA sin egen metod där de bifogade filerna överförs som en separat överföring och det egentliga meddelandet som ett eget synkront anrop. I den första fasen av dataöverföringen skickas bilagan till VIA. VIA viruskontrollerar bilagan och skickar efter kontrollen en unik ID-uppgift om materialet. Med denna id-uppgift refererar Sändaren i det egentliga SOAP/REST-meddelandet till det bifogade materialet som levererats tidigare. VIA skickar ett anrop i SOAP/REST-format vidare och lägger till en URI-länk i meddelandet som Mottagaren kan använda för att hämta det bifogade materialet. Principen/sekvensdiagrammet för denna överföring visas i figur 11. Figur 11. Principen/sekvensdiagrammet för överföringslösningen för stora filer. 4.3.1.3 Filöverföringar (SFTP) VIA möjliggör också satsvisa (synkrona eller asynkrona) överföringar med användning av SFTP-protokoll. I figur 12 visas alternativ för dataöverföringar. Figur 12. Filöverföring med hjälp av VIA. 17/27

Slutresultat av kapitel 4 är: Tabellen Logiska gränssnitt Tabellen Fysiska gränssnitt UML Interaction Overview Diagram. Sekvensdiagram. 5 Teknikarkitekturen ur integrationsperspektiv Arbetet med teknikarkitektur och resultaten av det beskrivs i rekommendationens kapitel 7.5 Beskrivning av teknikarkitektur. I detta kapitel fokuseras på beskrivning av datakommunikationsarkitekturen. 5.1 Datakommunikationsarkitekturen som en del av IT-infrastrukturen Datakommunikationsarkitekturen beskriver de nätverksstrukturer och mekanismer med vars hjälp dataöverföring kan tillhandahållas ände till ände för systemen på applikationsnivå (integrationsprocessens fas 6). Datakommunikationsarkitekturen består av flera slag av apparat- och programvaruelement som bildar datakommunikationsnäten, deras fysiska resurser som datakommunikationskablar, nätutrustning (apparat/kort/port), apparatutrymmen samt motsvarande logiska resurser och de element som uppstår genom kombinationer av dem, som vägar (link/transport) eller förbindelselager (VLAN, MPLS m.fl.). Datakommunikationsarkitekturen ska vid behov omfatta till exempel fysiska kabeluppgifter, korskopplingar, router- och switchportar, servernoder och -anslutningar, beskrivningar av anslutningspunkter till hyrda nättjänster eller förbindelser samt de inbördes beroendena mellan dessa och infrastrukturen i apparatrum 13. Principer som tillämpas Arkitekturprinciperna beskrivs enligt rekommendationens kapitel 6.3.4.2 Beskrivning av arkitekturens målbild genom grund- eller utökade beskrivningar (se även bilaga 5 ÖA-tabeller flik Arkitekturprinciper). När det gäller de principer som styr datakommunikationsarkitekturen bör följande principer beaktas: Datakommunikationsarkitekturen bör beskrivas på logisk och fysisk nivå. Varje aktör svarar för beskrivningarna (logiska och fysiska nätverksdiagrammet) av datakommunikationsarkitekturen inom de verksamhetsområden man äger (verksamhetsområde=domän). Beskrivningen av datakommunikationsarkitektur görs från två håll: - Nätverkets perspektiv på datakommunikationsarkitekturen skapar förutsättningar i infrastrukturen för att beskriva applikationernas kommunikation. Begrepp som används är till exempel Nod (Node), Domän (Domain), Apparat (Device), Kort (Card), Port (Port), Förbindelse (Connection), Kabel (Cable), osv. - Perspektivet för applikationslagrets tjänsters på modelleringen av datakommunikationsarkitekturen ställer krav på datakommunikationsnätets implementering och dess beskrivning. Kraven från applikationslagrets tjänster på datakommunikationsinfrastrukturen är kvalitativa (tillgänglighet, säkerhetsåtgärder, servicenivå, fördröjning osv.), kvantitativa (datavolymer, överföringshastigheter osv.) eller gäller datasäkerhet (t.ex. skyddsklass). 13 Baserat på beskrivningen TOGAF 9.1 4.3 Foundation Architecture: Technical Reference Model 43.3.5 Communication Infrastructure 18/27

5.2 Beskrivningen av datakommunikationsarkitekturen på logisk och fysisk nivå kan göras med beskrivningsverktyg som är speciellt framtagna för detta, men de minimikrav som presenteras här bör utföras oberoende av beskrivningsverktyg. Datakommunikationsarkitekturen ur nätverkets perspektiv (nerifrån och upp) I JHS 179-rekommendationens teknikarkitekturkapitel 7.5.2 7.5.3 ges anvisningar för beskrivning av den fysiska och logiska datakommunikationsarkitekturen samt en beskrivningsmall för logiskt nätverksdiagram (se bilaga 5 ÖA-tabeller flik Logiskt nätverksdiagram). I figurerna 13 och 14 visas kopplingen mellan det logiska och fysiska nätverksdiagrammet. Datakommunikationsarkitekturen bör stöda: detaljnivå (granularitet) till den nivå som analyskraven förutsätter identifiering av aktörens domäner beskrivning av domänernas gränsytor med referenspunkter. I samband med datakommunikationsnät kan domän-begreppet baseras på aktörens ansvarsområde, tillämpad nätverksteknik, zonarkitektur, operatörsområde för underleverantör eller annat krav. I beskrivningarna av datakommunikationsnät kan domäner vara överlappande 14. I exemplet i figur 13 har tre standardiserade domän-typer identifierats och mellan dessa fyra referenspunkter med vilka man i en enhetlig funktionsroll kan modellera andra motsvarande datakommunikationsnät i nuläget (As-Is). Framöver lär det uppstå behov av att standardisera nya domän-typer och tillhörande nya referenspunkter, men antalet standardiserade domän-typer och referenspunkter bör minimeras. Figur 13. Nätverksdomäner. 14 Se TOGAF 9.1 4.3 Foundation Architecture: Technical Reference Model 43.3.7 Communication Infrastructure Interface 19/27

5.3 Datakommunikationsnäts anslutningsgränsytor (RP=ReferensPunkt) I den övergripande arkitekturmodellens datakommunikationsarkitektur bör det finnas en begränsad mängd enhetligt beskrivna (standardiserade) anslutningsgränsytor. I figur 14 visas det logiska datanätets koppling till det fysiska datanätet. Sådana anslutningsgränsytor är också datakommunikationsförbindelsernas gränsytor och anslutningsgränsytor för olika datakommunikationsnät inom olika domänansvarsområden (sammankopplingsgränsytor). För beskrivning av dessa finns tabellmallen Logiskt nätverksdiagram (se bilaga 5 ÖA-tabeller flik Logiskt nätverksdiagram). Figur 14. Anslutningsgränsytor.15 5.4 Datakommunikationsarkitekturens nätverksbeskrivningar Gränsytan för tjänster i applikationslagret (informationssystemtjänst) ska beskrivas på ett så enhetligt sätt som möjligt när det gäller uppgifter som ingår i ÖA-tabeller. Till exempel när det gäller uppgifter gällande tillgänglighet, servicenivå och datasäkerhet möjliggör ett enhetligt beskrivningssätt jämförelser och analyser mellan flera tjänster. Vidare borde tillgänglighet, servicenivå och datasäkerhet beskrivas på ett så enhetligt sätt som möjligt även i andra uppgifter som ingår i ÖA-tabellerna, som i Logiskt nätverksdiagram. På det sättet kan man säkerställa att kraven från tjänsterna i applikationslagret uppfylls för datakommunikationsinfrastrukturen och enskilda datakommunikationsförbindelser. Beskrivningen av datakommunikationsarkitekturen som en del av den övergripande arkitekturen ska göras på en sådan detaljeringsnivå som gör analys möjlig på nivån en enskild tjänst på applikationsnivån (datakommunikationstjänst) och tillhörande datakommunikationsförbindelse (IP-flow) som en del av planeringen av arkitekturen för datakommunikationsnätet. 15 Som referensmaterial för arkitekturmodeller för allmänna datakommunikationsnät har i detta arbete som källa använts ITU G.809 Functional architecture of connectionless layer networks. 20/27

Då blir det möjligt att analysera inbördes beroenden (dependency) och påverkan (impact) mellan en applikationslagertjänst och en datakommunikationsförbindelse (logisk och fysisk) i förhållande till de olika slags parametrar som används i ÖA-modellen, t.ex. informationssystemtjänstens och datakommunikationsförbindelsens tillgänglighet (on, off, % availability) informationssystemtjänstens och datakommunikationsförbindelsens servicenivå (SLA, OLA, quality) analys av skyddsnivåer i anslutning till informationssystemtjänst eller för data som dataöverförbindelsen överför analys av kritiska komponenter och noder i helheten. Med hjälp av bilaga 5 KA-tabeller mallarna Logiskt nätverksdiagram och Logiska gränsytor kan en referenspunkt-id mellan datakommunikationsnäten/domänerna kopplas till värdet på den datakommunikations-id som den överför och vidare till den applikationsgränsyte-id som ansluter till den. Referenspunkt-ID mellan datakommunikationsnäten/domänerna kan vidare kopplas till den fysiska förbindelse som realiserar den, som ID för kabeln eller ID för gatewayutrustning, -kort eller -port. Den fysiska datakommunikationsinfrastrukturen beskrivs som en del av annan teknikarkitektur inklusive uppgifter om datakommunikationsapparater och servrar. En detaljerad beskrivning av teknikarkitekturen underhålls ofta med verktyg som utvecklats för detta, till exempel som en del av ett CMDB-system eller med ett separat inventariesystem för apparat- eller nätverksuppgifter som håller alla nödvändiga apparattyper, deras instanser, apparaternas kort/port-relationer och nödvändig kabel- och kopplingsinformation i sin databas. Med CMDB- och inventeringsverktyg kan man utöver en noggrann fysisk beskrivning också beskriva logiska förbindelse ände-ände (t.ex. förbindelsetyper L1, L2 och L3). Underhåll av uppgifter med CMDB- eller inventarieverktyg utnyttjar discovery-information som kan avläsas från nätverkets aktiva apparater. Med beskrivningsverktyg (inventarie- eller CMDB-verktyg) för det fysiska och logiska nätverket beskrivs bl.a. följande uppgifter: apparatuppgifter och anslutningspunktsuppgifter kablerings- och kopplingsscheman nätverkens referenspunktsuppgifter logiska punkt-punkt-förbindelser placeringsuppgifter. 21/27

5.5 Datakommunikationsarkitekturen ur applikationsmodellerarens perspektiv (uppifrån och ner) Figur 15. Informationssystemtjänster vid anslutning till datakommunikationsnät. Vid granskning av datakommunikationsarkitekturen utgår man från att datakommunikationsarkitekturen är kopplad till den övergripande arkitekturen (integrationsprocessens fas 7). I detta fall är det smidigast att koppla datakommunikationsbeskrivningarna med hjälp av informationssystemens applikationstjänster till den övergripande arkitekturen. I figur 15 visas ett informationssystem som består av en serverapplikation och en klientapplikation. Serverapplikationen tillhandahåller en systemtjänst där användaren är klientapplikationen. Informationssystemtjänsten publiceras som applikationslagertjänst. Serverapplikationen kan producera flera informationssystemtjänster. I figur 15 visas beskrivning av informationssystemtjänsten på två alternativa sätt: Det första sättet är att använda modelleringsverktygets ovala symbol där informationssystemtjänstens namn skrivs in. Tjänsteleverantörens koppling beskrivs med realisationspilen. Tjänsteanvändaren koppling beskrivs med användningspilen. Det andra sättet är att använda en beskrivning med "klubba och gaffel", där tjänsteleverantören publicerar en "klubba" som användaren av tjänsten använder med "gaffeln". Båda sätten kan användas parallellt. I det fallet beskriver den ovala symbolen den logiska förbindelsen och delen med "klubba och gaffel" kan brytas upp och därigenom åskådliggöra att den datakommunikationsarkitektur som är kopplad till informationssystemet består av olika delar. 22/27

I figuren realiserar tjänsteleverantörens nod produktion/publicering av applikationslagrets tjänst och tjänsteanvändarens nod realiserar användning av tjänsten. Beskrivningen av olika nätverksdelar görs med hjälp av logiska delar och molnet (fysisk realisering). Därvid kan man tydligt separera logiska (allmänna) delar och fysiska (publika) delar till egna helheter. Applikationslagrets tjänster beskrivs som tjänstens gränsyta (Tjänsteleverantörens gränsyta, Tjänsteanvändarens gränsyta). Datakommunikationsförbindelserna beskrivs med hjälp av nätverk/domäner och referenspunkter (RP) mellan dessa. Varje nätverkspart har ansvar för att beskriva fungerande/realiserade förbindelser "över" det egna molnet. Då kan datakommunikationsförbindelser mellan varje serverapplikation och klientapplikation sätta samman. Tjänsteleverantörens applikationsmodellerare publicerar sin applikations tjänst: Tjänsteleverantörens applikationsmodellerare beskriver applikationslagertjänstens gränsyta - vilka åtgärder vidtas och med vilken information i tjänsteleverantörens gränsyta. Tjänsteleverantörens applikationsmodellerare definierar också icke-funktionella krav i tjänsteleverantörens gränsyta. Tjänsteanvändarens applikationsmodellerare kopplar sin applikation till den publicerade tjänsten: Tjänsteanvändarens applikationsmodellerare beskriver tjänsteanvändarens gränsyta - vilka åtgärder behövs och med vilken information i tjänsteanvändarens gränsyta. Tjänsteanvändarens applikationsmodellerare beaktar icke-funktionella krav i tjänsteanvändarens gränsyta. Exempel 1 Logiskt och Fysiskt nätverksdiagram. I figur 16 finns ett exempel på visualisering av beskrivning av dubblerade fysiska datakommunikationsvägar i VY-nätverkets gränsyta som en logisk datakommunikationsförbindelse. 23/27

Figur 16. Exempel på logiskt och fysiskt nätverksdiagram. Exempel 2: Exempel på punkt-punkt-beskrivning Om ett arkitekturbeskrivningverktyg används kan man med det beskriva anslutningen av de informationssystemtjänster som finns ovanför en logisk datakommunikationsförbindelse till ovanliggande strukturdelar i informations- verksamhetsarkitekturen, som datagrupper och processfunktioner (se figur 17). Figur 17. Exempel på nätverksdiagram som beskrivits med ett verktyg. 24/27

Slutresultat av kapitel 5 är: Preciserade teknikval Datakommunikationsarkitekturens struktur Beskrivningen Logiskt nätverksdiagram inklusive domäner (interna, externa) domängränssnitt och referenspunkter Tabellen Logiskt nätverksdiagram datakommunikationsförbindelser applikationslagertjänster kopplade till datakommunikationsförbindelser (tillhandahållna/utnyttjade) klassificering av datakommunikationsförbindelser att motsvara kraven Uppgifter om det fysiska nätverksdiagrammet (hör till det logiska nätverksdiagrammets datakommunikationsförbindelser) ID för fysisk förbindelse/kabel ID för gatewayapparat, -kort eller -port Uppgifter om datakommunikations- och serverutrustning 6 Nationella servicearkitekturen ur ett integrationsperspektiv Den nationella servicekanalen16 en av den offentliga förvaltningens stödtjänster för elektronisk ärendehantering som ingår i den nationella servicearkitekturen (KaPA). Sådana är också bl.a. servicedatalager, identifieringstjänst, befullmäktigande och tjänstevyer. Den nationella servicekanalen är en integrationslösning som gör det möjligt för organisationer att utbyta information på ett säkert sätt över datakommunikationsnätet. Samma organisation kan vara både informationsleverantör som användare. Figur 18. Den offentliga förvaltningens datakommunikationsnätsarkitektur. 16 https://www.avoindata.fi/data/fi/dataset/kansallisen-palveluvaylan-viitearkkitehtuuri 25/27

Den nationella servicekanalen består av en publik informationskanal samt separata zoner som kan ha egna integrationslösningar. Den publika servicekanalen är en kontrollerad och säker informationsförmedlingstjänst på internet. Dess realisering baseras i Finland på X-Road17-tekniken. En zon är ett område inom vilket man kan använda en dataöverföringslösning eller definitioner som avviker från den publika servicekanalen. Det är ofta ett delnätverk som är SLA-säkrat eller har en högre datasäkerhetsnivå eller en branschspecifik helhet. Inom zonen kan zonspecifika lösningar användas i dataöverföringsinfrastrukturen med hänsyn tagen till skyddsnivåer. Den nationella servicekanalen använder publikt internet för sin funktion under det att zonspecifika lösningar verkar inom zonen. I API-katalogen18 beskrivs servicekanalens alla19 API:er för utvecklare. Informationen i servicedatalagret (PTV) är avsett för slutanvändare av tjänsterna (medborgare, företag, myndigheter). Den nationella servicekanalen (X-Road) är en meddelandeförmedlingsbuss som använder SOAP-protokollet och som är avsett för standardiserad informationsöverföring mellan organisationer. Servicekanalen krypterar också meddelandetrafiken. I figur 18 åskådliggörs olika zoner och deras anslutning till den publika servicekanalen. En tjänsteleverantör kan tillhandahålla gränsytor till sin tjänst i den publika servicekanalen, med hjälp av en separat zon eller utanför den nationella servicekanalen. Behoven ska analyseras innan beslut fattas. Till den nationella servicekanalen ansluts som regel tjänster som kräver identifiering. Ifall tjänsten används inom en zon, bör integrationen byggas inom zonen för att undvika användning av publikt internet i utbytet av meddelanden. Stora asynkrona dataöverföringar och satsvisa körningar förmedlas inte som sådana genom den publika servicekanalen och de bör som regel inte konstrueras med t.ex. en anslutningslösning till X-Road-tekniken. I tjänster med öppna data kan dataöverföringen i bakgrunden ske även i den publika servicekanalen genom specialarrangemang. Trafik mellan organisationens interna system rekommenderas inte gå genom den publika servicekanalen. Den nationella servicekanalen är en helhet som består av organisationernas anslutningsservrar och där sammankopplingen av information och tjänster styrs nationellt. Servicekanalarkitekturen skapar en gemensam lösningsmodell för organisationernas datautbyte. Detta undanröjer behovet av skräddarsydda anslutningar mellan två parter och främjar utvecklingen av digitala tjänster. Tjänster som ansluts till den nationella servicekanalen ska stöda realtidsfunktion såvida inte en tydlig motivering för en annan lösning finns. I en tjänsteprocess som integreras med hjälp av servicekanalen ska en offentlig part ingå. Tjänstens beskrivning ska kunna jämföras. Tekniska uppgifter, som gränssnitt ska vara beskrivna i API-katalogen och beskrivningar av tjänsternas innehåll i servicedatalagret (PTV). Den nationella servicekanalen tillhandahåller bara viktiga tjänster för informationsutbyte. Produktion av andra tjänster ligger på den anslutande organisationens ansvar. I den nationella servicekanalens referensarkitektur förs fram behovet av olika slags integrationslösningar utöver den publika servicekanalen. Detta behov söker man täcka med hjälp av zonmodellen för servicekanalen. I den publika servicekanalen är meddelandenas överföringsram (protokoll) noggrant definierat för att den valda produkten ska realisera. Inom andra zoner är inte det inte så utbrett med etablerad praxis för enhetliga gränsytor. Många organisationer har standardbaserade lösningar i intern användning inom organisationen och tjänster publiceras även för externa parter med användning av dessa gränsytor. 17 18 http://esuomi.fi/palveluntarjoajille/palveluvayla/tekninen-aineisto/x-road-tiedonsiirtoprotokolla-2/ https://liityntakatalogi.suomi.fi/ 19 https://esuomi.fi/palveluntarjoajille/palveluvayla/palvelukuvaus/ 26/27