Standarder for integrasjonsarbeid

Transkript

1 Standarder for integrasjonsarbeid Kristian Bergem Direktoratet for forvaltning og IKT Avdeling for digital forvaltning Seksjon for nasjonal arkitektur

2 Bakgrunn Startet opp høsten workshoper med off. virk. og leverandører Etablerte arbeidsgruppe Startet opp med adressecasen Litt dialog med to operative caser Dødsårsaksdialogen Fordeling av tippemidler Endring i ressurssituasjonen, lagt på is 12 April 2016 Direktoratet for forvaltning og IKT

3 Tatt opp igjen sen høst 2015 Ny i Norge case Skal oppsummere adressecasen Gjennomføre noen intervjuer for å klargjøre de to andre casene 12 April 2016 Direktoratet for forvaltning og IKT

4 Leveranser Case rapporter Forprosjektrapport oppdeling i og prioritering av bruksområder Innspill til felleskomp. arbeidet Behov for samhandlingsprinsipper (egen standard eller del av NIF) Web-services 12 April 2016 Direktoratet for forvaltning og IKT

5 Casebeskrivelse «Ny i Norge» Vi tenker oss en lege fra Hellas som blir tilbudt jobb i Norge på et internasjonalt seminar i Marbella i Spania. Etter å ha blitt autorisert som lege av SAK i Norge blir det inngått kontrakt med den nye arbeidsgiveren «Serium» som er et privat helseforetak. Legen tar fly fra Athen til Oslo og begynner å jobbe hos Serium mens hun bor på en av Seriums hybelleiligheter. Etter noen uker finner legen en passe leilighet i Oslo. Legen har en mann som er forfatter og de har 2 barn som er i 7 og 14 år. Hun tar fly tilbake til Hellas og de tar sin nye BMW SUV og kjører fra Athen til Oslo samtidig med flyttebilen som de har leid. Case-beskrivelsen fokuserer i det videre hvordan legen med familie møter offentlige virksomheter i forbindelse med det å være ny i Norge.

6 Nåsituasjon Ny i Norge (EØS) Involverte offentlige aktører i forbindelse med legens etablering i Norge: Sak UDI Folkeregisteret Skatt Helsedir NAV Biltilsynet Oslo Kommune skoleetaten Tollvesenet

7 Intervju av sentrale etater og brukere Intervju (faglig) Sak UDI Skatteetaten, folkereg. Intervjuet noen brukere Testet ut tjenestene på nett Ringt ulike virksomheter for å få brukerstøtte 12 April 2016 Direktoratet for forvaltning og IKT

8 Prosessdiagram nåsituasjon arbeidsinnvandring fra EØS

9 Nåsituasjon Ny i Norge (EØS) A: Søknad om autorisasjon som lege hos SAK Søknaden med vedlegg ble sendt fra Hellas. Diverse dokumenter måtte oversettes til engelsk og «rett kopi» måtte stempels av Notarius publicus i Aten og søknad med vedlagte dokumenter måtte deretter sendes med posten til SAK i Norge. Det måtte også betales et gebyr i norske kroner. Etter 4 måneder mottok hun så autorisasjonen fra Norge og hun kunne sette seg på et fly for å begynne å arbeide hos den nye arbeidsgiveren i Oslo. B: Søknad om skattekort Før hun kunne motta lønn måtte hun søke om skattekort. Dette kunne hun ha gjort i forbindelse med registrering, men siden timebestillingen hos SUA hadde bort imot en måneds ventetid, så valgte hun og dra på et skattekontoret for å få skattekort. Dette måtte gjøres ved personlig frammøte fordi det var behov for ID sjekk. Hun hadde lastet ned et Wordbasert skjema fra skatteetaten og fylt det ut. Beskrive punktvis hva hun gjorde videre etter autorisasjon som lege og mottatt skattekort. 1. Opprette brukerkonto på UDI sin hjemmeside 2. Søke om registreringsbevis ved hjelp av UDI sin hjemmeside 3. Møte opp hos SUA i politi skranken med pass ansettelsesbevis. 4. Melde flytting til den nye leiligheten til folkeregisteret. Dette gjøres ved å printe ut en PDF og fylle ut dette for hånd og sende det med Posten til folkeregisteret. 5. Opprette brukerkonto for mann og barn på UDIs hjemmeside. Søke om registreringsbevis. 6. Hele familien møter opp hos SUA med pass for registrering og ID sjekk hos Politiet. 7. Kontakte skoleetaten i Oslo for innmelding av barna i skolen. Der fikk de beskjed om å Kostnad ved innførsel av familiebil Beløp ta kontakt med nærmeste nærskole. MVA for bruktbil inn til Norge Innførsel av bil til Norge Engangsavgift Avgifter tilsammen i Norge Refusjon av MVA i Hellas Totale kostnader for Legen

10 Utfordringer med dagens løsning Utfordringen med dagens prosess for å kunne etablere seg i Norge som arbeidstaker med familie, er at servicetilbudet fra det offentlig bærer preg av fragmenterte prosesser med delvis manuell saksbehandling som gjør at man i prinsippet må søke om mange ting til ulike etater med de samme opplysningene og de samme dokumentene. UDI sin søkeportal håndterer kun registrering av EØS borgere, uten å gi veiledning og muligheter for andre søknader og registreringer som det er naturlig at arbeidsinnvandrere fra EØS har behov for. Det er også såpass lang ventetid i Oslo slik at man i praksis må gjøre ID sjekk og få skattekort med D-nummer før man får time for registrering hos SUA. Alle EU borgere som skal være i Norge mer enn 3 måneder må registrere seg i bestillingsportalen til UDI for å søke om registreringskort og bestille time hos politiet, har ingen veiledning for flytting til Norge (hva kan man ha med på flyttelasset), regler for å ta med bil, hvordan man ordner med barn i skole, rettigheter og plikter for skolebarn, melding om flytting og påmelding til norskkurs. Applikasjonene bærer også preg av dette. Svært mye baserer seg på enkeltstående PDF løsninger som er beregnet til å skrive ut på papir hvor man må delvis fyller ut for hånd og signerer. Saksbehandlerne mottar derfor mye informasjon på skannede dokumenter eller på papir som kunne ha vært på maskinlesbart format.

11 De offentlige virksomhetene Offentlige virksomheter mangler oversikt over andre virksomheters tjenester og hvilke prosesser de blir benyttet i. Har heller ikke tegnet og tilgjengeliggjort egne Offentlige virksomheter har noen ganger tilpasset tjenestene feil brukergruppe Mangler samarbeidsavtaler og avtaler om tjenestekvalitet Har lite forståelse for felles informasjonsforvaltning Fokus på egen saksbehandling fremfor brukers situasjon Tjenestene har forbedret seg betraktelig Direktoratet for forvaltning og IKT

12 Løsningsskisse Det er to ting en arbeidsinnvandrer har behov for temmelig umiddelbart når de kommer til Norge. Det ene er skattekort og det andre er lønnskonto med tilhørende bankkort. Med denne løsningen vil vår greske lege kunne gjøre følgende når hun kommer til Norge (hun er på forhånd autorisert som lege av SAK). 1: Undertegne arbeidsavtale 2: Ta med arbeidsavtale, pass og EU-ID kort til en avtalt bankfilial 3: Få personnummer, opprette lønnskonto, få bankkort og elektronisk bank ID 4: Fra PCen hjemmefra eller eventuelt mobiltelefon kan hun logge seg på «NY i Norge» hvor hun kan søke om skattekort (altinn) registrere opphold i Norge, søke om kjøretillatelse for bil med utenlandske skilter i 2 år (altinn), bestille strøm, søke om skoleplass for barna, betale regninger, melde flytting. Med andre ord, gjøre alle de tingene som norske borgere kan gjøre på nettet uten å måtte gå fysisk fra kontor til kontor for få utført for det meste ganske trivielle ting. Når resten av familien ankommer, så kan man følge samme prosedyre. Hele familien går til banken, får personnummer og BankID, eventuelt gå til et skattekontor og få personnummer og Min ID. Dermed så kan man melde flytting, registrere opphold og bekrefte innmelding i skolen.

13 Overordnet rammeverk for interoperabilitet i EU

14 Konseptuell modell for offentlige tjenester (EU-kommunikasjonen)

15 Forslag til arkitektur for ønsket situasjon (innvandring)

16 Tjenesteorientert arkitektur (SOA) Fra et teknisk perspektiv er det sentralt at den tjenesteorienterte arkitekturen ivaretar: Løs kobling Integrasjon mellom systemer skjer kun gjennom grensesnitt og skjemaer, og ikke deling av implementering. Gjenbruk - Etablerte tjenester skal kunne gjenbrukes i nye systemer og sammenhenger. Interoperabilitet og teknologiuavhengighet Bruk av tjenester skal ikke være begrenset til spesifikke implementeringer eller teknologier. Endringsevne og fleksibilitet Tjenester og prosesser skal kunne endres og rekomponeres for å ivareta virksomhetens skiftende behov. I en tjenesteorientert arkitektur er det naturlig å håndtere to konsepter, tjenester og hendelser. I noe litteratur vil hendelser være beskrevet som en egen arkitekturstil (Eventdriven Architecture EDA). En tjeneste beskrives som en forespørsel fra en klient om å få noe utført, eller tilgang til informasjon som er kontrollert av tjenesten. Tjenesten responderer på denne forespørselen, i forhold til klientens autorisasjon og tjenestens forretningslogikk. I arkitekturen vil hver tjeneste eller tjenesteområde i tillegg gjerne ha flere definerte hendelser som de kan respondere på. For hver av disse hendelsene kan det potensielt være ett eller flere systemer eller tjenester som skal respondere på hendelsen. Til behandling av tilstand og logikk i såkalte orkestreringsprosesser har man utviklet standarden BPEL (Business Process Execution Language). BPEL muliggjør orkestrering, det vil si å sette sammen tjenester til mer sammensatte tjenester, som da kan leve over lengre tid. En BPEL prosess kan vare lenge og huske sin tilstand. Det er mulig at prosessen dehydrerer (lagres på disk) for så å våkne ved en hendelse som vekker opp prosessen igjen. Alternativt workflow.

17 Webservice Uttrykket «Web Services» kan være forvirrende. Det er dessverre benyttet på mange forskjellige måter. Det som kan skape ytterligere forvirring, er bruken av termen «services» som ofte har en annen betydning ellers enn i begrepet «Web Services». Begrepet «Web Services» refererer til de teknologier som gir mulighet for å lage forbindelser. Services her er det du kobler sammen ved hjelp av Web Services. En service er i endepunktet til en forbindelse. Dessuten har en «service» en eller annen slags form for underliggende datasystem som støtter tilkoblingen som tilbys. Kombinasjonen av interne og eksterne «services» (tjenester) hos en organisasjon, utgjør en «service oriented» (tjenesteorientert) arkitektur. En web service er definert av W3C som et software system som er designet for å støtte maskin til maskin interaksjon/kommunikasjon over et nettverk. En web service er en protokoll for utveksling av XML-baserte meldinger i et datanettverk. SOAP (Opprinnelig var navnet en forkortelse for Simple Object Access Protocol, senere Service Oriented Architecture Protocol) danner grunnlaget for en webservice. HTTP/HTTPS for å overføre meldinger. Web servicer blir ofte brukt av offentlige etater som Nav, apotek, kommuner, sykehus og mange andre. En webservice (ebxml spørring) som er svært mye brukt, er en spørring om personen har fritak for egenandel (harborgeregenandelfritak) som går fra et apotek til Nav når en person henter medisin på e-resept på et apotek. Dette er en spørring som kommer fra så å si alle landets apotek flere ganger i sekundet på dagtid og hvor svarene blir gitt på under ett sekund. En web service muliggjør kommunikasjon ved hjelp av en kombinasjon av åpne protokoller og standarder, hovedsakelig XML, SOAP og WSDL. En web service bruker XML til å beskrive data, SOAP å overføre en melding og endelig WSDL for å beskrive tilgjengeligheten av tjeneste.

18 XML XML (Extensible Markup Language) er et universelt og utvidbart markeringsspråk. XML er et verktøy for deling av strukturerte data mellom informasjonssystemer, særlig over internett. XML brukes imidlertid også til koding av dokumenter og som kommunikasjonsmiddel mellom ulike informasjonssystemer og dataformater. Filformatet.xml organiserer data i en hierarkisk struktur. Formatet er et vanlig tekstformat, leselig for mennesker, der merker, eller tagger, gir informasjon om hva innholdet er. Spesifikasjonen av XML, som gis ut av W3C, fastsetter et metaspråk som andre språk kan defineres ut fra. De eksakte kravene til et konkret språk som bygger på XML fastsettes av en DTD eller et XML-skjema (XSD). XML er en helt sentral byggekloss for Web Service og brukes både til å definere meldinger for meldingsutveksling og spørringer og til beskrivelse av tjenester med tilhørende regler. Sett ut fra XML meldingene, enten det er spørringer eller svar, så fungerer Webservice elementene som en protokoll for utveksling av data. Behovet for standardisering av disse meldingene er derfor det samme som ved utveksling av XML meldinger med andre tradisjonelle protokoller (eks. SMTP, FTP, ebxml, AS2)

19 SOAP SOAP står for Service Oriented Application Protocol (tidligere Simple Object Access Protocol). SOAP blir benyttet i flere sammenheng, men i en standard web service kontekst, danner SOAP fundamentet i en web service protokollstakk som i sin tur danner grunnlaget i et meldings rammeverk for web services. Denne XML - basert protokollen består av tre deler: En konvolutt som definerer meldingsstrukturen og hvordan den skal behandles Et sett med kode regler for å utrykke applikasjons-definerte datatyper En konvensjon for å representere prosedyrekall og responser SOAP med vedlegg W3C har foreslått en metode for å knytte SOAP-meldinger sammen med innhold som har annet format enn XML, innkapslet som vedlegg etter MIME-standarden. Denne løsningen anbefales blant annet for ebxml og av WS-I.

20 WSDL Web Services Description Language (WSDL) er en XML basert språk for grensesnitt spesifikasjoner som benyttes til å beskrive egenskaper og funksjonalitet som en bestemt webservice tilbyr. The Web Service Description Language er utviklet av W3C og har to hoved releaser: WSDL 1.1, mars 2001 WSDL 2.0, juni 2007 En WSDL fil refererer til en maskinlesbar beskrivelse av hvordan en web service kan bli kalt, hvilke parametere som forventes og hvilke datastrukturer den returnerer. Mange sammenligner dette som noe som tilsvarer remote procedure call (RFC1050) fra en Client- Server arkitektur i et Linux/Unix miljø. I WSDL versjon 2.0 ble betydningen av forkortelsen endret i forhold til versjon 1.1 hvor D sto for «Definition». WSDL kan betraktes som en XML dialekt som er utviklet for å kunne beskriver nettverkstjenester ved hjelp av en samling kommunikasjonsendepunkt. Endepunktene er i stand til å utveksle meldinger. Diagrammet under illustrerer elementene som et WSDL dokument inneholder og deres innbyrdes relasjoner til hverandre.

21 WSDL versjon 1.1 og 2.0 Et WSDL 1.1 dokument har et Definisjonselement som inneholder de andre 5 elementene: Types inneholder datatype definisjoner ved hjelp av en kjent syntaks (f. eks XSD). Message en abstrakt, definisjon av data som skal kommuniseres. Operation en abstrakt beskrivelse av aktiviteter som støttes av tjenesten. Port Type et abstrakt endelig antall av operasjoner som er støttet av en eller flere endepunkt. Binding en konkret protokoll og et dataformat spesifikasjon for en bestemt port type. Port ett enkelt endepunkt som er definert ved hjelp av en kombinasjon av en binding og en nettverksadresse Service en samling av relaterte endepunkter

22 WSDL versjon 1.1 og 2.0 Et WSDL 1.1 dokument har et Definisjonselement som inneholder de andre 5 elementene: Types inneholder datatype definisjoner ved hjelp av en kjent syntaks (f. eks XSD). Message en abstrakt, definisjon av data som skal kommuniseres. Operation en abstrakt beskrivelse av aktiviteter som støttes av tjenesten. Port Type et abstrakt endelig antall av operasjoner som er støttet av en eller flere endepunkt. Binding en konkret protokoll og et dataformat spesifikasjon for en bestemt port type. Port ett enkelt endepunkt som er definert ved hjelp av en kombinasjon av en binding og en nettverksadresse Service en samling av relaterte endepunkter Definisjonselementet benytter navnerom (Namespace). WSDL 1.1 skiller mellom 4 ulike mønstre for meldingsutveksling ved hjelp av porttype elementet: One-way - en melding fra tjenestebruker til tjenesteleverandør. Request-response spørsmål og svar initiert av tjenestebruker. Solicit-response - spørsmål og svar initiert av tjenesteleverandør. Notification - en melding fra tjenesteleverandør til tjenestebruker.

23 WSDL versjon 1.1 og 2.0 Et WSDL 2.0 dokument har et beskrivelselement (description) som inneholder de andre 5 obligatoriske elementene: Types inneholder datatype definisjoner ved hjelp av en kjent syntaks (f. eks XSD). Interface dette elementet beskriver virksomheten tilgjengelig på web-tjeneste og hvilke meldinger som skal utveksles mellom produsent og konsument for hver operasjon (forespørsel / respons). Dette elementet er også benyttet til å beskrive mulige feilmeldinger. Operation en abstrakt beskrivelse av aktiviteter som støttes av tjenesten. Binding en konkret protokoll og et meldingsformat for en «interface». Alle «operations» og «fault» må ha disse detaljene i en «interface» Service en samling av relaterte endepunkter som angir hvor tjenesten kan aksesseres. Hvert endepunkt henviser til en tidligere definert binding og som indikerer protokollen og formatet som skal benyttes på endepunktet. I tillegg kan de valgfrie elementene «Documentation» og «Import» benyttes. WSDL 2.0 definerer i alt åtte standardmønstre ved hjelp av Interface elementet og man kan selv definere egne utvidelser: In-only, In-out, Out-In og Out-Only tilsvarer de fire typene fra version 1.1. In-Optional-Out og Out-Optional-In hvor svar er valgfritt. Robust In-Only og Robust Out-Only hvor mottaker sender feilmelding hvis opprinnelig melding går tapt.

24 WSDL versjon 1.1 og 2.0 Som man ser av figuren over så er endringene fra versjon 1.1 til 2.0 gjort på en slik måte at det ikke er bakover kompatible. Navnet på rot elementene (rot taggene) er endret fra «Definition» til «Description» og elementet «Porttype» er endret til «Interface» og «Port» under «Service» er endret til «Endpoint». Flere leverandører (bla Microsoft) støtter bare versjon 1.1, mens mange andre har satset på versjon 2.0. Dette gjør at det i praksis bli krav til at en offentlig web service tjeneste i mange tilfeller må støtte begge versjonene. Begge hovedversjonene av WSDL deler tjenestebeskrivelsen inn i en abstrakt og en konkret del. Den abstrakte beskriver grensesnittets datatyper, operasjoner og meldinger, mens den konkrete definerer implementeringen av tjenestene, med binding til kommunikasjonsprotokoller og adressene (URI) til der tjenesten er installert.

25 UDDI Universal Description, Discovery and Integration (UDDI), er en plattformuavhengig XML basert protokoll med en XML basert register hvor virksomheter (tjeneste produsenter) kan registrere sine tjenester på internett. UDDI er et åpent industri initiativ støttet av Organization for the Advancement of Structured Information Standards (OASIS). UDDI er den sentrale standarden for kataloger som gir brukere tilgang til tjenestebeskrivelser i WSDL og informasjon om virksomhetene som tilbyr dem. Grensesnittet til UDDI er definert gjennom standardiserte web services. Versjon 1 etablerte grunnleggende funksjonalitet, mens versjon 2 oppdaterte til nye standarder for web services og innførte metoder for klassifisering av tjenester. Versjon 3 legger til sikker interaksjon mellom åpne samhandlingsløsninger og lukket intern implementasjon av tjenester. UDDI var opprinnelig foreslått som en av de tre grunnpilarene i standard Webservice ved siden av WSDL og SOAP, men er helt klart den minst brukte av de tre. IBM, Microsoft og SAP mfl har lagt ned sine offentlige UDDI tjenester.

26 Web Service profiler Web Services Interoperability Organization (WS-I) er en industriorganisasjon som betrakter seg som en bindeledd mellom utviklere av standarder og brukere av dem (Best Practices). De startet som en frittstående gruppe, men i juli 2010 ble det besluttet at gruppen skulle legges under OASIS. WS-I definerer profiler som består av en gruppe sammenhørende standarder pluss retningslinjer for hvordan man bør bruke dem sammen. Ved siden av profilene publiseres eksempler på anvendelser, og testverktøy for å sjekke om en implementasjon er i tråd med spesifikasjonene. Profilene definerer også mekanismer som leverandører av web service verktøy har muligheter for å utrykke støtte til WS-I profiler i WSDL-beskrivelsene til tjenester. Basisprofilen har utviklet seg slik: Versjon 1.0 (offentlig 2002, godkjent 2004) bruker WSDL1.1, UDDI 2, SOAP 1.1, http 1.1, XML 1.0 (2. utgave), og XML Schema 1.0. Sikkerhetsmekanismer er ikke obligatoriske, men retningslinjer for bruk av sikkerhetsstandardene TLS/SSL og X.509 er inkludert. Versjon 1.1 (godkjent 2006) skiller ut detaljer om binding til SOAP i en egen profil kalt Simple SOAP Binding Profile (SSBP). Attachments Profile 1.0 bygger på 1.1, og definerer hvordan man bør lage webtjenester som håndterer vedlegg meldingene i andre format enn XML. Versjon 1.2 (klar til styrets godkjenning) Versjon 2.0 (utkast fra arbeidsgruppe) går over til SOAP 1.2

27 Rest REST (Representational State Transfer) er en arkitekturstil for fleksible og skalerbare distribuerte systemer. World wide web er utformet i tråd med denne stilen. Prinsippene i REST kan implementeres som webtjenester, men også i andre omgivelser. REST krever et klart skille mellom klient og tjener, i en lagdelt arkitektur, med et uniformt utformet grensesnitt mellom lagene, tilstandsløs kommunikasjon hvor klient og tjener ikke kjenner hverandres kontekst og meldingene inneholder alt den andre parten trenger å vite. Tilstandsløs kommunikasjon sørger også for at svarmeldinger kan lagres lokalt på klienten og gjenbrukes, siden to like forespørsler alltid vil gi samme svar. Det uniforme grensesnittet i REST baserer seg på identifikasjon av den ressursen man vil gjøre noe med. En ressurs oppdateres direkte i representasjonen av den, slik at en klient f.eks. kan legge inn nye verdier i et XMLdokument, og sende det tilbake til tjeneren for oppdatering. Andre operasjoner gjøres gjennom å sende selvbeskrivende og gjerne standardiserte meldinger til en ressurs. I http kan man f.eks. sende meldingene POST, GET, PUT, DELETE til en ressurs identifisert av en URI. Disse meldingene tilsvarer basisoperasjonene i de fleste REST-løsninger: CRUD (Create, Read, Update, Delete). Mens web service har sin rot i programmeringsgrensesnitt for å sy sammen applikasjonskomponenter, er REST mer utviklet for kommunikasjon mellom klient og tjener, eller brukergrensesnitt og applikasjon. En arkitektur som definerer en mindre mengde meldinger som kan sendes til de aller fleste ressurser, forenkler dessuten adgangskontroll og komposisjon av tjenester. Ved siden av brukerinteraksjon er REST egnet for å gi et uniformt grensesnitt til tjenester som gjør registre og grunndata tilgjengelige for andre virksomheter. REST er ingen egen familie av standarder, men Sun har sendt et forslag til W3C på et Web Application Description Language (WADL) som angir en standard måte å representere ressurser i XML. For interaksjon i tråd med REST mellom brukergrensesnitt og applikasjon, brukes gjerne JSON (Javascript Object Notation) til å representere ressursene. Som nevnt over gir WSDL 2.0 bedre støtte for REST enn versjon 1.1, og flere standarder er basert på disse prinsippene, som WS-ResourceTransfer og WS-Distributed Management. I web service sammenheng er REST interessant hvis man kan benytte XML basert REST til for eksempel enkle standard spørringer i offentlige registre fra web klient applikasjoner.

28 Forslag til offentlig web service profil WS-I sin basis profil støttes allerede av en rekke grupperinger i Norge (f. eks helsesektoren), og bør derfor ligge som en grunnleggende profil for bruk av Webservice i det offentlige i den forstand at hvis ikke noe annet er spesifisert så gjelder WS-I versjon 1.2. Versjon 2.0 støtter bare de siste versjonene av WSDL og SOAP etc. Versjon 2.0 må derfor ligge til observasjon for de mange av leverandørene av WS verktøy bare støtter tidligere versjoner. Følgende Web Service standarder foreslås som obligatorisk basis i referanse katalogen: XML XML versjon 1.0 skal benyttes. XML er en helt sentral byggekloss for Web Service og skal benyttes både til å definere meldinger for meldingsutveksling og spørringer og til beskrivelse av tjenester med tilhørende regler. De faktiske XML meldingstypene som utveksles ved hjelp av web service bør standardiseres på samme måte som meldinger som blir benyttet i mer tradisjonell asynkron EDI basert samhandling. WSDL Både versjon 1.1 og 2.0 må støttes som likestilte, dette fordi flere leverandører bare støtter versjon 1.1. Hvordan dette skal gjøres i praksis må utredes. XML Namespaces Bare versjon 1.0 skal benyttes

29 Forslag til offentlig web service profil fortsettes XML Namespaces Bare versjon 1.0 skal benyttes XML Schema (XSD) Versjon 1.0 skal benyttes for definisjon av XML. NB! XML Document Type Definition (DTD) skal ikke benyttes. SOAP Versjon 1.1 skal benyttes, mulig versjon 1.2 også kan benyttes dette må vurderes. SOAP With Attachments SOAP With Attachments (SWA) Profile 1.1 skal benyttes. Dette må sees i sammenheng med sikkerhetsprofilen med krypterte meldinger som vedlegg. Hvor man benytter samme teknikk for å pakke inn en kryptert XML melding som en komprimert melding eller en melding på et annet format en XML. WS-Addressing WS-Addressing versjon 1.0 skal følges. http som transportprotokoll Web Service skal benytte http 1.1 som transportprotokoll. Denne versjonen er allerede fastsatt i referansekatalogen. Sikkerhet Standard PKI for kryptering og signering skal benyttes når det kreves strengere sikkerhet en bare https. En kryptert melding må legges som et vedlegg som ifølge SWA Profile 1.1 For øvrig vises det til WS-I Basic Security Profile Version 1.0, ID-porten, edi UDDI Blir ikke foreslått som en obligatorisk standard, men kan danne grunnlaget for en løsningsspesifikasjon for en felleskomponent for tjenestekataloger (Web Service katalog) for det offentlige. Intern bruk av UDDI anbefales.

30