Kartlegging av mulige standarder for tjenesteorientert arkitektur ... - Difi

Kartlegging av mulige 

standarder for tjenesteorientert 

arkitektur i offentlig sektor 

Forprosjektrapport 

På oppdrag for 

Lysaker, 20. januar 2010 

Versjon 1.1

DIFI 

Utredning av tjenesteorientert arkitektur i offentlig sektor 

Forord 

Rapporten er utarbeidet av Commitment AS på oppdrag av Direktoratet for forvaltning og IKT 

(Difi). Difi er sekretariat for standardiseringsrådet, og skal legge fram for rådet forslag til 

standarder som rådet skal vurdere. 

Hensikten med rapporten er å vise bredden i mulige standarder innen området 

tjenesteorientert arkitektur. Rapporten er et utgangspunkt for hvilke standarder Difi skal 

anbefale standardiseringsrådet å vurdere nærmere, for eventuelt senere å inkludere dem i 

referansekatalogen for IT-standarder i offentlig sektor. Anbefalingene i rapporten er forslag til 

hvilke standarder som bør vurderes nærmere, og ikke en endelig anbefaling om hvilke 

standarder som skal inn i referansekatalogen. 

Oppgavene med å anbefale aktuelle standarder er første steg i standardiseringsrådets arbeid. 

Senere vil mulige standarder bli vurdert i henhold til standardiseringsrådets kriterier, og 

knyttet til mulige anvendelsesområder i offentlig sektor. Standarder kan være egnet på noen 

områder, mens de er mindre egnet for andre anvendelsesområder. 

Vi ønsker en åpen prosess rundt dette, og ber om tilbakemeldinger på anbefalingene i 

rapporten. Basert på anbefalingene i rapporten, og tilbakemeldinger som kommer, vil Difi i 

samråd med en arbeidsgruppe utarbeide en anbefaling til standardiseringsrådet om hvilke 

standarder rådet skal utrede videre. 

Rapporten prøver å spenne vidt, men det kan være standarder som ikke er omfattet. 

Rapporten fokuserer på tekniske standarder og har avgrenset mot prosesstandarder. 

Kommentarer til rapporten og forslag til standarder og områder som bør vurderes kan gis på 

standardiseringssekretariatets hjemmesider. 

Det arbeides også med to tilhørende notater som vil gi innspill til terminologi på området og en 

oversikt over referansemodeller som ofte blir brukt. Disse er ikke klare ennå. Vi ber leserne 

om ikke å henge seg opp i begrepsbruken i rapporten. Området tjenesteorientert arkitektur er 

preget av ulik begrepsbruk, og vi håper at dere leser rapporten med et åpent sinn. Rapporten 

skal være et utgangspunkt for en diskusjon om standarder, ikke begreper. 

Difi, januar 2010 

20.01.2010 Versjon 1.1 2/89

DIFI 


Innhold 

1 Sammendrag ......................................................................................................... 6 

1.1 Anbefaling av standarder ............................................................................... 6 

1.2 Andre anbefalinger ........................................................................................ 6 

2 Innledning ............................................................................................................. 8 

2.1 Bakgrunn ..................................................................................................... 8 

2.2 Målsetninger................................................................................................. 8 

2.3 Avgrensning ................................................................................................. 9 

2.4 Viktige begreper ........................................................................................... 9 

2.5 Rapportens struktur ...................................................................................... 9 

3 Anvendelse av metoder og standarder i ulike scenarioer ............................................. 10 

3.1 Scenario: Informasjonsutveksling mellom enheter i offentlig sektor .................... 11 

3.1.1 Tekniske løsninger ...................................................................................... 12 

3.1.2 Standarder for meldingsutveksling ................................................................ 12 

3.1.3 Standarder for sikkerhet .............................................................................. 13 

3.1.4 Løsninger for kommunikasjon ...................................................................... 13 

3.1.5 Løsninger for store datamengder .................................................................. 14 

3.1.6 Dataformater ............................................................................................. 15 

3.1.7 Tjenestekataloger ....................................................................................... 15 

3.2 Scenario: Tilgjengeliggjøring av registerdata ................................................... 16 


3.2.2 Løsninger for søk ........................................................................................ 18 

3.2.3 Løsninger for semantisk interoperabilitet ....................................................... 18 

3.3 Scenario: Saksbehandling ............................................................................. 18 

3.3.1 Krav til interaksjon med tjenestebrukere ....................................................... 19 


3.3.3 Prosessmotor og regelmotor ........................................................................ 20 

3.3.4 Interoperabilitet mellom fagsystem ............................................................... 21 

3.3.5 Arkivering .................................................................................................. 21 

3.3.6 Kontakt med bruker .................................................................................... 21 

3.3.7 Interaksjon mellom brukergrensesnitt og prosess ........................................... 22 

3.4 Scenario: Innrapportering til det offentlige ...................................................... 22 


3.4.2 Løsninger for skalerbarhet ........................................................................... 23 

3.4.3 Løsninger for prosess, koordinering og fordeling ............................................. 23 

3.4.4 Løsninger for dataoverføring ........................................................................ 23 

4 Metoder og standarder for tjenesteorientert arkitektur ............................................... 25 

4.1 Arkitekturmessige betraktninger på bruksscenarioene ...................................... 27 

4.2 Metoder og standarder for tjenestelaget ......................................................... 28 

4.2.1 Web services – WSDL .................................................................................. 29 

4.2.2 Modularisering av tjenester og data .............................................................. 30 

4.2.3 Versjonsstyring av tjenester og dataformat .................................................... 30 

4.2.4 Standarder tilknyttet WSDL ......................................................................... 31 

4.2.5 Profiler for webtjenester .............................................................................. 31 

4.2.6 REST ......................................................................................................... 32 

4.2.7 ebXML for eHandel ...................................................................................... 32 

4.2.8 RosettaNet ................................................................................................. 34 

4.2.9 Semantiske tjenestebeskrivelser ................................................................... 35 

4.3 Mellomvare ................................................................................................. 35 

4.3.1 Ulike typer mellomvare ............................................................................... 36 

4.3.2 Beskrivelse og oppdagelse av tjenester ......................................................... 37 

4.3.3 Teknisk styring og drift av tjenester .............................................................. 38 

4.4 Kommunikasjon ........................................................................................... 40 

4.4.1 Metoder for meldingsutveksling .................................................................... 40 

4.4.2 Standarder for direkte kall til tjenester .......................................................... 41 

4.4.3 Hendelser og notifikasjon ............................................................................ 42 

20.01.2010 Versjon 1.1 3/89

DIFI 


4.4.4 WS-Addressing - ruting og adressering av tjenester ........................................ 43 

4.5 Data og informasjon ..................................................................................... 43 

4.5.1 Nivåer for dataintegrasjon ........................................................................... 43 

4.5.2 Profiler for informasjonsutveksling ................................................................ 44 

4.5.3 XML .......................................................................................................... 45 

4.5.4 ebXML Core Components ............................................................................. 46 

4.5.5 Innholdsstandarder ..................................................................................... 47 

4.5.6 Andre tekstlige formater .............................................................................. 47 

4.5.7 Binær XML ................................................................................................. 48 

4.5.8 WS-Enumeration - Tjenesteorientert tilgang til sammensatte data .................... 48 

4.5.9 Databaseintegrasjon ................................................................................... 48 

4.6 Portaler, interaksjon og presentasjon ............................................................. 49 

4.6.1 Kanaler ..................................................................................................... 49 

4.6.2 HTML ........................................................................................................ 50 

4.6.3 Tilgjengelighet for alle ................................................................................. 50 

4.6.4 ELMER ....................................................................................................... 50 

4.6.5 WSRP – Web Services for Remote Portlets ..................................................... 51 

4.6.6 AJAX ......................................................................................................... 51 

4.6.7 W3C Webapps ............................................................................................ 51 

4.6.8 Interaktivt multimedia og rike grensesnitt ..................................................... 52 

4.7 Samhandling, prosesser og komposisjon av tjenester ....................................... 52 

4.7.1 BPEL ......................................................................................................... 53 

4.7.2 WS-CDL .................................................................................................... 53 

4.7.3 ebXML BPSS .............................................................................................. 54 

4.7.4 WS-CAF – Composite Applications Framework ................................................ 54 

4.7.5 WS-Transactions ........................................................................................ 54 

4.7.6 Overvåking og styring av prosesser .............................................................. 54 

4.7.7 Business Centric Methodology (BCM) og Content Assembly Mechanism (CAM) .... 54 

4.7.8 Andre standarder ........................................................................................ 55 

4.8 Sikkerhet og pålitelighet ............................................................................... 55 

4.8.1 eID og ID-porten ........................................................................................ 55 

4.8.2 SAML ........................................................................................................ 56 

4.8.3 XACML ...................................................................................................... 56 

4.8.4 WS-Security ............................................................................................... 57 

4.8.5 XML kryptering og signering ......................................................................... 58 

4.8.6 Åpne industristandarder for autentisering og autorisasjon ................................ 59 

4.8.7 Pålitelig meldingsutveksling ......................................................................... 59 

4.8.8 ISO/IEC 27000 ........................................................................................... 59 

4.9 Avhengigheter mellom standarder .................................................................. 60 

4.10 Modellering av tjenester ................................................................................ 60 

4.10.1 Prosesser og sammenstilling av tjenester .................................................. 60 

4.10.2 Modelldrevet utvikling av tjenester ........................................................... 62 

4.10.3 Modellering av regler .............................................................................. 64 

4.10.4 Virksomhetsarkitektur for forvaltning av tjenester ...................................... 64 

5 Råd for videre arbeid .............................................................................................. 69 

5.1 Basis standarder som trolig bør anbefales ....................................................... 69 

5.2 Andre standarder som kan anbefales .............................................................. 71 

5.3 Standarder som kan vurderes seinere ............................................................. 72 

5.4 Områder for videre kartlegging ...................................................................... 72 

5.4.1 Forvaltning og drift av tjenester ................................................................... 73 

5.4.2 Tjenester i skyen ........................................................................................ 73 

5.4.3 Pragmatisk semantikk ................................................................................. 73 

5.4.4 Virksomhetsarkitektur ................................................................................. 73 

5.4.5 Modelldrevne applikasjoner .......................................................................... 75 

Vedlegg A. Referanser ............................................................................................... 76 

Vedlegg B. Forkortelser.............................................................................................. 83 

20.01.2010 Versjon 1.1 4/89

DIFI 


Figurer 

Figur 1. Bruksområder for tjenesteorientert arkitektur ..................................................... 10 

Figur 2. Scenarioer for tjenesteorientert arkitektur .......................................................... 10 

Figur 3. Offentlig tjenesteyting før tjenesteorientert arkitektur. ......................................... 25 

Figur 4. Første generasjon tjenesteorientert arkitektur. .................................................... 26 

Figur 5. Andre generasjon tjenesteorientert arkitektur. .................................................... 26 

Figur 6. Komponenter i tjenesteorientert arkitektur. ........................................................ 27 

Figur 7. Ulike løsninger for tilgjengeliggjøring av registerdata. .......................................... 28 

Figur 8. Oversikt over standarder for webtjenester. ......................................................... 31 

Figur 9. Interoperabilitet på ulike nivåer. ........................................................................ 43 

Figur 10. Arkitektur for dynamiske brukergrensesnitt for webtjenester [168]. ..................... 52 

Figur 11. Avhengigheter mellom standarder for webtjenester............................................ 60 

Figur 12. Bruk av virksomhetsarkitektur. ........................................................................ 65 

Figur 13. Hovedbegreper i TOGAF [132]. ........................................................................ 66 

Figur 14. Ulike nivåer av virksomhetsarkitektur i offentlig sektor [37]. ............................... 74 

20.01.2010 Versjon 1.1 5/89

DIFI 


1 Sammendrag 

Denne rapporten er en kartlegging av mulige standarder for tjenesteorientert arkitektur i 

offentlig sektor. Hovedmålet er å peke på standarder som på sikt kan gjøres til 

forvaltningsstandarder [32]. Rapporten er et første innspill til den videre standardiseringsprosessen, 

hvor mer detaljerte analyser blir foretatt. Her er relevante standarder identifisert 

og vi peker på hvor de kan anvendes. 

I analysen har vi fokusert på fire bruksscenarioer for tjenesteorientert arkitektur i offentlig 

sektor: Informasjonsutveksling mellom virksomheter, tilgjengeliggjøring av registre, 

saksbehandling og innrapportering. 

Tilgjengelige standarder innen tjenesteorientert arkitektur varierer sterkt i forhold til 

utbredelse, formell godkjenning, modenhet, stabilitet, enkelhet og kompleksitet. Ofte finnes 

det flere standarder som dekker overlappende funksjonalitet, og noen standarder brukes i 

ulike versjoner parallelt. 

1.1 Anbefaling av standarder 

Kapittel 5 oppsummerer basis standarder som bør anbefales, andre standarder som kan 

anbefales, og standarder som ikke er modne for anbefaling, men som bør overvåkes videre. 

De viktigste standardene som bør anbefales, og som danner grunnlaget for tjenesteorientert 

arkitektur, er i første rekke: 

WSDL for beskrivelse av tjenester, 

SOAP, SOAP with Attachments for kommunikasjon med tjenester, 

XML, XML Schema, XML Namespaces for dataene som tjenester utveksler, 

WS-Adressing for identifikasjon og beskrivelse av endepunktene hvor tjenester er 

tilgjengelige. 

Dette er i tråd med anbefalinger fra WS-I, KITH, og OIO [58, 70, 209], i deres profiler av 

standarder for webtjenester. Disse profilene beskriver hvordan en samling standarder bør 

brukes sammen, mer presist og detaljert. En norsk standard profil for webtjenester bør trolig 

defineres. 

Sikkerhetsstandarder knyttet til WS-Security, med SAML, WS-SecurityPolicy, WS-Policy, XML 

Encryption og XML Signatures bør også anbefales. Dette må samordnes med eID og ID-porten. 

Gruppen av standarder som man i tillegg bør vurdere på kort sikt, dekker kommunikasjon 

(MTOM, XOP, XMPP, JSON), tjenestekataloger (UDDI), sikkerhet og pålitelighet (WS- 

SecureConversation, WS-Trust, WS-ReliableMessaging, XACML, XKMS), sammenstilling av 

tjenester til løsninger (WS-Transaction, WS-BPEL), brukergrensesnitt (XForms, Ecmascript, 

DOM) og dataprosessering (XSLT, XPath, XQuery). 

1.2 Andre anbefalinger 

Referansekatalogen for standarder [32] skal først og fremst sørge for interoperabilitet mellom 

IKT-løsninger i offentlig sektor, for allmenn tilgjengelighet til elektroniske tjenester, og sikre 

åpen konkurranse mellom leverandører av IKT. 

Referansekatalogen inneholder i dag for det meste ”skal”-krav knyttet til bruk av standarder, 

og bare unntaksvis anbefalinger i form av ”bør”-krav. For tjenesteorientert arkitektur kan det 

være hensiktsmessig med flere anbefalinger, gjerne knyttet til en regel om ”bruk eller forklar 

hvorfor ikke” [19]. En grunn til dette er at det finnes flere ulike standarder og versjoner av 

standarder som dekker overlappende funksjonalitet, og som godt kan eksistere side om side. 

Obligatoriske standarder bør være stabile over tid, presise og entydige. Tjenesteorientert 

arkitektur er fortsatt i utvikling, og flere av de grunnleggende standardene har såpass mye 

frihet innbakt i seg at ulike verktøy implementerer dem forskjellig. For å kunne garantere 

interoperabilitet bør man derfor presisere hvordan standardene skal brukes, slik flere profiler 

gjør [187, 58, 70, 209]. 

20.01.2010 Versjon 1.1 6/89

DIFI 


Det er noen særtrekk ved tjenesteorientert arkitektur som kan påvirke vurderingen av 

kostnader og nytteverdi knyttet til standardisering: 

Løsninger for å bygge bro mellom ulike rammeverk er allment tilgjengelig, og de fleste 

leverandører tilbyr en rekke standard grensesnitt ved siden av proprietære løsninger. I 

stedet for å kreve en løsning for alle integrasjonsformer, bør man trolig skille mellom 

virksomhetsintern og –ekstern interoperabilitet. 

Lagdelte arkitekturer gir åpenhet og fleksibilitet, men kan skape problemer i forhold til 

ytelse og skalerbarhet. Ulike arkitekturer trengs dermed for ulike anvendelser. 

Flere standarder finnes i ulike versjoner, som støttes i varierende grad av ulike 

leverandører. Her kan det være en konkurransemessig fordel med valgfrihet i forhold til 

hvilke versjoner som skal benyttes. Dette gjelder f.eks. WSDL og SOAP. 

De fleste standarder for tjenesteorientert arkitektur har teknisk integrasjon som fokus, 

og tar i liten grad høyde for brukerinteraksjon og menneskelig skjønn. Dette kan 

komme i konflikt med arkitekturprinsippet om tjenesteorientering [19], og illustrerer 

viktigheten av å se på andre standarder for brukernære tjenester, grensesnitt og 

saksbehandlingsprosesser enn for lavnivå integrasjon mellom tekniske komponenter. 

Ved siden av teknisk interoperabilitet er det mange utfordringer knyttet til organisatorisk og 

semantisk interoperabilitet. De bør forfølges, men har vært utenfor fokus for denne 

utredningen: 

Felles rammeverk for forvaltning, drift og vedlikehold av tjenester, inkludert ”tjenester i 

skyen”. 

Rammeverk og mønstre for virksomhetsarkitektur beskriver i hvilken organisatorisk 

sammenheng ulike standarder og felleskomponenter skal eller bør brukes. Ved siden av 

generelle rammeverk, vil ulike sektorer ha behov for mer spesifikke 

referansearkitekturer knyttet til sitt virksomhetsområde. En metodikk for å knytte 

sammen referansearkitekturer på ulike nivå med virksomhetens egne 

arkitekturbeskrivelser vil være svært nyttig for å forbedre utnyttelsen av 

felleskomponenter. 

Referanseimplementasjoner med åpen kildekode kan legge til rette for gjenbruk, og 

dessuten brukes til å spesifisere mer presist hvordan standardene bør brukes. En 

operativ referanseimplementasjon gjør det langt enklere å teste interoperabilitet enn 

statiske spesifikasjoner. 

Felles begrepsapparat på tvers av applikasjoner, faggrupper, virksomheter innen en 

sektor og ulike sektorer. Dette er en utfordring som har sin rot på virksomhetsnivået, 

som først og fremst bør løses der, heller enn gjennom komplekse tekniske 

spesialløsninger. 

Slike tilnærminger vil øke mulighetene for å nå de operative målsetningene ved 

tjenesteorientert arkitektur, som gjenbruk, flerbruk, interoperabilitet, fleksibilitet, 

tilgjengelighet og sikkerhet. Altinn II vil være en sentral leverandør av felleskomponenter og 

tjenester. Det er derfor særdeles viktig at denne plattformen utformes i tråd med prinsipper 

for tjenesteorientert arkitektur [19]. Ved siden av tekniske krav vil etablering av åpne arenaer 

for kunnskapsutveksling mellom ressurspersoner være et nyttig tiltak, jf. digitaliser.dk. 

Beskrivelser av hvordan standarder kan implementeres i ulike verktøy, og barrierer mot 

interoperabilitet som verktøyene introduserer, vil også være en nyttig ressurs [61]. 

20.01.2010 Versjon 1.1 7/89

DIFI 


2 Innledning 

Denne rapporten er en kartlegging av metoder og standarder for tjenesteorientert arkitektur i 

offentlig sektor. Hovedmålet er å peke på standarder som på sikt kan gjøres til 

forvaltningsstandarder [32]. Rapporten: 

Beskriver scenarioer hvor tjenesteorientert arkitektur kan være nyttig i offentlig sektor, 

Identifiserer metoder og standarder og beskriver dem kort, 

Foreslår metoder og standarder som best adresserer behovene i de ulike scenarioene, 

Anbefaler standarder som kan inngå i fremtidige referansekataloger. 

Rammene har ikke tillatt en detaljert teknisk og markedsmessig analyse av de ulike 

standardene. Dette overlates til den videre bearbeidingen i Difi og standardiseringsrådet. 

2.1 Bakgrunn 

I stortingsmeldingen ”Ei forvaltning for demokrati og fellesskap” [31] presenteres sju 

arkitekturprinsipper for offentlig sektor: 

Tjenesteorientering 

Interoperabilitet 

Tilgjengelighet 

Sikkerhet 

Åpenhet 

Fleksibilitet 

Skalerbarhet 

Før dette gjorde FAOS-rapporten [37] tjenesteorientering til et grunnprinsipp for all IKTutvikling, 

og inkluderte et prinsipp om enhetlig brukerfront i tillegg til de seks andre i lista 

over. Tjenesteorientering er en tilnærming for å realisere de andre prinsippene: 

Formålet med tjenesteorientering som arkitekturprinsipp i offentlig sektor er å sikre at 

brukerne av offentlige tjenester får tilgang til tjenester og informasjon der de trenger 

det, uavhengig av offentlig sektors oppbygging eller portalstruktur. 

I denne sammenhengen betyr tjenesteorientering at IKT-løsninger som etableres skal 

være basert på en komponenttenking der det tilbys og benyttes informasjon, 

informasjonsbearbeiding eller andre IKT-tjenester gjennom et overordnet og utadrettet 

tjenestetilbud. [19] 

En tjenesteorientert IKT-arkitektur vil også påvirke organisatoriske sider ved hvordan 

forvaltningen produserer og leverer tjenester til innbyggere og næringsliv, hvordan ulike etater 

samhandler, og hvordan forvaltningen kjøper tjenester fra leverandører. De gevinster man 

søker å realisere, krever tjenesteorientert helhetstenking for best mulig utforming av 

organisasjon og IKT. Tjenesteorientering er dermed et viktig prinsipp for hele virksomheten, 

ikke bare IKT. 

2.2 Målsetninger 

Motiver for å bygge ut tjenesteorienterte arkitekturer inkluderer ofte 

Sikre at organisasjonen har kontroll på tjenestene den yter 

Økt gjenbruk av eksisterende applikasjoner 

Flerbruk for maksimal utnyttelse av eksisterende funksjonalitet i ”siloer” 

Fleksibilitet ved endringsbehov 

Bygge sammensatte applikasjoner for å levere ny verdi 

Raskere implementering 

Legge tilrette for skreddersøm 

Leveranse av IKT-tjenester over ulike kanaler 

Standardisering av prosesser 

Standardisert drift og applikasjonsforvaltning 

20.01.2010 Versjon 1.1 8/89

DIFI 


Offentlige IKT-prosjekter skal analysere om tjenester man har behov for er tilgjengelig i 

felleskomponenter eller i andre virksomheters åpne tjenesteportefølje, og om virksomhetens 

egne IKT-komponenter bør tilgjengeliggjøres for andre offentlige virksomheter som tjenester. 

Ved siden av gjenbruk av funksjonalitet står økt gjenbruk og utveksling av informasjon 

sentralt. For å realisere disse målsetningene trenger man metoder og standarder for 

beskrivelse av tjenester på teknisk nivå, men også på virksomhetsnivået, også kalt 

organisasjonsnivået. 

2.3 Avgrensning 

Denne utredningen fokuserer på teknologier for tjenesteorientert arkitektur. Metoder på 

virksomhetsnivået vil ikke bli analysert i detalj. Organisatoriske sider ved tjenesteleveranser 

og kontrakter, forretningsmodeller, definisjon av tjenestekvalitet (service level agreements) og 

kvalitetssikring av driftsorganisasjonen omhandles ikke. 

Hovedmålet er å identifisere relevante metoder og standarder. En overordnet beskrivelse av 

anvendelsesområder og grunnprinsipper for hver teknologi inngår, mens detaljerte tekniske 

analyser overlates til det seinere arbeidet. 

Semantiske teknologier er gjenstand for en annen kartlegging, og vil ikke bli beskrevet her, ei 

heller innholdsstandarder innen domener som innkjøp, transport, forsvar, helse, bygg og 

anlegg o.s.v. 

Spesifikke teknologier fra leverandører blir heller ikke vurdert, utover en overordnet 

beskrivelse av de ulike standardenes utbredelse. 

2.4 Viktige begreper 

Overordnet defineres tjeneste som ”utførelse av arbeid av en for en annen” [90], altså en 

aktivitet som en tjenesteleverandør utfører for en bruker eller kunde. Begrepet brukes både 

om virksomheter, hvor mennesker utfører tjenester, og IKT, hvor komponenter utfører 

tjenester for hverandre og brukerne. En tjeneste leveres i henhold til en kontrakt, og den er 

beskrevet i et grensesnitt slik at brukeren ikke trenger å bry seg om hvordan den er 

implementert. Dette gir en løs kobling mellom bruker og leverandør. 

Arkitektur er ”en struktur av komponenter og avhengigheter mellom dem, og prinsippene og 

retningslinjene som styrer deres utforming og utvikling over tid” [132]. Tjenesteorientering er 

et arkitekturprinsipp som kan anvendes på IKT-arkitekturen, og på hele virksomhetsarkitekturen. 

For ytterligere klargjøring av begrepene som brukes i rapporten, vises det til notatet ”Oversikt 

over begrepsbruk innen tjenesteorientert arkitektur” [14]. 

2.5 Rapportens struktur 

Kapittel 3 beskriver typiske scenarioer i offentlig sektor hvor tjenesteorientert arkitektur bør 

anvendes. Ved siden av å være representative for offentlig sektor på virksomhetsnivået, 

dekker scenarioene hovedkomponenter i en teknisk løsning. Beskrivelsene er basert på 

tidligere kartlegginger innen offentlig forvaltning. For hvert scenario analyseres det kort hvilke 

metoder som er best egnet for å lage en teknisk løsning, og hvilke standarder som er mest 

aktuelle. 

Kapittel 4 kartlegger relevante standarder innenfor ulike områder av tjenesteorientert 

arkitektur. Hovedvekten legges på tekniske standarder for tjenestelag, dataintegrasjon, 

prosesser, interaksjon, kommunikasjon, sikkerhet og andre tjenestekvaliteter. Vi beskriver 

dessuten metoder for modelldrevet utvikling av tjenesteorienterte arkitekturer, samt 

rammeverk for virksomhetsarkitektur. 

Til slutt presenteres punktvise hovedkonklusjoner. De viktigste anbefalingene er oppsummert i 

sammendraget over. 

20.01.2010 Versjon 1.1 9/89

DIFI 


3 Anvendelse av metoder og standarder i ulike scenarioer 

Dette kapittelet beskriver generelle scenarioer for tjenesteorientert arkitektur. Vi kan skille 

samhandling mellom offentlige enheter (1 i figuren under) fra offentlig tjenesteyting til 

innbyggerne (2) og næringslivet (3), og fra det offentliges innkjøp av tjenester fra 

næringslivet (4). 

Innbyggere 

Næringsliv 

2 

3 

Figur 1. Bruksområder for tjenesteorientert arkitektur 

Vi fokuserer her på fire sentrale scenarioer for tjenesteorientert arkitektur i offentlig sektor: 

1. Informasjonsutveksling mellom enheter i offentlig sektor 

2. Tilgjengeliggjøring av registerdata 

3. Saksbehandling 

4. Innrapportering 

Offentlig sektor 

Enhet 1 

Scenarioene henger sammen som illustrert i figuren under: 

Saksbehandling 

1 

Enhet 2 

Offentlig sektor 

Innrapportering 

Enhet n 

Informasjonsutveksling 

Tilgjengeliggjøring 

av registerdata 

Register 

Figur 2. Scenarioer for tjenesteorientert arkitektur 

Næringsliv 

Hvert scenario blir beskrevet på overordnet nivå. Deretter ser vi på hvilke varianter av disse 

scenarioene vi kan finne, og på konkrete tjenester som eksemplifiserer hvert scenario. 

Eksemplene hentes fra felles nasjonalt, statlig, regionalt, fylkes- og kommunalt nivå, i ulike 

sektorer. Til slutt diskuterer vi kort hvilke metoder og standarder som er best egnet som 

tekniske løsninger for scenarioet. For en utfyllende beskrivelse av de ulike standardene, 

henvises det til kapittel 4. 

20.01.2010 Versjon 1.1 10/89 

4

DIFI 


3.1 Scenario: Informasjonsutveksling mellom enheter i offentlig sektor 

Offentlige enheter utveksler informasjon med hverandre i mange sammenhenger. De tre neste 

scenarioene vil kunne kreve oversendelse av registerinformasjon til brukere i offentlig sektor, 

utveksling av informasjon om en sak, og spredning eller videreformidling av innrapporterte 

data. I en tjenesteorientert virksomhetsarkitektur bør vi dessuten se på hvordan offentlige 

virksomheter tilbyr tjenester til hverandre, og innrapporterer data om sin virksomhet til ulike 

kontrollinstanser. Typiske eksempler på informasjonsutveksling inkluderer: 

Utveksling av elektronisk journal mellom sykehus, helseforetak, leger m.m. 

Meldinger som følger KITHs rammeverk i ebXML for elektronisk meldingsutveksling i 

helsevesenet [68], f.eks. henvisninger og rekvisisjoner med svar, legeerklæring til Nav, 

Justissektorens samhandlingsarkitektur for straffesakskjeden, 

Utveksling av saksmappen i en byggesak mellom ulike enheter i en kommune, 

Overføring av grunnlagsmaterialet for en søknad om utbygging av et olje- eller gassfelt 

i Nordsjøen, som kan inneholde svært store datamengder, 

Overføring av oppdatert folkeregister til enheter som jobber mot en egen kopi av dette, 

Overføring av 3-dimensjonale bygningsmodeller med tilknyttede egenskaper (BIM) 

mellom Statsbygg og virksomhetene som skal bruke eller vedlikeholde bygget, 

Overføring av kartdata fra Norges kartverk, 

Overføring av meteorologiske data, 

Bestillinger, fakturaer, leveransedokumentasjon og logistikkstyring i forbindelse med 

innkjøp av varer og tjenester, 

Budsjetter og regnskapsrapportering. 

Ulike behov for informasjonsutveksling vil gi ulike krav til de tekniske løsningene: 

Mengden av data som skal overføres vil variere, og 

Frekvensen, hvor ofte meldingene overføres, med særlig vekt på topper i belastningen, 

for eksempel i forbindelse med tidsfrister. 

Formen på dataene vil også variere, fra strukturerte databaser og meldinger, via 

tekstdokumenter, filer i applikasjonsspesifikke formater, og ulike medier som bilder, 

lyd, video m.m. 

Avsenderens teknologi for å lagre, finne fram og tilgjengeliggjøre informasjonen legger 

føringer på hvilke metoder som er aktuelle. 

Mottakerens bruk av informasjonen vil også påvirke løsningen, om den skal vises 

direkte til en bruker, eller prosesseres videre av et applikasjonssystem, kobles sammen 

med data som mottakeren allerede har o.s.v. I det siste tilfellet blir semantisk 

interoperabilitet mellom senders og mottakers systemer kritisk. Spesifikk semantikk er 

en viktig årsak til etableringen av sektorstandarder, f.eks. innen helse, transport, 

bygg/anlegg, og utdanning. 

Ulike sikkerhetsnivåer, om dette er allment tilgjengelig informasjon etter 

offentlighetsloven, sensitive opplysninger om personer, viktig for nasjonal sikkerhet 

o.s.v. Personvern og begrensning av innsynsrett må også ivaretas. Dette styrer krav til 

autentisering, og til metodene som brukes til å overføre data, kryptering og lignende. 

Sikkerhetskrav kan også resultere i mer komplekse prosesser for informasjonsutveksling, 

hvis for eksempel godkjenning eller samtykke må innhentes før 

informasjonen deles. 

Ulike mønstre for meldingsutveksling, initiert av sender eller mottager, eller kanskje 

styrt av eksterne hendelser (jf. avsnitt 4.4.1). Inngår meldingen i en 

interaksjonsprotokoll med forskjellige meldingstyper? 

20.01.2010 Versjon 1.1 11/89

DIFI 


Varierende vilje til å betale dyrt for maksimal pålitelighet, responstid, tilgjengelighet, 

og feilhåndtering. 

Hvilke tekniske angrepsmåter som er egnet, avhenger i stor grad av datamengder, formater 

og sikkerhet, samt tilgjengelig infrastruktur og mellomvare. Alle scenarioene vil dessuten bli 

påvirket av hvilke felleskomponenter og fellestjenester som blir utviklet. For dette scenarioet 

er en felles komponent eller standardprofil for meldingsutveksling sentral. 

3.1.1 Tekniske løsninger 

Valg av tekniske løsninger for informasjonsutveksling i offentlig sektor dreier seg om valg av 

standarder og rammeverk, og deretter hvordan løsninger bør implementeres innenfor det 

frihetsrom som de aktuelle standarder tillater. Her er særlig sikkerhet, kommunikasjonsmønstre, 

datamengder og dataformater viktig. Beslutningene bør knyttes opp til arkitekturprinsippene 

(se side 8). 

3.1.1.1 Overordnet arkitektur og tilnærming 

I begrepet ”informasjonsutveksling” kan det ligge innbakt en antagelse om en meldingsbasert 

integrasjon på tvers av virksomheter. Denne tilnærmingen følger papirbasert 

forvaltningspraksis og jus, hvor oversendelse av informasjon i form av søknader, dokumenter 

og saksmapper kan betraktes som juridiske handlinger. Det betyr ikke at dette er den eneste 

eller beste løsningen for fremtidens tjenestearkitekturer. 

En helt annen tilnærming er å basere seg på dataintegrasjon, med et utgangspunkt om at alle 

data kun bør lagres ett sted. Dette er f.eks. valgt som grunnprinsipp for domstolsverket i 

Sverige [43]. Dette gir fellestrekk med løsninger for tilgjengeliggjøring av registerdata (avsnitt 

3.2), selv om informasjonen som utveksles ofte vil være mindre strukturert og mer dynamisk 

enn den man finner i etablerte registre. 

3.1.2 Standarder for meldingsutveksling 

De mest aktuelle standardene for meldingsutveksling er EDI, ebXML og webtjenester (se 

avsnitt 4.2 og 4.3). EDI er en eldre teknologi som det først og fremst vil være aktuelt å 

fortsette å bruke der hvor man allerede har en etablert løsning. For nyutvikling bør man heller 

bruke mer åpne løsninger basert på SOAP og XML. Da står valget mellom ebXML Messaging 

Service og WS-standarder. Innholdsstandarder for ebXML Core Components kan også brukes 

til å definere skjemaer for webtjenester, så valget dreier seg her kun om 

kommunikasjonsløsningen. 

For helsesektoren definerer referansekatalogen ebXML [78] som obligatorisk for sikker 

meldingsutveksling [77]. Samtidig har KITH også definert en profil webtjenester i 

helsesektoren [70], basert på WS-standarder. Begge disse løsningene gjør sikker 

kommunikasjon med PKI mulig, og WS-løsningen er anbefalt for intern kommunikasjon, mens 

ebXML skal brukes mellom foretak. Innkjøp og logistikk er annet område hvor ebXML er 

utbredt, gjennom f.eks. ehandel.no. 

De tekniske grunnene til å velge ebXML framfor WS var viktige inntil sikkerhetsstandarder for 

webtjenester kom på plass. Verktøystøtten for ebXML er betydelig, men den kommer ikke opp 

mot WS, som er allestedsnærværende. WS-standarder bør derfor anbefales for områder hvor 

det ikke finnes spesialiserte ebXML-løsninger. 

En annen mulighet er å bruke proprietære komponentarkitekturer. Dette er mest aktuelt 

internt i en virksomhet. Ytelse, skalerbarhet og enkel implementasjon kan være gode grunner 

for å velge en slik løsning. Samtidig skaper det barrierer mot gjenbruk og flerbruk, så slike 

valg bør begrunnes. Heldigvis tilbyr de fleste proprietære arkitekturer egne eller tredjeparts 

mekanismer for å gjøre komponentløsninger tilgjengelig også som webtjenester, så en 

kombinasjon er mulig. 

KITH legg i sin profil for webtjenester i helsesektoren [70] til grunn at ”profilen skal basere seg 

på etablerte web services-standarder i endelige utgaver. Standardene skal ha bred 

verktøystøtte, og være leverandørnøytrale.” De valgte standarder følger WS-I sin basis profil 

og basis sikkerhetsprofil [209, 211]. Følgende standarder inkluderes: 

20.01.2010 Versjon 1.1 12/89

DIFI 


WSDL 1.1 for tjenestebeskrivelser (avsnitt 4.2.1) 

WS-Adressing for transportnøytral adressering av tjenester (avsnitt 4.4.4) 

WS-Policy 1.5 for beskrivelse av tjenesters oppførsel og bruksvilkår, og parametere for 

konfigurering (avsnitt 4.3.2.4) 

WS-Security 1.0 for signering/kryptering og autentisering (avsnitt 4.8.4) 

o Kravspesifikasjon for PKI i offentlig sektor og sertifikater fra eID for personer og 

virksomheter 

o SAML – hvis tjeneste for engangs innlogging brukes 

o X.509 sertifikater og brukersertifikater 

o WS-SecurityPolicy for sikkerhetsregler og -parametere 

o XML Encryption og XML Signature 

http, eller https hvis det er påkrevd. 

Dessuten vurderes UDDI og ebXML Registry som teknologier for en fremtidig katalogtjeneste, 

og sikkerhetsløsninger på ulike nivåer beskrives. En utviklingsmetodikk basert på kontraktførst, 

heller enn kode-først, anbefales. 

Denne løsningen er i tråd med internasjonale anbefalinger, og et godt utgangspunkt for en 

nasjonal profil. Valget av WSDL 1.1 kan diskuteres. Sammenlignet med WSDL 2.0 og ebMS er 

dette den minst etablerte standarden, formelt sett, siden den bare er et notat fra W3C. ebXML 

har sterkest standardforankring gjennom OASIS, FN og ISO, men har samtidig minst 

verktøystøtte. WSDL 2.0 kunne vært et kompromiss, som anbefalt standard fra W3C støttet av 

de fleste verktøy. Uten støtte fra f.eks. Microsoft vil det likevel legge for sterke føringer å gjøre 

dette til en obligatorisk standard. Mange forslag unngår derfor å spesifisere hvilken versjon av 

WSDL som skal brukes, mens andre anbefaler at tjenester så langt det er mulig beskrives 

både med WSDL 1.1 og WSDL 2.0. Altinn II legger f.eks. opp til parallell publisering av 

underliggende tjenester mot flere integrasjonsløsninger og standarder. 

Et annet spørsmål er hvilken versjon av SOAP som bør foretrekkes. Dette sier ikke KITH noe 

om, mens WS-I velger 1.1 for versjon 1.X av sine profiler, og 1.2 for versjon 2.0 av profilene 

(jf. avsnitt 4.2.1). En presis retningslinje for offentlig sektor på dette området bør dessuten 

beskrive hvilke bindinger for SOAP som anbefales, i tråd med f.eks. WS-I. I likhet med for 

WSDL, vil den beste løsningen være å gjøre tjenestene tilgjengelig over både SOAP 1.1 og 1.2. 

3.1.3 Standarder for sikkerhet 

Løsningsutformingen for sikkerhet kan basere seg på autentiseringstjenester fra ID-porten 

(avsnitt 4.8.1), i tråd med eID [34]. Hvorvidt dette i fremtiden også skal brukes som sentral 

autentiseringstjeneste for ansatte i offentlig sektor, er ikke avgjort. Der hvor lokale 

identitetsleverandører blir implementert, bør dette likevel gjøres med standard sertifikater i 

tråd med ID-porten, slik at tjenester kan implementeres med et så enkelt grensesnitt til 

autentisering som mulig. Spesifikasjonene før føderert identitet i WS-Security bør derfor 

følges. Det bør dessuten avgjøres om løsningene for engangs innlogging skal baseres på SAML 

og/eller WS-Federation (se avsnitt 4.8.4.4). SAML virker foreløpig som et tryggere valg, men 

utbredelsen av WS-Federation bør følges. Altinn II har valgt SAML. For autorisering bør 

dessuten XACML vurderes. Denne brukes av OpenSSO, som ID-porten er basert på. 

Sikkerhetsløsningen må tilpasses kravene som stilles for den informasjonen som skal 

utveksles. WS-Security trenger ikke å inngå i implementasjonen dersom informasjonen er 

åpent tilgjengelig. 

3.1.4 Løsninger for kommunikasjon 

Ved siden av standard for meldingsutveksling må en løsning også velge hvilke 

interaksjonsmønstre som skal støttes, f.eks. avhengig av om det er avsender eller mottaker av 

informasjonen som initierer utvekslingen (push eller pull). Dette har sammenheng med de 

ulike meldingsmønstre som WSDL støtter (se avsnitt 4.2.1.1), men også den grunnleggende 

20.01.2010 Versjon 1.1 13/89

DIFI 


arkitekturen. Her tilbyr WSDL 2.0 noen flere muligheter enn versjon 1.1, for pålitelig 

overføring og valgfritt svar. 

For å sikre en løs kobling mellom kommunikasjonsgrensesnittet og resten av 

implementasjonen, vil det være en fordel med størst mulig gjenbruk av meldinger mellom de 

ulike interaksjonsmønstrene som man støtter, og at komponenten som implementerer selve 

tjenesten overlater all håndtering av protokoller til kommunikasjonsgrensesnittet. Ideelt sett 

burde tjenestekomponenten være tilstandsløs, slik at alle hensyn til hvilket steg vi har kommet 

til i samhandlingsprosessen håndteres utenfor tjenesteimplementasjonen. REST (avsnitt 4.2.6) 

er en arkitekturstil som sørger for dette. Den er særlig egnet for enkle tjenester, som tilgang 

til registerdata. Ved siden av de vanligste REST-tjenestene for opprettelse, lesing, endring og 

sletting av informasjonselementer, vil man ofte trenge tjenester for validering av 

informasjonsstrukturen, og for søking og navigering. 

I noen situasjoner vil informasjonsutvekslingen på IKT-nivået følge kommunikasjonen på 

virksomhetsnivået, men i andre tilfeller vil de avvike fra hverandre. To virksomheter kan bruke 

samme datasystem, men likevel trenge å utveksle informasjon. I andre sammenhenger kan 

informasjonsutveksling mellom to ulike system i samme virksomhet være utfordringen, til og 

med to system som anvendes av samme bruker. Meldingsutveksling kan også foregå på 

virksomhetsnivå, gjennom at en saksbehandler informerer en annen om at de sender over en 

sak, ved siden av den rent tekniske overføringen av saksinformasjonen mellom systemene 

som de to saksbehandlerne bruker. Kanskje initieres kommunikasjonen på virksomhetsnivå av 

avsender, mens det på teknisk nivå er mottakers datasystem som etterspør 

saksinformasjonen fra avsenderens. 

EDI og ebXML baserer seg på direkte samsvar mellom virksomhetsnivået og IKT-nivået i 

kommunikasjonen. En bestillingsmelding er f.eks. både en melding fra avsender til mottaker, 

og fra avsenders datasystem til mottakers. Lagdelte arkitekturer innfører derimot ofte et skille 

mellom virksomheten og den tekniske implementasjonen, f.eks. slik at den tekniske løsningen 

kan implementeres mest mulig uavhengig av de organisatoriske samhandlingsmønstrene. 

Prosess- og regelmotorer kan brukes til å støtte ulike samhandlingsmønstre med samme 

teknologi. For mer kompleks interaksjon virker dermed webtjenester som mer velegnet enn 

løsninger som følger en EDI-tilnærming. 

Det kan også være hensiktsmessig å skille horisontale kommunikasjonsomgivelser, hvor 

partene kan sende de samme meldinger til hverandre, fra vertikale, hvor den ene parten 

etterspør, mens den andre parten leverer informasjon. Horisontal kommunikasjon mellom 

virksomheter kan godt implementeres ved hjelp av vertikal teknisk kommunikasjon, f.eks. til 

et felles register. Horisontal teknisk kommunikasjon basert på meldingsutveksling kan godt 

brukes til å støtte vertikal virksomhetsinteraksjon mellom brukeren og leverandøren av en 

tjeneste. Dette vil vi se nærmere på under diskusjon av saksbehandlingsløsninger i avsnitt 

3.3.2 nedenfor. 

Hendelsesdrevne arkitekturer, hvor mottakere kan abonnere på meldinger fra avsender, gir en 

løsere kobling ved at avsender og mottaker ikke trenger å vite om hverandre. Denne 

arkitekturstilen kan brukes både på virksomhetsnivå og på teknisk nivå, til å fordele oppgaver 

og holde alle oppdatert. Stilen går bra sammen med REST, særlig i situasjoner hvor flere 

aktører kan endre de samme dataene. For dette området virker WS-Notification som den 

sterkeste standarden, selv om alternativet WS-Eventing har støtte fra bl.a. Microsoft (jf. 

avsnitt 4.4.3). 

3.1.5 Løsninger for store datamengder 

Utveksling av store datamengder kan kreve spesialløsninger for å få til akseptabel ytelse. 

Standarden MTOM, som benytter SOAP with attachments til å implementere komprimering og 

valgfri kryptering av binære data, er egnet for data i andre format enn XML, eller XML-data 

som først er gjort om til binær form. Denne løsningen anbefales av WS-I, og er en klar 

kandidat for offentlige retningslinjer. I framtida vil trolig implementeringer av EXI kunne tilby 

enda bedre ytelse, særlig raskere koding og dekoding (se avsnitt 4.5.7). 

Proprietære alternativ til disse åpne standardene ble diskutert i avsnitt 4.5.9. Ofte overføres 

dataene i en fil ved hjelp av ftp heller enn http. En binding for SOAP til ftp har også vært brukt 

20.01.2010 Versjon 1.1 14/89

DIFI 


for webtjenester, blant annet for mobile nettverk hvor nettverkstilkoblingen ikke er stabil, og i 

situasjoner hvor mottakersiden, f.eks. et arkivsystem, kun tilbyr mottak over ftp. 

3.1.6 Dataformater 

Utforming av formater for meldingsinnhold er en viktig problemstilling for 

informasjonsutveksling. KITH har f.eks. definert en lang rekke formater for helsesektoren, og 

Altinn definerer tilsvarende for de ulike skjemaene som næringslivet skal rapportere i. 

Innenfor et tjenesteområde bør det utvikles en helhetlig konseptuell datamodell, slik at 

sammenhengene mellom de ulike meldingsformatene er klar, og den totale datastrukturen så 

enkel som mulig. Dette er et middel for å unngå at de samme dataene samles inn flere 

ganger, og lagres flere steder. Internasjonale og nasjonale begrepsrammeverk bør følges i 

størst mulig grad (se avsnitt 4.5.5). 

Fleksibilitet blir et viktig arkitekturprinsipp i denne sammenhengen, ettersom 

meldingsformatene trolig vil måtte oppdateres ved jevne mellomrom. Nye formater blir gjerne 

lagt til, mens gamle utvides, omstruktureres, eller blir erklært utdaterte. Et viktig spørsmål blir 

da om datastrukturen for meldingene skal gjøres til en del av tjenestegrensesnittet, eller 

forvaltes uavhengig av dette. Altinn 1 har valgt å definere tjenestene uavhengig av 

datainnholdet. En og samme operasjon brukes dermed til all rapportering, mens 

forvaltningstjenester ved siden av gir tilgang til de forskjellige skjemaene som kan brukes, i 

ulike versjoner. Leverandører som har registrert seg får beskjed når nye formater er 

tilgjengelig. For å minske belastningen på leverandørene, blir eksisterende meldingsformater 

oppdatert bare ved jevne mellomrom, typisk en gang i året. Dette gir en enkel og stabil 

tjenestebeskrivelse. 

Den alternative løsningen er å eksponere dataformatene i tjenestegrensesnittet, og definere 

en operasjon for hver meldingstype. Dermed vil man måtte endre tjenestegrensesnittet hver 

gang meldingsformatene blir oppdatert, men samtidig får leverandører som skal bruke 

grensesnittet bedre støtte fra sine utviklingsverktøy til å håndtere datastrukturene. Man 

bringer dessuten forvaltningen av meldingsformater inn i et standardisert regime, hvor ulike 

versjoner av tjenester kan håndteres av standard mellomvare for tjenesteorientert arkitektur. 

En tjenestekatalog som UDDI eller ebXML Registry kan brukes til å gi oversikt over alle de 

forskjellige meldingsformatene, heller enn en egenutviklet løsning. 

Når dataformatene ikke er eksplisitt gjengitt i tjenestegrensesnittet blir det også vanskeligere 

for mellomvaren å behandle, fordele, og logge meldingene. Man blir helt avhengig av 

innholdsbasert ruting for å skille de ulike meldingstypene fra hverandre. Når meldingstypene 

skal behandles på ulike måter, f.eks. sendes til ulike mottakere, behandles av ulike prosesser, 

eller har forskjellige rutiner for unntakshåndtering og sikkerhet, krever implisitte dataformater 

kraftigere mellomvare. Dette er kanskje ikke noe problem for en sentral instans som Altinn, 

men når man skal lage en formidlingstjeneste for offentlig sektor i Altinn II, må man ta større 

hensyn til mottakere med svært varierende infrastruktur, organisatorisk og teknologisk 

modenhet. 

I helsevesenet har KITH valgt å gjøre meldingsformatene eksplisitte, gjennom egne 

operasjoner for hver meldingstype. Dette valget avhenger av forventet endringsfrekvens og 

tilgjengelig verktøystøtte. 

For pålitelig meldingsutveksling kan WS-ReliableMessaging (avsnitt 4.8.7) anbefales. Denne 

standarden har vært tilgjengelig i flere år, og den har god verktøystøtte. Behovet for 

håndtering av dette på meldingslaget bør imidlertid vurderes opp mot tilgjengeligheten av 

løsninger på transportlaget, i de grunnleggende kommunikasjonsprotokollene. 

3.1.7 Tjenestekataloger 

Oversikt over tilgjengelige grensesnitt for informasjonsutveksling kan organiseres som 

tjenestekataloger (jf. avsnitt 4.3.2). Kanskje kan offentlig sektor utvikle en delingskultur hvor 

slike kataloger kan brukes til å organisere gjenbruk og flerbruk av fellestjenester på tvers av 

virksomheter? Bruken av UDDI er utbredt i mange sektorer, selv om ikke alle tjenester blir 

eksponert. En nasjonal tjenestekatalog er etterspurt [70]. 

20.01.2010 Versjon 1.1 15/89

DIFI 


Erfaringer fra eHandel i Danmark tilsier at UDDI kan være for kompleks og upålitelig for visse 

anvendelser. Infrastrukturen for eHandel på tvers av landegrenser i Europa som utvikles av 

PEPPOL [28], har derfor valgt en katalogløsning bygd på DNS (Domain Name System) for 

robusthet. Katalogdata utveksles med http GET etter prinsipper fra REST (jf. avsnitt 4.2.6). Vi 

skal likevel være forsiktige med å trekke for klare konklusjoner fra dette, siden 

anvendelsesområdet her er svært godt strukturert, med klart definerte prosesser, tjenester og 

meldinger. Alle nodene tilbyr det samme grensesnittet, så vi snakker egentlig mer om en 

tjenerkatalog enn en tjenestekatalog. 

3.2 Scenario: Tilgjengeliggjøring av registerdata 

Det å gjøre data fra et register tilgjengelig for andre offentlige virksomheter overlapper med 

informasjonsutveksling. I dette avsnittet fokuserer vi på hvordan avsendersiden kan få brakt 

data ut av sine interne system, og på overføring og gjenfinning av strukturert informasjon. 

Viktige registre i offentlig sektor inkluderer: 

Det sentrale folkeregisteret 

Enhetsregisteret og oppgaveregisteret i Brønnøysund 

Skattelister 

Arbeidstaker/arbeidsgiver-registeret (Nav) 

Grunneiendom-, adresse- og bygningsregistert (GAB) og matrikkelsystemet til Statens 

Kartverk, og annen kartinformasjon fra kartverket og landets kommuner 

Motorvognregisteret 

Løsøreregisteret 

Førerkortregisteret 

Skattelister 

Statistikk fra SSB 

Postnummerregisteret 

Nasjonalt helseregister 

Registrene varierer med hensyn på hvilke krav de stiller til tekniske løsninger: 

Sikkerhetsnivået vil avhenge av informasjonsinnholdet. Noen registre er også 

tilgjengelig for publikum, mens andre kun skal kunne ses av et fåtall autoriserte. I noen 

tilfeller må oppslag logges for å kunne spore misbruk. eID [34] skiller mellom fire ulike 

risikonivå: Ingen, liten, moderat og stor, som gir ulike nivåer av konsekvenser for liv 

og helse, økonomi, renommé og tillit, kriminalitet og straffeforfølgelse. Dette knyttes til 

fire nivåer av sikkerhet, med ulike autentiseringskrav. 

Forretningsmessige betingelser for adgang til dataene, i tilfelle det ikke er gratis. Noen 

offentlige enheter lager egne selskap som skal stå for salg av informasjonstjenester, 

f.eks. Norsk Eiendomsinformasjon AS i tilknytning til Statens Kartverk. 

I tilfeller hvor lokale fagsystem eller databaser skal knyttes sammen med felles 

registerdata, trengs interoperabilitet på teknisk, semantisk og organisatorisk nivå. For 

felles registre vil dette først og fremst være en utfordring for mottakerne, men eieren 

av registeret bør legge til rette for ulike brukergrupper gjennom klart definerte 

grensesnitt på alle nivåer. 

Registereiers teknologi vil påvirke løsningen. En standard relasjonsdatabase med enkle 

datatyper vil skille seg fra hierarkiske databaser for geometriske modeller, og 

stormaskinløsninger fra klient-tjener. 

Ulike typer data kan håndteres på ulike måter. Ved siden av strukturerte registre, kan 

det være aktuelt å gjøre tilgjengelig multimedia fra bibliotek og kringkasting, 

geometriske kartdata, bygningsmodeller o.s.v. 

20.01.2010 Versjon 1.1 16/89

DIFI 


Det kan være ulike forventninger til datakvalitet og presisjon, inkludert 

oppdateringshyppighet. 


Et felles register kan i hovedsak gjøres tilgjengelig på to måter: 

1. En sentral tjeneste som brukerne forespør data fra når de trenger dem. 

2. Kopiering av det sentrale registeret til lokale databaser, for å bedre ytelse, skalerbarhet 

og tilgjengelighet, eller for enklere integrasjon med lokale data. 

Alternativ 1 kan realiseres som en sentralisert løsning både logisk og fysisk. Alternativt kan 

databaseteknologi brukes til å implementere en fysisk distribusjon for økt ytelse og sikrere 

tilgjengelighet. På logisk nivå kan man etablere en føderasjon av flere lokalt vedlikeholdte 

registre, under ansvarsområdet til f.eks. den enkelte kommune, fylke, eller helseregion (se 


Alternativ 2 har enda flere variasjonsmuligheter, knyttet til hvordan og hvor ofte de lokale 

kopiene blir oppdatert: 

En enkel løsning er jevnlig overføring av hele registeret på et filformat som er egnet for 

import i de lokale databasene. 

o Overføringen kan initieres fra den sentrale kilden (push) eller fra de lokale 

kopiene (pull). 

Man kan også overføre bare de endringene som er foretatt siden forrige runde (delta). 

I en hendelsesdrevet arkitektur kan den sentrale kilden gi beskjed til alle kopier hver 

eneste gang noe endres, slik at de alltid er oppdatert. 

o Med løs sammenkobling via abonnering kan man håndtere et vilkårlig og 

dynamisk antall kopier. 

En hendelsesdrevet arkitektur kan også støtte andre konfigurasjoner enn den sentraliserte 

løsningen hvor alle oppdateringer skjer på en kildedatabase, gjennom at alle kopier potensielt 

kan informere de andre om lokale endringer. Dette vil kreve transaksjonshåndtering for å 

håndtere parallelle oppdateringer hos flere kilder. 

For begge hovedløsningene står man over for et valg om integrasjonen skal foretas direkte på 

databaselaget, eller om databasen bør kapsles inn som webtjenester. I forhold til 

arkitekturprinsippene kan dette dreie seg om et valg mellom skalerbarhet og ytelse, opp mot 

tjenesteorientering, interoperabilitet og åpenhet. Jo flere lag med programvare man legger til, 

jo større overhead. I forhold til proprietære grensesnitt for datatilgang, og åpne 

industristandarder som ODBC og JDBC, vil et tjenestelag gjerne abstrahere bort detaljer, og 

styre bruken inn mot et mindre antall funksjoner enn det generell databaseaksess tillater. 

F.eks. ender man fort opp med å opprette webtjenester for de forespørslene som 

applikasjonene bruker, vis a vis å gi full tilgang til alle typer forespørsler med SQL. 

Innkapslingen i en webtjeneste forenkler sikkerhet, blant annet gjennom å begrense antall 

porter som man trenger å åpne i brannmurer, og ved at man unngår å åpne selve databasen 

for angrep. Samtidig er proprietære databaseteknologier utviklet over lang tid for å kombinere 

akseptabel ytelse med tilstrekkelig sikkerhet. En analyse av skalerbarhet og ytelse for det 

enkelte register er dermed avgjørende for om webtjenester bør anvendes. Dette bør dessuten 

vurderes ut ifra et kost/nytte-perspektiv, avhengig av om det allerede finnes mye verdifull 

logikk som ligger i basen, og dette ønskes tilgjengeliggjort til web klienter med minimal 

kostnad. 

Store databasesystem tilbyr verktøy for å eksponere sine data, forespørsler, prosedyrer og 

lignende som webtjenester, og for å bruke webtjenester til å laste nye data inn i databasen. 

Løsningene kan settes opp med minimal koding. Gjennom webtjenester tilbys mulighet til å 

utvide databasens funksjonalitet for klientprogrammer ved å eksekvere databasens 

operasjoner som standard webtjenester. For eksempel kan klientapplikasjoner gjenbruke 

eksisterende databaselogikk, som lagrede prosedyrer, funksjoner og pakker, forhåndsdefinerte 

SQL-spørringer (views), som standardbaserte webtjenester. 

20.01.2010 Versjon 1.1 17/89

DIFI 


Noen databaseløsninger har også innbygget klientfunksjonalitet for webtjenester. Man kan for 

eksempel definere datainnhenting fra en ekstern kilde gjennom en webtjeneste, og lagre 

dataen i basen. En slik transaksjon kan f.eks. initieres via en hendelse som er definert i en 

databasetrigger. 

Ved siden av direkte adgang til SQL, kan man utnytte mer høynivå dataaksess gjennom f.eks. 

ADO.net, JDO (data objects), LINQ eller JPA (persistence). Dette er først og fremst aktuelt hvis 

man ønsker å legge på et lag med applikasjonslogikk mellom registeret og de som henter data 

fra det, eller hvis dataene skal gjøres tilgjengelig i et brukergrensesnitt og ikke til mottakernes 

applikasjoner og tjenester. I dette tilfellet bør også REST og AJAX vurderes, da disse 

metodene er god egnet for enkle, databaseorienterte applikasjoner. 

Hvis registerdataene som skal overføres innholder multimedia eller binære 

applikasjonsspesifikke formater, bør man vurdere MTOM, SOAP with Attachments og XOP 

(avsnitt 4.4.2.2 og 4.5.7) for å sikre rask overføring. Standarder for overføring av multimedia 

er allerede dekket av referansekatalogen [32], og ligger på siden av tjenesteorientert 

implementasjon. Vi går derfor ikke inn på dette her. 

3.2.2 Løsninger for søk 

Sammenlignet med generell informasjonsutveksling som vi så på over, vil de fleste registre ha 

en mer stabil datamodell. Dette gjør det fornuftig å inkludere datamodellen i 

tjenestegrensesnittet, som XML Schema. Et valg som det kan være vanskeligere å forutse 

konsekvensene av over tid, er hvilke forespørsler som mottakerne skal kunne bruke for å søke 

fram data, og hvordan tjenestegrensesnittet til disse bør utformes. Åpne søkegrensesnitt kan 

utformes med webtjenester som tar i mot forespørsler i SQL eller XQuery, mens lukkede 

søkegrensesnitt typisk definerer hvert søk som en parametrisert operasjon i WSDL eller REST. 

Lukkede grensesnitt må man selvfølgelig utvide hver gang man ønsker å støtte noen nye typer 

forespørsler, med det gir samtidig tjenesteleverandøren bedre kontroll over tjenestebruken. 

Kombinasjonen XForms–REST–XQuery (XRX) har fått oppmerksomhet i det siste som en åpen 

standardprofil for dataorienterte applikasjoner. Her lagres dataene som XML gjennom XQuery 

og ikke i en relasjonsdatabase. Nettopp bruken av XML på alle nivå gjør løsningen enkel. Selv 

for de som ikke følger denne arkitekturen fullt ut, er XQuery interessant, siden den kan brukes 

til å søke i både relasjonstabeller og hierarkiske data som XML. XQuery eller XSLT kan 

dessuten brukes til enkelt å produsere brukergrensesnitt i HTML fra en datastruktur. For mer 

informasjon, se avsnitt 4.5.3.2. 

3.2.3 Løsninger for semantisk interoperabilitet 

Når dataene fra et felles register skal gjøres tilgjengelig gjennom fagsystem og andre 

applikasjoner på brukersiden, blir semantisk interoperabilitet mellom kilde- og mottakersystem 

essensielt. Avsnitt 4.5.2 diskuterer ulike løsninger på dette problemet på overordnet nivå. 

Semantisk teknologi er utenfor fokus for denne rapporten, men samtidig bare en av mange 

tilnærminger for å løse problemet. Tilgjengeligheten, åpenheten og brukervennligheten til 

semantisk teknologi er ofte langt dårligere enn for industrielle løsninger som kobler sammen 

tradisjonell datamodellering, XML Schema, XSLT, eller XQuery. 

For tjenesteorientert arkitektur er det viktig at teknologiene man velger baserer seg på de 

grunnleggende standarder for webtjenester. Flere standarder for semantisk web har f.eks. 

manglet et klart definert XML Schema for sine XML-formater, noe som gjør at 

representasjonen av semantiske data på tjenestelaget ikke blir entydig. Dette kan skape 

problemer med interoperabilitet. 

3.3 Scenario: Saksbehandling 

En saksbehandlingsprosess starter gjerne med en søknad eller forespørsel fra innbygger eller 

næringsliv. Saksbehandling kan også være initiert av offentlig sektor selv, f.eks. innen politisk 

utredning eller utøvelse av juridiske myndighet. Typiske eksempler er: 

Søknad om stilling 

20.01.2010 Versjon 1.1 18/89

DIFI 


Byggesak, fra byggeplaner til ferdigattest 

Søknader i forbindelse med utbygging av et oljefelt, fra leteboring til produksjon, med 

plan for utbygging og drift (PUD) og plan for anlegg og drift (PAD) m.m. 

Søknad om stønader fra Nav 

Registrering av kjøretøy 

Juridiske straffesaker eller tvister 

Utredning for politiske vedtak 

Budsjettering 

Prosessene for saksbehandling vil blant annet variere avhengig av: 

Om en sak har flere private parter eller bare en, om det er flere parallelle søkere som 

må vurderes opp mot hverandre, eller hver søknad kan behandles for seg. 

Om flere etater involvert eller ikke. Selv om en sak er lokalisert til en etat, vil gjerne 

klagemuligheter kunne involvere et annet myndighetsnivå. 

Om saken krever skjønnsmessige vurderinger, eller om utfallet kan bestemmes av 

oppsatte regler uten at noen tolkning er nødvendig. 

Sikkerhetskrav, f.eks. om det kreves eksplisitt samtykke fra bruker for å tillate 

utveksling av informasjon mellom ulike etater i forbindelse med saken. 

Offentlighetslovens krav til allment innsyn balanseres mot personvern og andre hensyn, 

mens partene ofte har krav på utvidet partsinnsyn. 

3.3.1 Krav til interaksjon med tjenestebrukere 

Tjenestens grensesnitt ut mot brukeren er viktig for saksbehandling og annen offentlig 

tjenesteyting, enten det er manuelt med brevutveksling og telefon, helt eller delvis 

automatisert. 

Første steg er å gi brukeren den informasjon vedkommende trenger for å forstå hvem hun skal 

henvende seg til, hva slags sak hun skal søke om, hvilke skjemaer som skal brukes, hvilken 

dokumentasjon som trengs, hvordan søknaden vil bli behandlet, hvilke kriterier som gjelder 

o.s.v. Offentlige informasjonstjenester gir brukerne mulighet til selv å søke fram informasjon 

(pull), men myndighetene sprer også informasjon til publikum gjennom utadrettede 

kampanjer (push). Kommunikasjon om lover, regler og forvaltningens praksis må overkomme 

barrierer knyttet til et språk, terminologi og kompleksitet, som gjør det vanskelig for brukerne 

å forstå hvilken informasjon som gjelder dem, og hva den betyr rent praktisk. 

Portaler som Norge.no, Minside, Altinn og kommunale websider er i ferd med å gjøre 

informasjon og tilstøtende tjenester lettere tilgjengelig gjennom brukersentrert utvikling. 

Forskjellige metoder og standarder støtter dette i varierende grad på teknisk nivå, men 

utfordringene er kanskje størst på semantisk og organisatorisk nivå. Samtidig gjør utfordringer 

knyttet til et komplekst tjenestetilbud fra mange forskjellige virksomheter at portalene bør 

filtreres og struktureres i tråd med den informasjon man har om den enkelte bruker. 

Etter at en sak opprettet, vil kommunikasjonen mellom innbygger eller næringsliv og offentlige 

instanser inneholde formelle meldinger og mer uformell interaksjon knyttet til manglende 

informasjon eller tolkning av informasjon, forespørsler om status o.l. Slike utvekslinger kan 

initieres av bruker eller tjenesteleverandør. 

Når noen opptrer på vegne av andre i forbindelse med en sak, stilles det spesielle krav til 

kommunikasjonshåndtering, autentisering og innsyn. Typiske eksempler på dette er en jurist 

som bistår et firma eller en enkeltperson, eller en fastlege som søker om ytelser på vegne av 

en pasient. Dette krever adgangskontroll og meldingsruting med mulighet for delegering. 


Ved siden av informasjonsutveksling mellom virksomheter i offentlig sektor og 

tilgjengeliggjøring av registre, vil saksbehandling ofte kreve interoperabilitet mellom 

20.01.2010 Versjon 1.1 19/89

DIFI 


fagsystem, ulike løsninger for kommunikasjon med tjenestebrukeren, samt generell 

saksbehandlingsstøtte fra prosess- eller regelmotorer. 

3.3.3 Prosessmotor og regelmotor 

En prosessmotor kan brukes til å koordinere og følge opp saksbehandlingsprosessene fra 

opprinnelig forespørsel til endelig svar. WS-BPEL (avsnitt 4.7.1) er den dominerende 

standarden på dette området for tjenesteorientert arkitektur, og den støttes av de fleste 

leverandører. BPEL4People definerer tillegg for saksbehandleres interaksjon med aktiviteter i 

prosessen, og er også ganske utbredt. Disse standardene kan anbefales for bruk i offentlig 

sektor, men i så fall bør bruksområdet avgrenses. Grunnmodellen i BPEL er nemlig at hele 

saksbehandlingen utføres i henhold til en predefinert prosess, uten mulighet for å utøve skjønn 

eller håndtere uforutsette unntak. Mer brukerorienterte og fleksible saksbehandlingsløsninger 

basert på regler og hendelsesorienterte arkitekturer, bør også vurderes. Her er 

standardiseringsarbeidet imidlertid i støpeskjeen (jf. avsnitt 4.10.1.6). 

Samhandlingstjenesten i Altinn II skal støtte flere tjenesteeiere, flere brukere og flere 

sluttbrukertjenester samlet, i det som for brukerne oppleves som en prosess. Denne løsningen 

skal være tilgjengelig fra 2011, og vil trolig legge føringer på dette området. 

3.3.3.1 Portabilitet mellom prosessmotorer 

Selv om en prosess er definert ved hjelp av en åpen standard som BPEL, er det ikke sikkert at 

den enkelt kan flyttes fra en prosessmotor til en annen. Barrierer mot flytting kan skyldes at 

deler av prosessen krever mekanismer som ikke tilbys av BPEL, og som er implementert på 

ulike måter i ulike system. For BPEL gjelder dette særlig direkte kobling til underliggende 

komponenter i Java eller .Net, uten innkapsling i webtjenester, kommunikasjon med ekstern 

programvare som ikke tilbyr webtjenester, direkte aksess til data i relasjonsdatabaser (for 

skalerbarhet), og koblinger til et proprietært brukergrensesnitt [11]. Siden flere leverandører 

bruker noen av de samme grensesnittene fra XML/HTML, .Net eller Java for å implementere 

dette, så trenger det ikke å være umulig å flytte en løsning, selv om man har brukt teknologi 

på siden av BPEL. Det er likevel viktig å kjenne grensene for interoperabilitet og åpenhet, og å 

vite hva som ligger i randsonen til en typisk implementasjon av en standard. BPEL er først og 

fremst en standard for å definere grensesnitt mellom partnere (abstrakte prosesser), og til å 

sette sammen mindre webtjenester til en større tjeneste. 

Med bakgrunn i dette kan man også vurdere standardisering på et høyere og mer brukernært 

nivå, som et alternativ eller komplement til BPEL. ”What you draw is what you execute – 

WYDIWYE” foreslår noen [17, 139], et argument for standardisering på BPMN/XPDL (avsnitt 

4.10.1), med valgfri eksekveringsomgivelse. Samtidig skal man være klar over at høynivå 

modelleringsspråk ikke er like presise, og kan gi tolkningsfrihet slik at samme modell ikke 

kjøres nøyaktig likt i alle motorer. En standardisert omforming fra BPMN til BPEL finnes [122], 

så man skal heller ikke overdrive dette problemet. 

3.3.3.2 Prosessenes størrelse 

I likhet med for operasjoner, tjenester og navnerom (se avsnitt 4.2.2), er granulariteten til 

prosessene en sentral utfordring for å oppnå en fornuftig tjenestearkitektur. Her har man 

valget mellom å definere ulike varianter som ulike prosesser, eller å inkludere mange 

alternative forløp i en og samme prosessmodell. Den siste løsningen kan gjøre den enkelte 

prosess svært kompleks, og vanskelig å teste alle varianter av. 

BPEL gjør det mulig å definere aktiviteter som delprosesser, slik at man kan lage et hierarki av 

prosesser og delprosesser over mange lag, med webtjenester som grensesnitt mellom lagene. 

På hvert lag vil man da stå overfor valget mellom å lage mer generelle prosesser som kan 

gjenbrukes av mange på laget over, eller enklere og mer spesifikke prosesser med lavere grad 

av gjenbruk. 

I en slik arkitektur vil det være en fordel med generelle retningslinjer for lagdeling, f.eks. for å 

skille tjenester for dataaksess fra applikasjonslogikk, forretningsprosesser fra tekniske 

prosesser, og interaksjonsprosesser fra bakenforliggende prosesser. 

20.01.2010 Versjon 1.1 20/89

DIFI 


3.3.4 Interoperabilitet mellom fagsystem 

En av fordelene med WS-BPEL er at man baserer seg på enkle grensesnitt med WSDL for 

integrasjon med fagsystemer. Dette gjør det enkelt å knytte funksjonalitet fra fagsystem inn i 

de ulike stegene i en prosess, siden de fleste fagsystemleverandører tilbyr WSDL-grensesnitt 

for automatiske funksjoner. 

Samtidig mangler standarden opplegg for brukerinteraksjon, så her er det opp til proprietære 

og delvis standardiserte løsninger. Hvis en bruker skal utføre en oppgave i en 

saksbehandlingsprosess gjennom et fagsystem, så vil prosessen se på det som et kall til en 

webtjeneste. Denne modellen er enkel og grei, men svært rudimentær sammenlignet med 

tidligere standarder fra Workflow Management Coalition [205, 206]. De tok også høyde for 

mer kompleks interaksjon med applikasjoner og brukergrensesnitt som meldingsbokser og 

gjørelister enn det BPEL4People tilbyr. 

Her kan man lett oppleve at prosessens forventning til granularitetsnivå passer dårlig med det 

fagsystemene tilbyr. Fagsystem legger gjerne ut programmeringsgrensesnittet sitt som 

webtjenester og operasjoner, mens prosessen ønsker å knytte til seg delvis automatiserte 

oppgaver. Disse oppgavene er gjerne er sammensatt av flere operasjoner, og et eller flere 

steg med brukerinteraksjon. Man kan derfor fort oppdage at WS-BPEL eller tilsvarende 

løsninger må bygges inn på toppen av fagsystemet for å kunne koble sammen lavnivå 

programmeringsoperasjoner til mellomnivå tjenester som er meningsfulle steg i 

saksbehandlingsprosessen. Dette er reflektert i vårt målbilde for tjenesteorientert arkitektur, 

som blir presentert i Figur 5 på side 26. 

Saksbehandlingsløsninger kan fort bli utviklet som en skog av punkt-til-punkt-integrasjoner 

mellom ulike fagsystem. Mulighetene for gjenbruk og flerbruk vil øke hvis man klarer å 

etablere en generell løsning basert på et felles nav for saksbehandling, eller i det minste en 

nasjonal standard for koordinering av saksbehandling på tvers av fagsystem og virksomheter. 

3.3.5 Arkivering 

Saksbehandlingsprosesser finner sted innenfor fagsystem, egne sakssystem og i 

prosessmotorer. En helhetlig oppfølging og styring med saksbehandlingen på tvers av disse 

applikasjonene har først og fremst vært knyttet til saksarkivet, som har vært ”eieren” til 

saksnummer og saksmappe. 

Viktigheten av dette området vises gjennom standard kravspesifikasjoner for generelle 

saksbehandlingsløsninger (SGK) og arkiv (Noark). Dette er høyere nivå løsninger enn 

prosessmotorer basert på WS-BPEL, og kan ikke reduseres til sistnevnte. Å definere standard 

saksbehandlingsgrensesnitt som webtjenester, kan være en naturlig videreutvikling av 

felleskomponenter på dette området, slik Noark allerede gjør for arkivtjenester. Dette kunne 

skape en standard måte å knytte sammen interaktive saksbehandlingsprosesser på tvers av 

fagsystem og virksomhetsgrenser. Ved siden av aktiviteter som utfører webtjenester, bør en 

slik spesifikasjon inneholde standard tjenester for administrasjon og oppfølging av 

saksbehandlingsprosessen. Man trenger dessuten et standard språk for å definere metadata 

eller behandlingsregler (policies) tilknyttet de ulike tjenestene, f.eks. som et spesialisert 

grensesnitt som bruker WS-MetadataExchange og WS-Policy (avsnitt 4.3.2). 

Samtidig legger det papirbaserte grunnsynet bak arkivlovgivningen føringer som ikke passer 

like godt med en tjenesteorientert arkitektur. Siden forespørsler skal journalføres, genererer 

man i dag f.eks. pdf-versjoner av de webtjenestekall som går fra en skjemaløsning til 

underliggende applikasjoner i forbindelse med automatisert innsending av en søknad. En 

løsning som åpner for arkivering av XML-dokumenter bør vurderes, selv om man da også vil 

måtte ta vare på XSLT eller lignende spesifikasjoner som omformer datastrukturen i meldingen 

til en mer lesbar presentasjon. 

3.3.6 Kontakt med bruker 

Saksbehandling vil utgjøre et av hovedelementene ved innbyggernes, næringslivets og 

organisasjoners interaksjon med offentlig IKT-tjenester. Sammenlignet med 

20.01.2010 Versjon 1.1 21/89

DIFI 


informeringstjenester krever saksbehandling mer kompleks interaksjon, med toveis 

kommunikasjon, i ulike sammenhenger, over ulike kanaler. 

Første utfordring for en bruker er å finne ut hvilken tjeneste eller saksbehandlingsprosess man 

trenger. Dette går utover tjenestekataloger for webtjenester som UDDI, og fokuserer på 

forvaltningens tjenesteyting på virksomhetsnivå. Her kreves i overskuelig framtid en 

kombinasjon av godt strukturerte portaler og menneskelig kontakt gjennom servicetorg og 

saksbehandlere. Her kreves brukerrettede oversikter som ikke første og fremst er strukturert 

etter offentlig sektors organisering, men heller tar utgangspunkt i brukerens livssituasjon. 

Standarder som LOS [21] tar viktige steg i riktig retning for å definere et 

navigeringsrammeverk for å finne fram blant tjenestene. Samtidig bør portalene også kunne 

knyttes til informasjon om brukeren. Ideelt sett burde også saksbehandlere kunne hente ut 

grunnleggende informasjon om den enkelte for bedre å kunne gi råd til brukeren, selvfølgelig 

begrenset av personvernhensyn. 

Når brukeren har funnet ut hva slags saksbehandling eller tjeneste han/hun trenger, bør 

overgangen til grensesnittet for å sende forespørselen være direkte tilgjengelig, gjerne 

gjennom samme portal, f.eks. Minside. For næringslivsbrukere vil meldingsboksen i Altinn II 

trolig være en sentral kanal, selv om denne kanskje vil bli skreddersydd for innrapportering. 

Etterfølgende interaksjon vil gjerne finne sted gjennom brukerens meldingsboks i portalen, 

men noen brukere vil kanskje foretrekke å bruke sin vanlige e-post. Metodene og standardene 

som man velger for webtjenester, sikkerhet og kommunikasjonsløsninger bør altså spille 

sammen. En skjemastandard bør derfor f.eks. støtte strukturerte dokumenter innsendt over epost 

i tillegg til web-skjemaer. Xforms (avsnitt 4.6.2.2) og proprietære løsninger fra f.eks. 

Adobe og Microsoft tilbyr dette (jf. avsnitt 4.6.8). Altinn I bruker Xforms. 

3.3.7 Interaksjon mellom brukergrensesnitt og prosess 

Ved siden av virksomhetsprosessen som definerer stegene i saksbehandlingen, vil man 

definere interaksjonsprosesser for samspillet mellom brukere og hovedprosess, og fra 

prosessen til underliggende tjenester for hvert enkelt steg. For gjenbruk og fleksibilitet er det 

er viktig at disse lagdelte prosessene skilles fra hverandre og kan utvikles delvis uavhengig av 

hverandre. Ulike prinsipper vil gjelde for utforming av hvert lag. Mens kommunikasjonen fra 

saksbehandling til underliggende komponenter og tjenester bør skje med få, større 

transaksjoner for skalerbarhet, baseres brukergrensesnittet gjerne på mer finkornet men 

hyppigere meldingsutveksling, f.eks. i AJAX (jf. avsnitt 4.6.6). 

Et tilsvarende skille finner man i datastrukturene, hvor det ikke alltid er fornuftig å bruke 

samme XML-skjemaer for utveksling mellom brukergrensesnitt og prosess, som mellom 

prosess og applikasjonstjenester. Førstnevnte kan inneholde gruppering og organisering 

tilpasset ulike brukergruppers behov, og vil gjerne bli strukturert avhengig av hvordan 

informasjon skal presenteres på skjermen. Sistnevnte bør i større grad gjenspeile organisering 

av dataene i databaser og en eventuell felles begrepsmodell der hvor flere 

applikasjonssystemer er involvert. Dette betyr ikke at man ikke bør gjenbruke noen byggesteiner 

på tvers av lagene. 

3.4 Scenario: Innrapportering til det offentlige 

Det offentliges innsamling av informasjon fra næringsliv og privatpersoner har vært gjenstand 

for forenkling, samordning og standardisering gjennom bl.a. Altinn. Ved siden av 

Brønnøysundregisterne får Skatteetaten og Statistisk Sentralbyrå data gjennom denne 

kanalen. Andre rapporteringskanaler finnes innen ulike sektorer, f.eks. finansnæringens 

rapportering til Kredittilsynet, eller oljedirektoratets overvåking av leting og produksjon på 

norsk sokkel. Det finnes dessuten forbrukerportaler som næringslivet fyller med informasjon 

mer frivillig, som finansportalen og telepriser.no. Offentlige virksomheter møter også lignende 

rapporteringskrav, f.eks. KOSTRA for kommunesektoren. 

Løsninger for innrapportering vil variere etter flere av de sammen faktorene som vi diskuterte 

for informasjonsutveksling mellom enheter i offentlig sektor (avsnitt 3.1), særlig: 

Mengde data som skal sendes i hver rapport og formatet på denne, 

20.01.2010 Versjon 1.1 22/89

DIFI 


Frekvens for innrapportering, spesielt regelmessige tidsfrister som gir høye topper i 

belastningen, 

Grensesnitt for næringsliv og andre som rapporteres, om det baserer seg på manuell 

inntasting av informasjon i et skjema, dokumentoverføring, eller overføring på standard 

format fra næringslivets IKT-systemer. Her vil man ta hensyn til behovene til både små 

og store bedrifter. 

Prosedyrer for påminning, purring og oppfølging av manglende rapportering, inkludert 

sanksjonsmuligheter, 

Om de innsamlede data skal videreformidles til en eller flere andre offentlige 

virksomheter, f.eks. fra Altinn til SSB. 

For rapportering er felleskomponenter i brukergrensesnittlaget viktig, som portaler, 

meldingsbokser og skjemamotorer. Fleksibilitet og utvidbarhet er sentrale krav til disse 

komponentene, slik at nye skjemaer lett kan legges til. Retningslinjer for grafisk og 

innholdsmessig strukturering av skjemaer er angitt i ELMER 2 [75]. 


De tekniske løsningene for rapportering vil bestå av komponenter som portaler, 

skjemamotorer, kommunikasjon, integrasjon og tjenester, sikkerhet, prosess- og 

regelmotorer. Diskusjonen i de foregående kapitlene dekker dermed mange av 

problemstillingene. Den sentrale rollen til Altinn er også reflektert der. Her ser vi derfor bare 

på områder hvor innrapportering skiller seg fra de andre bruksscenarioene. 

3.4.2 Løsninger for skalerbarhet 

Innrapportering er ofte knyttet til tidsfrister hvor svært mange skal levere inn data samtidig. 

Dette gir ekstreme topper i belastningen, og skalerbarhet blir en hovedutfordring. Dette er i 

større grad en grunn til å gå bort fra standardisering og velge proprietære løsninger, til å gå 

vekk fra indirekte og fleksible løsninger som introduserer overhead, som proxies og lagdelte 

arkitekturer. Bruken av teknologi fra Microsoft gjennomsyrer f.eks. Altinn II, mens 

Landbrukets Informasjonsbase benytter Oracle. 

Alternativet til proprietære løsninger med høy ytelse er gjerne åpen kildekode. Man bør 

dessuten ikke kreve at behovene til de høyest belastede tjenestene blir førende også for 

tjenester som ikke har tilsvarende behov. Løsningene som velges for Altinn II bør derfor ikke 

ukritisk gjøres gjeldende for hele offentlig sektor. Skalerbarhet nedover mot enkle og billige 

løsninger vil også prege en stor del av behovet for tjenesteorientert arkitektur i offentlig sektor 

framover. 

3.4.3 Løsninger for prosess, koordinering og fordeling 

Løsninger for å formidle, koordinere og følge opp innrapporteringen bør være løst koblet til 

datafangstløsningen, slik at den ikke skaper økt belastning under rapporteringstopper. 

Sammenlignet med saksbehandling er reglene for oppfølging, fordeling og behandling av 

rapporter gjerne mer strukturerte og stabile, noe som kan gjøre bruk av standard BPMS basert 

på WS-BPEL mer aktuelt. Samtidig er brukerinteraksjon også viktig, knyttet til ulike regler for 

å sende ut påminnelse om frister, purring ved forsinket innlevering, innlevering av deler av 

rapporten over flere omganger, og mulighet til å sende inn flere versjoner av samme rapport 

over tid. 

3.4.4 Løsninger for dataoverføring 

Sammenlignet med saksbehandling og informasjonsutveksling har innrapportering den fordel 

at man har en bestemt instans som er mottaker av en rapport. Dette gjør det enklere å 

etablere datamodellen for rapporteringen, selv om denne helst bør være i tråd med andre 

rapporteringsstrukturer, slik at byrden på brukerne blir minst mulig. Samordning slik at 

samme informasjon ikke trengs å bli rapportert flere ganger, er ønskelig. 

20.01.2010 Versjon 1.1 23/89

DIFI 


Dagens systemer bruker ulike tekniske dataformater som XML over webtjenester (Altinn), 

tekstfiler med faste feltbredder (KOSTRA), skjemaer over web (bl.a. Norges Forskningsråd) 

eller skjemaer som dokumenter (bl.a. Statens Landbruksforvaltning). Denne fragmenteringen 

gjør at brukere og IKT-leverandører må implementere mange ulike grensesnitt i sine 

systemer. 

Innrapportering har vært drivende bruksområde for semantisk standardisering, blant annet 

gjennom SERES, som er knyttet til Altinn. De har et edruelig syn på løsningene: 

SERES II-prosjektet har som utgangspunkt og forpliktelse å levere løsninger som på kort 

sikt understøtter pågående produksjonsløp i Altinn ... Dette kravet har vært førende for 

fremgangsmåten i prosjektet og de prioriteringer som er gjort. Ulempen med en slik 

fremgangsmåte er at løsningen ikke tilfredsstiller framtidige behov innen samordning, 

samarbeid og samhandling i det offentlige... [4] 

Konseptskissen for SERES II [5] gir et godt utgangspunkt for videre arbeid. Den viser 

forståelse for organisatoriske utfordringer og ikke bare tekniske, og har et balansert syn på 

muligheter og begrensninger for felles begrepsmodeller. De beskriver prinsipper om 

dynamiske modeller, regler drevet av hendelser, med relasjon som en førsteklasses 

konstruksjon, og grafer heller enn trær. Disse prinsippene er dessverre i liten grad fulgt i 

hovedtyngden av arbeid på semantikk. Samtidig peker de fram mot en situasjon hvor felles 

begrepsmodeller ikke er fastlåste i statiske dokumenter, men løpende oppdatert og 

tilgjengelig, f.eks. gjennom felles webtjenester. 

20.01.2010 Versjon 1.1 24/89

DIFI 


4 Metoder og standarder for tjenesteorientert arkitektur 

Dette kapittelet gir en oversikt over standarder innenfor hver av disse hovedområdene: 

Tjenester (avsnitt 4.2) 

Mellomvare og tjenestekataloger (avsnitt 4.3) 

Kommunikasjon (avsnitt 4.4) 

Data og informasjon (avsnitt 4.5) 

Portaler, brukerinteraksjon og presentasjon (avsnitt 4.6) 

Samhandling, prosesser og komposisjon av tjenester (avsnitt 4.7) 

Sikkerhet og pålitelighet (avsnitt 4.8) 

Metoder for modelldrevet utvikling av tjenester (avsnitt 4.10) 

Eksisterende løsninger og organisatorisk modenhet har stor innflytelse på hvilke metoder og 

standarder som er relevante i en gitt sammenheng. Tjenesteorientert arkitektur utvikles ofte 

fra en situasjon med etablerte IKT-applikasjoner som brukes internt i den offentlige 

virksomheten, og hvor næringsliv og borgeres grensesnitt mot tjenestene først og fremst er 

saksbehandlerne [77]: 

Offentlig virksomhet 

Brukergrensesnitt 

Applikasjon 

Database 

Innbyggere Næringsliv 

Saksbehandlere 


Applikasjon 

Database 



Applikasjon 

Database 



Applikasjon 

Database 

Figur 3. Offentlig tjenesteyting før tjenesteorientert arkitektur. 

Første generasjons løsninger bygger gjenbrukbare komponenter som webtjenester, og gjør 

tjenester tilgjengelige gjennom portaler som er lokale for virksomheten. Portaler og tjenester 

kan kobles sammen på tvers av organisasjonsgrenser, men en helhetlig arkitektur er ennå 

ikke utviklet: 

20.01.2010 Versjon 1.1 25/89

DIFI 






Portaler 

Tjenester 

Applikasjon Database 

Portaler 

Tjenester 

Database 


Applikasjon 

Figur 4. Første generasjon tjenesteorientert arkitektur. 

Neste generasjon bygger på felleskomponenter som gjør tjenester tilgjengelige for innbyggere 

og næringsliv, men som også kan brukes for samhandling mellom virksomheter og internt i 

etatene i offentlig sektor. Vi skiller her mellom fire tjenestelag: Presentasjon og interaksjon 

gjennom portaler som Altinn og Minside med tilhørende skjemamotor, samhandling/prosesser, 

komponenter og sammenstilling, og infrastruktur for tilgjengelighet, sikkerhet, 

interoperabilitet, kommunikasjon m.m.: 

Fellestjenester for offentlig sektor 



Offentlig virksomhet Offentlig virksomhet 



Tjenester 

Applikasjon Database 


Presentasjon og interaksjon 

Samhandling 

Komponenter 

Infrastruktur 

Tjenester 

Database 

Figur 5. Andre generasjon tjenesteorientert arkitektur. 



Applikasjon 

Et slikt målbilde kan også flytte dagens applikasjoner og basis IKT-løsninger ut som 

komponenter og tjenester, kanskje utviklet og driftet av eksterne organisasjoner. Her 

gjenbrukes fellestjenester i stor grad på alle nivåer. Eierskap og driftsansvar kan plasseres 

sentralt eller lokalt i virksomheten, avhengig av krav og tilgjengelige ressurser. Som figuren 

antyder, vil noen virksomheter også utvikle egne løsninger for de fire lagene av 

tjenesteorientert arkitektur, selv om fellesløsninger bør ha forrang. 

20.01.2010 Versjon 1.1 26/89

DIFI 


4.1 Arkitekturmessige betraktninger på bruksscenarioene 

Diskusjonen i kapittel 3 peker på ulike løsningsalternativ. Valg mellom disse avhenger ikke 

bare av bruksscenarioets krav, men også av hvilken teknologi som virksomheten har 

tilgjengelig, og hvor moden virksomheten er i forhold til innføring av tjenesteorientert 

arkitektur [131]. Basert på generasjonene og målbildene for tjenesteorientert arkitektur, 

diskuterer vi her utfordringer knyttet til samvirket mellom ulike komponenter. 

Figuren nedenfor gir en oversikt over sentrale funksjonelle komponenter i en tjenesteorientert 

arkitektur for en virksomhet, i tråd med målbildet i Figur 5 på side 26. I motsetning til de 

fleste referansemodeller på området har vi valgt å ta med alle typer brukere, også de internt i 

offentlig sektor, da tjenesteorientering påvirker disse vel så mye som innbyggere og 

næringsliv. 

Andre 

enheter 

Figur 6. Komponenter i tjenesteorientert arkitektur. 

Figuren viser komponenter som firkanter og tjenestegrensesnitt som ellipser. Nederst finner vi 

eksisterende fagsystem med database og applikasjon. Disse kan tilby 

programmeringsgrensesnitt (API) av vanlig type eller som lavnivå webtjenester. 

Integrasjonslaget er ofte basert på proprietære løsninger eller industristandarder, men tilbyr 

gjerne webtjenester som et av flere grensesnitt. Komponentlaget representerer 

spesialutviklede programmerte tjenester på høyere nivå enn API, mens samhandlingslagets 

prosesser og regler kan brukes til å sette sammen tjenester uten programmering. 

Skjemamotoren er en viktig del av interaksjonslaget, som ofte er tilgjengelig i ulike portaler. 

Som det fremgår, vil også brukere i offentlig sektor kunne anvende portalløsninger, og ikke 

bare brukergrensesnittene til sine applikasjoner og fagsystem. 

Denne figuren kan illustrere ulike tekniske løsninger. For tilgjengeliggjøring av registerdata, 

ser vi disse alternativene, nedenfra og opp i Figur 7: 

Direkte tilgang til applikasjonens programmeringsgrensesnitt eller database, 

Lavnivå tjenester publisert direkte fra databasen, 

Portal 

Meldingsutveksling 


Database 

Utviklingsverktøy 

Lavnivå tjenester fra grensesnittet til applikasjonen, 

20.01.2010 Versjon 1.1 27/89 

Portal 

Interaksjon 

Samhandling 

Komponenter 

Infrastruktur 

API API 

API API 

Forvaltning, drift 

og utvikling 

Applikasjon 

Portal 

Applikasjonsbrukergrensesnitt 

Ansatte

DIFI 


Bruk av mellomvare og infrastruktur for integrasjon slik at vi får løsere kobling mellom 

intern realisering og eksterne grensesnitt, 

Spesialutviklede komponenter av tjenester på høyere nivå, som kobler sammen flere 

steg på applikasjonsnivået til en funksjonell enhet, 

Samhandling gjennom prosesser som behandler eksterne forespørsler og kaller opp de 

nødvendige interne applikasjonstjenestene for å besvare dem, 

Skjemaløsning for søk i registre og annen interaksjon. 

Andre 

enheter 

Portal 

Meldingsutveksling 


Database 

Portal 

Interaksjon 

Samhandling 

Komponenter 

Infrastruktur 

Figur 7. Ulike løsninger for tilgjengeliggjøring av registerdata. 

Tilsvarende kan vi skille fra hverandre ulike løsninger på mottakersiden: 

Direkte lagring av dataene man mottar i interne databaser, kanskje bearbeidet av 

applikasjonslogikken på veien, 

Bruk av webtjenester eller andre APIer til å sende data inn til interne fagsystem, 

Spesialutviklete tjenester for kommunikasjon med eksterne registre, for løs kobling, 

Behandling av eksterne registerdata i prosesser og regler, 

Bruk av eksterne data til å fylle ut skjema eller validere data fra brukeren, 

Bruk av registerdata til å tilpasse utforming av portal til brukerens situasjon, 

Manuell tilgang til eksterne registerdata gjennom portaler eller fagsystem. 

Dette peker også på ulike anvendelser av de tekniske komponentene. En prosessmotor kan 

brukes til å håndtere selve den funksjonelle saksgangen på samhandlingslaget, men også til å 

styre interaksjonsprosessen som ligger under et skjema eller en portal, eller til å fordele 

meldinger mellom ulike mottakersystemer i infrastrukturen. En helhetlig prosessløsning vil 

knytte sammen tjenestebrukerens og saksbehandlernes aktiviteter, men samtidig skille dem 

fra hverandre slik at de kan utvikles delvis uavhengig av hverandre. 

4.2 Metoder og standarder for tjenestelaget 

API API 

API API 

Applikasjon 

Dette avsnittet ser på grunnleggende standarder for å spesifisere tjenester og gi brukerne 

tilgang til dem. WSDL og tilhørende standarder dominerer, men eldre løsninger som ebXML er 

20.01.2010 Versjon 1.1 28/89 

Portal 

Applikasjonsbrukergrensesnitt 

Ansatte

DIFI 


fortsatt i bruk på noen områder. For brukerinteraksjon og løst sammenkoblede tjenester har 

arkitekturstilen REST etablert seg, delvis overlappende med webtjenester. 

4.2.1 Web services – WSDL 

Web Service Definition Language (WSDL) [173] har lenge vært den sentrale standarden innen 

tjenesteorientert arkitektur. I versjon 2.0 skiftet WSDL navn til Web Service Description 

Language. Mens versjon 1.1 bare er et utkast, er versjon 2.0 en anbefalt standard fra W3C 

[174]. Noen leverandører av mellomvare og verktøy for systemutvikling støtter ikke versjon 

2.0, blant annet Microsofts Windows Communication Foundation (WCF). Profilene til WS-I 

(Web Service Interoperability Organization) bruker også fortsatt versjon 1.1 [210]. Andre 

leverandører som bruker Java, og miljøer som lager åpen kildekode, har imidlertid for lengst 

tatt i bruk den siste versjonen. Mange anbefaler derfor å gjøre tjenester tilgjengelig både i 

WSDL 1.1 og i WSDL 2.0, som to grensesnitt inn mot en og samme implementasjon. 

WSDL oppstod som en standard måte å definere programmeringsgrensesnitt for 

fjernprosedyrekall og overføring av strukturerte dokumenter, basert på 

kommunikasjonsprotokollen SOAP (avsnitt 4.4.2.1), som overfører meldinger med innhold i 

XML over http. WSDL bruker derfor XML Schema (avsnitt 4.5.3.1) til å definere innholdet i 

meldingene. 

Begge hovedversjoner 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 til hvor tjenesten er installert. 

4.2.1.1 Meldingsmønstre for webtjenester 

WSDL skiller mellom ulike mønstre for meldingsutveksling, som porttyper (versjon 1.1) eller 

grensesnitt (2.0). WSDL 1.1 [173] definerer 4 mønstre: 

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. 

WSDL 2.0 definerer i alt åtte standardmønstre [176, 177], 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. 

4.2.1.2 Binding til underliggende transportlag 

Selv om WSDL som oftest er implementert med SOAP som kommunikasjonsprotokoll, støtter 

standarden også andre løsninger. WSDL 1.1 bruker SOAP 1.1, men tilbyr også direkte bruk av 

http GET og POST med parametere, hvor innholdet ikke kodes i XML. MIME (Multipurpose 

Internet Mail Extensions) er en annen mulighet, hvis man ønsker å sende flere deler i ulike 

formater, f.eks. bilder eller dokumenter. Som en alternativ løsning til MIME direkte over http, 

kan man kapsle flere MIME-vedlegg inn i SOAP [164], som blant andre WS-I anbefaler [210]. 

WSDL 2.0 utvider med flere nye transportmuligheter. For å implementere REST (se avsnitt 

4.2.6) kan man nå bruke flere metoder i http, PUT og DELETE i tillegg til GET og POST [176]. I 

tillegg til disse valgmulighetene, kan SOAP bruke andre transportløsninger enn http, som vi 

skal se i avsnitt 4.4.2.1. 

20.01.2010 Versjon 1.1 29/89

DIFI 


4.2.2 Modularisering av tjenester og data 

Webtjenester består av operasjoner. Granulariteten til disse operasjonene bør velges i forhold 

til ytelse og skalerbarhet (mange små kall gir mer overhead enn ett stort), 

transaksjonsegenskaper (slik at man ikke trenger å ta vare på tjenestens tilstand fra en 

operasjon til den neste), og hvor enkel, generell og lett forståelig oppdelingen oppfattes fra 

forretningssiden. 

Grupperingen av operasjoner i større eller mindre tjenester dreier seg mer om forvaltning og 

styring av tjenesteleveransen. De operasjoner som brukes sammen for å oppnå en ønsket 

effekt, bør grupperes sammen som en tjeneste. I noen tilfeller vil man tilby ulike varianter av 

tjenester, som tilbyr ulike mengder av operasjonene for ulike brukerkategorier. Dette kan 

gjøres gjennom å definere ulike tjenester innenfor samme navnerom og fil, eller i ulike 

navnerom dersom man f.eks. ønsker å kunne versjonsstyre tjenestene uavhengig av 

hverandre. For en hensiktsmessig forvaltning er det viktig at strukturen av navnerom styres av 

behovene for vedlikehold. Det er f.eks. bedre om de knyttes til organisering og eierskap, enn 

om de avledes fra interne programstrukturer i implementasjonen av tjenestene. 

WSDL 2.0 tillater arv av operasjoner mellom grensesnitt, og kan således være bedre egnet til 

å håndtere modularisering av tjenester enn forgjengerne. 

4.2.3 Versjonsstyring av tjenester og dataformat 

Tjenester og datastrukturene som de bruker vil utvikle seg over tid, og bør versjonsstyres. Det 

er vanlig å skille mellom hovedversjoner, som ikke er kompatible med tidligere 

hovedversjoner, og underversjoner som er kompatible innefor en hovedversjon. W3C har en 

rekke anbefalinger på dette området [149], som kan tjene som konkretiseringer av 

arkitekturprinsippet om fleksibilitet: 

En spesifikasjon av dataformater bør inneholde versjonsinformasjon. 

Et XML-format bør inneholde regler og føringer for hvordan navnerommene kan endres. 

En spesifikasjon bør tillate utvidelser fra en hvilken som helst partner. 

Utvidelser må ikke ødelegge for konformitet med den opprinnelige spesifikasjonen. 

En spesifikasjon bør definere hvordan partene skal oppføre seg når noe uforutsett 

skjer, f.eks. ”må ignorere” eller ”må forstå” for visse unntak. 

Iona [140] foreslår disse prinsippene for versjonering av WSDL: 

Ikke bruk datoer for versjonering av tjenester, det introduserer et nytt navnerom for 

hver versjon, og skaper unødvendig inkompatibilitet. 

Hovedversjonsnummer for en WSDL-fil bør inkluderes i filnavnet og i navnerommet, for 

styring av kompatibilitet, men ikke underversjonsnummeret. 

Skill datatypene for tjenesten ut som egne navnerom (xsd-filer), heller enn integrert i 

WSDL-filen for tjenesten, og importer dem inn i WSDL. 

Bruk standard konvensjoner for å versjonere navnerom (xsd), altså ved å inkludere 

datoer (gjerne år og måned) eller hovedversjon/underversjon som del av URLen til 

navnerommet. 

Unngå versjonsinformasjon i meldingsnavn, det skaper vanskeligheter for 

kodegeneratorer. 

Inkluder versjonsinformasjon i tjenestens navn (service) og i grensesnittnavnet 

(interface, porttype), slik at hver versjon får sitt eget grensesnitt, og slik at tjeneste og 

grensesnitt har samme navn. 

Nye operasjoner kan legges til i underversjoner. WSDL 2.0 tillater arv av operasjoner 

mellom grensesnitt, og dermed kan en ny underversjon arve fra sin forgjenger. 

Endringer i eksisterende operasjoner krever en ny hovedversjon. 

Enhver endring av datatyper (xsd) krever en ny hovedversjon. 

20.01.2010 Versjon 1.1 30/89

DIFI 


Oppretthold gamle hovedversjoner så lenge noen av brukerne ikke har migrert til nyere 

versjoner. 

Intalio [51] foreslår prinsipper for versjonering av prosesser, i tråd med anbefalingene over. 

4.2.4 Standarder tilknyttet WSDL 

Figuren nedenfor gir oversikt over de mange standarder som er tilknyttet WSDL, og som 

beskrives i resten av dette kapittelet. Standardene kommer fra W3C (hvit), OASIS (grå) eller 

andre (mørk grå, stiplet kant). 

Interaksjon, komposisjon, 

prosess 

Data 

XPDL 

WS-CDL 

Choreography 

Tjenester og mellomvare 

WS- 

Inspection 

Kommunikasjon 

XML 

Namespaces 

XML Infoset 

BCM 

CAM 

WS-BPEL 

WS- 

Transaction 

UDDI 

XSLT 

XPath 

WS-Remote 

Portlets 

XForms 

WS-CAF 

Context 

WS- 

Discovery 

4.2.5 Profiler for webtjenester 

XML Schema 

1.0 

XML Schema 

1.1 

Figur 8. Oversikt over standarder for webtjenester. 

WS-I [209, 210] er en industriorganisasjon som betrakter seg som en bindeledd mellom 

utviklere av standarder og brukere av dem. De 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. Mange leverandører av verktøy for 

tjenesteorientert arkitektur hevder å følge profilene til WS-I, og profilene definerer også 

mekanismer for å inkludere slike påstander i WSDL-beskrivelsene til tjenestene. De første 

versjonene av deres basisprofil [209] er også standardisert som ISO/IEC 29362:2008. 

Basisprofilen har utviklet seg slik [209, 210]: 

Sikkerhet og pålitelighet 

WS-Secure 

Conversation 

WS-Reliable 

Messaging 

WS-Metadata 

Exchange 

WSDL 1.1 WSDL 2.0 

SOAP 1.1 

WS- 

Adressing 

XML 1.0 

WS-Trust 

WS-Security 

WS-Security 

Policy 

WS-Policy 

SOAP 1.2 

WS- 

Federation 

SOAP with 

Attachments 

SOAP MTOM 

XOP EXI 

Forvaltning 

WS- 

Enumeration 

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 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). 

o 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. 

20.01.2010 Versjon 1.1 31/89 

SPML 

SAML 

WS- 

Fragment 

MIME 

WS- 

Management 

WS-Eventing 

WS-Resource 

Framework 

WS-Resource 

Transfer 

WS-Transfer 

WSDM 

WS- 

Notification 

XML 

Signature 

XML 

Encryption

DIFI 


Versjon 1.2 (klar til styrets godkjenning) legger til MTOM og WS-Adressing, og bruker 

Attachments Profile heller enn SSBP for binding til SOAP. 

Versjon 2.0 (utkast fra arbeidsgruppe) går over til SOAP 1.2, og refererer dessuten til 

XOP. 

WSDL 2.0 og UDDI 3 er altså ennå ikke tatt med, selv om disse standardene har vært 

tilgjengelige i flere år, og WSDL 2 i motsetning til WSDL 1.1 faktisk er en godkjent standard. 

Dette reflekterer utbredelsen de ulike versjonene har blant leverandører og brukere. De øvrige 

standardene blir beskrevet i resten av dette kapittelet. I avsnitt 4.8 diskuterer vi dessuten 

sikkerhetsprofilene til WS-I. 

4.2.6 REST 

REST (Representational State Transfer) [30] 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 XML-dokument, 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 webtjenester 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. 

4.2.7 ebXML for eHandel 

ebXML er en samling standarder utarbeidet av OASIS og FN for elektronisk handel og annen 

samhandling på tvers av organisasjoner. Målsetningen er å definere en åpen, XML-basert 

standard for å støtte den globale bruken av elektronisk forretningsinformasjon i en felles, 

sikker og konsistent måte for alle handelspartnere. 

ebXML ble utviklet tidlig på 2000-tallet som neste generasjons EDI (Electronic Data 

Interchange). Arbeidet stammet fra ooEDI (objektorientert EDI), UML/UMM, XML-teknologi og 

X12 EDI. ISO aksepterte ebXML som standard i 2007, med følgende deler: 

ISO 15000-1: ebXML Collaborative Partner Profile Agreement 

ISO 15000-2: ebXML Messaging Service Specification 

ISO 15000-3: ebXML Registry Information Model 

ISO 15000-4: ebXML Registry Services Specification 

ISO 15000-5: ebXML Core Components Technical Specification 

20.01.2010 Versjon 1.1 32/89

DIFI 


ebXML og RosettaNet (beskrevet nedenfor) var lenge viktig for å adressere svakheter ved web 

services. Etter hvert som web service standarder har modnet og tatt opp i seg gode løsninger 

fra andre områder, så har konkurrerende initiativ gjerne fokusert på tilstøtende områder. I dag 

kan ebXML tilby en offisiell standard for elektronisk meldingsutveksling, og de har også 

definert nyttige standarder for informasjonsinnholdet i meldinger (Core Components). 

ebXML er i likhet med web services basert på SOAP, men de tilbyr utvidet funksjonalitet for 

håndtering av sikkerhet, pålitelighet, forretningstransaksjoner og annet som er sentralt for 

elektronisk samhandling. I Norge har KITH definert et rammeverk for meldingsutveksling i 

helsesektoren basert på ebXML [68]. Dette brukes for kommunikasjon mellom foretak, mens 

web services brukes internt i hvert helseforetak [69]. Standardene innen ebXML utvikles ikke 

videre, men de er i bruk, og metodene som ligger til grunn blir i stadig større grad 

implementert i web service standarder. I nyere løsninger for eHandel, som PEPPOL [28], 

bruker de primære transportløsningene WSDL, selv om ebXML er fortsatt er tillatt. WSDL og 

ebXML tilbyr ulike løsninger på flere nivåer: 

Område Web service standarder ebXML standarder 

Prosess BPEL 

Tjeneste WSDL 

BPSS, CPP/CPA 

Register UDDI ebXML Registry 

Meldinger SOAP SOAP, ebMS 

Informasjon XML Schema Core components 

XML Schema 

4.2.7.1 ebXML Messaging Service (ebMS) 

ebMS er en utvidelse av SOAP som forbedrer sikkerhet og pålitelighet. Den kan brukes 

uavhengig av de andre komponentene i ebXML. Dette er da også den eneste komponenten 

som brukes i standarden for norsk helsevesen [68]. ebMS bruker SOAP med vedlegg [164] og 

MIME med flere deler til å definere en ebXML melding bestående av konvolutt og innhold, med 

hode og kropp. Innholdet kan ha andre formater enn XML, og kan også krypteres for sikker 

overføring. Konvolutten benyttes til å identifisere avsender og mottager, selve meldingsutvekslingen 

og tidspunkt for denne, saken eller forretningsprosessen det gjelder, samt 

eventuelt hvilken større interaksjon denne meldingen tilhører [68]. 

4.2.7.2 ebXML Registry & Repository 

Dette registeret gjør tilgjengelig informasjon om mulig handelspartnere, og de tjenester de 

tilbyr. Informasjonen om partnere (Trading Partner Information) lagres i registeret i XMLformat, 

og inkluderer 

Collaboration Protocol Profile (CPP), en formell beskrivelse av meldingsutvekslingen 

som en part tilbyr, og de samarbeidsmønstre (collaborations) den støtter. 

Collaboration Protocol Agreement (CPA) definerer det to parter må være enige om for å 

kunne samhandle, et snitt av to CPPer. Slike avtaler kan brukes til å skreddersy 

systemene på hver side. 

Registre for web services beskriver først og fremst selve tjenestene, ikke de som tilbyr dem, 

selv om nyere versjoner også har tatt opp i seg flere av elementene fra ebXML (se avsnitt 

4.3.2.1). 

4.2.7.3 Business Process Specification Schema (BPSS) 

BPSS spesifiserer forretningstransaksjoner og koreografien av transaksjoner til helhetlige 

samhandlingsmønstre. BPSS modelleres i UML, og blir konvertert til XML. Her tilbyr man altså 

en integrert høynivå beskrivelse av prosesser som kan forstås av brukere. Web services kan 

settes sammen til prosesser ved hjelp av det mer tekniske språket BPEL (avsnitt 4.7.1), og 

20.01.2010 Versjon 1.1 33/89

DIFI 


brukernivå prosessbeskrivelser i f.eks. BPMN må konverteres til BPEL. BPSS brukes dessuten 

til å beskrive standard interaksjonsmønstre for elektronisk handel, og en katalog av felles 

forretningsprosesser. 

4.2.7.4 Core Components 

I likhet med WSDL bruker ebXML XML Schema til å definere informasjonsinnholdet i kall til 

tjenester og de dokumenter som utveksles mellom partnere i en samhandling. Core 

Components tilbyr et rammeverk på toppen av dette for å definere standard språk for 

forretningstransaksjoner generelt, og spesielt innenfor ulike sektorer. Eksempler på dette blir 

beskrevet i avsnitt 4.5.5.1. 

4.2.8 RosettaNet 

RosettaNet [136] fokuserer på innkjøp og logistikk, og mer generelt på samhandling mellom 

organisasjoner. Deres standarder er særlig utbredt innen elektronikkindustrien. De 

standardiserer meldingsformater og ”offentlige prosesser” mellom partnerne, men ikke interne 

prosesser. I likhet med ebXML kan dette ses på som neste generasjons EDI-løsning, ved hjelp 

av XML. RosettaNet ser på seg selv som en vertikal standardiseringsaktivitet som kan bygges 

på toppen av andre standarder som web services og ebXML. Rundt 2000 firmaer bruker dette 

rammeverket, etter en jevn vekst siden 2001. 

4.2.8.1 Protokoller for forretningstransaksjoner - PIP 

RosettaNets Partner Interface Processes (PIPs) definerer forretningsprosesser mellom 

handelspartnere, uten å detaljere de interne aktivitetene innen hver organisasjon. De avbilder 

aktiviteter, beslutninger og interaksjoner som inngår i en forretningstransaksjon, struktur og 

format på meldingene som skal utveksles. Spesifikasjonene er organisert etter industrisektorer 

og funksjoner. RosettaNet har et PIP Directory hvor medlemmer kan finne fram eksisterende 

definisjoner, for gjenbruk og interoperabilitet. 

4.2.8.2 Enklere introduksjon for små og mellomstore virksomheter 

RosettaNet Automated Enablement (RAE) er et program som skal sette mindre bedrifter i 

stand til å delta i elektronisk samhandling, gjennom å redusere kravene til tid, kostnad og 

teknisk modenhet for å implementere en PIP. Dette støttes gjennom å automatisere 

utrullingen av en Trading Partner Implementation Requirements (TPIR), som lar 

handelspartnere definere ytterligere begrensninger i tillegg til de som ligger i en standard PIP. 

RAE tilbyr dessuten løsninger for brukerinteraksjon, slik at mindre bedrifter får enkle 

grensesnitt for å legge inn den informasjonen som trengs i de forskjellige meldingene, også 

uten en intern skjema- eller prosessmotor. 

4.2.8.3 Engineering Information Management 

RosettaNet har de siste årene fokusert på standardisering av forretningsprosesser, samordning 

av verdikjeder, og informasjonsutveksling innen elektronikkindustrien, under programmet 

Engineering Information Management. De har utviklet tekniske spesifikasjoner for utveksling 

av informasjon om produkter (Engineering Information Property Sets - EIPS), og for typiske 

forretningsprosesser knyttet til dette, som fakturering, datafangst, endringshåndtering, 

lagerstyring og resirkulering. 

4.2.8.4 Dictionaries 

Dictionaries definerer felles datatyper og egenskaper som kan brukes i ulike PIPer. Business 

Dictionary definerer egenskaper til grunnleggende forretningsaktiviteter, mens Technical 

Dictionaries definerer egenskaper for ulike produkter. RosettaNet samarbeider dessuten med 

UN/CEFACT om å definere informasjonsinnhold i ebXML Core Components (se over). 

4.2.8.5 Implementasjon - RosettaNet Implementation Framework 

RosettaNet Implementation Framework (RNIF) spesifiserer løsninger for pakking, ruting og 

transport av meldinger som inngår i en PIP. 

20.01.2010 Versjon 1.1 34/89

DIFI 


4.2.8.6 Multiple Messaging Services 

Multiple Messaging Services (MMS) sørger for at RosettaNets XML-meldinger kan utveksles 

over ulike infrastrukturer. Spesifikasjoner for web services, AS2 og ebMS er utviklet. 

4.2.9 Semantiske tjenestebeskrivelser 

Flere metoder er foreslått for semantisk berikelse av webtjenester, som WSDL-S [185], OWL-S 

[156], og WSMO/WSML (Web Service Modeling Ontology/Language). SAWSDL (Semantic 

Annotations for WSDL and XML Schema) [159] er en standard fra W3C som sprang ut av dette 

arbeidet. Semantiske beskrivelser tilstreber en formell, utvetydig og maskinell tolkbar form, og 

dette preger teknologiene, selv om flere og flere innser at det er viktig med formater som er 

lette å forstå for mennesker. Semantisk berikelse skal gjøre det enklere å finne fram til riktige 

webtjenester i en katalog, og kan også åpne for regelstyring av applikasjoner. 

SAWSDL legger inn lenker (semantiske annotasjoner) til standard begrepsmodeller 

(ontologier) i WSDL-filene. Dette kan brukes til å definere startbetingelser (precondition) og 

effekter til operasjoner, og for å kategorisere datainnhold og tjenester (modelreference). 

Løsningen bygger på standard utvidelsesmekanismer for WSDL og XML Schema. SAWSDL 

endrer kun WSDL-filene. Annoteringene har ingen påvirkning på SOAP-kommunikasjonen 

under bruk av tjenestene. 

4.3 Mellomvare 

I plattformer for tjenesteorientert arkitektur er en tjenestebuss (Enterprise Service Bus – ESB) 

som oftest den sentrale mellomvaren [10]. Utover direkte overføring av meldinger mellom 

tjenesteleverandøren og de ulike brukerne, tilbyr en slik komponent disse kjernefunksjonene 

[6]: 

Ruting av meldinger, slik at f.eks. innholdet kan styre hvilken tjenesteyter som skal 

behandle forespørselen, 

Transformering av meldingsinnholdet mellom tjenestebrukers og leverandørens 

formater, 

Validering av meldinger, at innhold og format er i henhold til tjenestekontrakt og 

grensesnitt. 

Ved siden av kjernefunksjonene for meldingshåndtering, så tilbys ofte: 

Tjenestekatalog hvor alle tilgjengelige tjenester beskrives, 

Oppfanging og kringkasting av hendelser til tjenester som skal reagere på dem, 

Eksekvering av prosesser og andre sammensatte tjenester, 

Modellering for utvikling og komposisjon av tjenester, 

Regelmotorer for forretninglogikk, kompleks meldingsruting og prosessflyt, 

Lager for metadata som definerer gjenbrukbare datamodeller, 

Forvaltningstjenester for å logge og overvåke driften, håndtere sikkerhet og 

adgangskontroll, versjonering, feilrapportering m.m., 

Grensesnitt og koblingspunkter mot andre omgivelser og virksomhetens IKT-løsninger. 

f.eks. ERP, CRM, HR m.m. 

Ved siden av en tjenestebuss finner man gjerne tilknyttede komponenter for [6] 

Engangs innlogging (Single Sign On - SSO) og distribuert identitetshåndtering 

Brukergrensesnitt og portaler 

Kontraktsforvaltning og fakturering 

Overvåking av forretningsprosesser og –aktiviteter 

Automatisk kontroll av at tjenestereglementene etterleves 

20.01.2010 Versjon 1.1 35/89

DIFI 


Forvaltning av kildedata og eierskap til data 

En buss skiller seg fra en hub ved at datatransporten er desentralisert. I begge arkitekturene 

er forvaltningen og styringen sentralisert. 

4.3.1 Ulike typer mellomvare 

Skillet mellom applikasjonsintegrasjon (EAI) [9] og tjenesteorientert arkitektur [6] blir stadig 

mindre etter hvert som tjenestebusser tilbyr flere og flere koblingspunkter mot proprietære 

applikasjoner, databasesystem og stormaskinomgivelser, mens mellomvare for EAI støtter de 

fleste standarder for webtjenester. De tekniske løsningene er også overlappende. Dette 

avsnittet ser derfor på ulike typer mellomvare, som man også vil finne i tjenesteorienterte 

arkitekturer. 

4.3.1.1 Fjernprosedyrekall 

Denne enkleste formen for integrasjon var utgangpunkt for tidlig eksperimentering og 

standardisering innen tjenesteorientert arkitektur. I en slik løsning kaller en programtjeneste 

opp en operasjon i en annen omgivelse direkte. Kallet foretas synkront, og mellomvaren 

sørger for at løsningsutviklerne ikke trenger å bry seg om kommunikasjonskanalen. 

Brukerprogrammet kan dermed forholde seg til distribuerte tjenester på sammen måte som 

lokale. 

Fjernprosedyrekall (Remote Procedure Call - RPC). skaper betydelig overhead, og en 

nettverkstrafikk som ikke skalerer bra oppover. Synkron kommunikasjon gjør løsningen dårlig 

egnet over ustabile kommunikasjonskanaler som internett [9]. 

4.3.1.2 Meldingsorienterte løsninger (MOM) 

Meldingsorientert mellomvare (MOM) ble utviklet for å adressere svakheter ved synkrone 

fjernprosedyrekall. MOM innefører en meldingskø mellom sender og mottager [9]. 

Meldingskøen kan garantere persistens ved driftsavbrudd og sikker overlevering av 

meldingene, og gjør det mulig å bygge ytterligere funksjonalitet beskrevet i innledningen til 

dette avsnittet. 

MOM kan rute meldinger etter direkte adressering, eller i en løst sammenkoblet arkitektur hvor 

mottakerne abonnerer på meldinger om bestemte tema eller hendelser. Muligheter for å 

distribuere meldingskøen gir god skalerbarhet, med asynkron kommunikasjon som er egnet 

for internett. Den viktigste svakheten er at responstider ikke kan garanteres [9]. 

Java Message Service (JMS) er et åpent grensesnitt for MOM som gjør det mulig å 

opprettholde en løs kobling mellom mellomvaren og applikasjonene som bruker den. 

4.3.1.3 Distribuerte objekter og komponenter 

Distribuerte objekter legger et abstraksjonslag på toppen av RPC som gjør prosedyrekallene 

uavhengig av underliggende språk, nettverk og teknologiplattform [9]. De mest kjente 

eksemplene er OMGs CORBA, og Microsofts DCOM. I disse arkitekturene trenger ikke 

applikasjonene som bruker tjenester fra objekter og komponenter å vite hvor de er lokalisert. 

4.3.1.4 Transaksjonsorienterte løsninger 

Transaksjonsprosessering på tvers av applikasjoner er en utfordring som har skapt en egen 

type mellomvare. For å sikre applikasjonenes og databasenes integritet, sørger disse 

komponentene for at alle oppdateringer rulles tilbake hvis et ledd i en transaksjon feiler, på 

tvers av systemer og databaser. Disse løsningene har vokst videre til applikasjonstjenere, som 

også tilbyr balansering av belastning, overflytting til annen tjener ved feil, gjenbruk av 

databasetilkoblinger, og tjenester for å koble til eksterne systemer. Dette gir en skalerbar og 

robust løsning, men skaper en tett knytning mellom applikasjonene og mellomvaren. 

4.3.1.5 Meldingsmeglere 

Meldingsmeglere (message brokers) støtter transformasjon, lagring og ruting av meldinger 

basert på hendelser og regler, på toppen av MOM. 

20.01.2010 Versjon 1.1 36/89

DIFI 


4.3.2 Beskrivelse og oppdagelse av tjenester 

Standardene vi så på i avsnitt 4.2, i første rekke WSDL, definerer det tekniske grensesnittet til 

en tjeneste, med operasjoner, kommunikasjonsprotokoller og meldingsformater. Standardene 

nedenfor kan brukes til å gi tilgang til slike beskrivelser, og til å utvide beskrivelsene med mer 

informasjon om tjenestene. 

4.3.2.1 UDDI - Universal Description, Discovery, and Integration 

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 [93] oppdaterte til nye standarder for web services, og innførte metoder for 

klassifisering av tjenester. Versjon 3 [94] legger til sikker interaksjon mellom åpne 

samhandlingsløsninger og lukket intern implementasjon av tjenester. 

UDDI er posisjonert som katalog også for ebXML [95], og har delvis tatt over for deres 

registre. Katalogene var opprinnelig tenkt brukt til elektronisk samhandling, gjennom et slags 

”gule sider” hvor kunder kunne bruke til å finne ulike leverandører av tjenestene de etterspør. 

Denne bruken tok ikke av. En av grunnene til dette er at tekniske grensesnitt som WSDL ikke 

gir all den informasjon om en tjeneste som trengs for å kunne foreta en forretningsmessig 

vurdering. ebXML og RosettaNet gikk lenger i å dekke virksomhetsnivået, ved å definere 

standard prosesser og meldingsinnhold, og gjennom å knytte seg opp til konkrete initiativ i 

ulike bransjer. 

Etter hvert har UDDI i langt større grad blitt brukt i virksomhetsinterne tjenestearkitekturer, 

som en av flere komponenter i en tjenestebuss. Her holder katalogen oversikt over hvilke 

tjenester som er tilgjengelig fra hvem, og hjelper til å støtte distribusjon og forvaltning. Dette 

gjør en løsere kobling mellom bruker og leverandør mulig, og gir robusthet ved driftsavbrudd 

hos en installasjon av en tjeneste. 

UDDI gjør en føderasjon av kataloger mulig. En katalog i UDDI kan bestå av flere noder, f.eks. 

satt opp av ulike organisasjoner. Flere kataloger kan også kobles sammen slik at de deler 

navnerom for identifikasjon av elementer. Dette er blant annet nyttig for å koble sammen 

interne og åpent tilgjengelige kataloger. 

4.3.2.2 WS-Inspection 

WS-Inspection Language (WSIL) er et forslag fra IBM og Microsoft til en felles standard for å gi 

en samlet oversikt over de forskjellige webtjenestene som en leverandør tilbyr. Sammenlignet 

med UDDI tilbyr WSIL en enklere, mer teknisk oversikt over tjenester. Gjennom bruk av 

nøstede referanser mellom spesifikasjonsdokumenter, følger WSIL en desentralisert 

tilnærming. WSIL var ment å ta over for Microsofts DISCO og lignende proprietære løsninger, 

men verktøystøtten er begrenset [6]. 

4.3.2.3 WS–Discovery 

Denne standarden fra OASIS har Web Services Dynamic Discovery [103] som fullt navn. Den 

gjør det mulig å forespørre et dynamisk nettverk av registrerte tjenere om hvem som tilbyr en 

gitt tjeneste. Tjenergruppene kan jobbe ad-hoc, ved at alle forespørsler kringkastet, eller i 

styrt modus, hvor en sentral tjener (discovery proxy) mottar forespørslene og sender dem 

videre bare til aktuelle registrerte tilbydere. Hvis den sentrale tjeneren blir utilgjengelig, går 

gruppen tilbake til å operere ad-hoc. Styrt modus skalerer bedre til store nettverk. 

Sammenlignet med UDDI er WS-Discovery en enklere løsning, som egner seg bedre for 

tjenester som ikke alltid er tilkoblet nettet, eller andre former for dynamiske nettverk. 

Gjennom at man ikke har noen sentral katalog, men i stedet oppdager dynamisk hvilke 

tilbydere som er tilgjengelig i den omgivelsen man til enhver tid befinner seg i, unngår man 

alle problemer med utdaterte kataloger. 

4.3.2.4 WS-Policy 

Web Services Policy Framework [182] spesifiserer et XML-format som tilbydere kan bruke til å 

beskrive sin oppførsel på ulike områder som sikkerhet og tjenestekvalitet. Det kan også 

20.01.2010 Versjon 1.1 37/89

DIFI 


brukes av kunder for å spesifisere krav til disse egenskapene. Rammeverket definerer 

dessuten byggesteinene som andre spesifikasjoner kan bruke til å definere språk for å 

uttrykke mer spesialiserte regler, noe som brukes bl.a. i WS-SecurityPolicy (avsnitt 4.8.4.1), 

WS-Transaction (4.7.5) og WS-ReliableMessaging (4.8.7). 

Regler (policies) bygges opp hierarkisk ved hjelp av logiske operatorer som sier om alle eller 

bare en av delreglene (assertions) trenger å være oppfylt. Noen regler kan være rådgivende 

(ignorable, optional), andre er obligatoriske. Regler kan referere til andre regler, og bruke dem 

som delregler. 

WS-Policy Attachments [183] knytter regler til subjektene som de gjelder for. En 

regeltilknytning (policy attachment) er en mekanisme som knytter regler til et område (policy 

scope) av subjekter. Tilknytningen kan foretas på to måter: Integrert som en del av 

metadataene om subjektet, eller med en uavhengig spesifikasjon som knyttes til subjektet 

gjennom en ekstern binding. Spesifikasjonen viser hvordan dette kan brukes til å knytte regler 

til elementer i XML, WSDL og UDDI. 

4.3.2.5 WS-Metadata Exchange 

Web Service Metadata Exchange [178] er en spesifikasjon under utvikling fra W3C. Den angir 

en standard utvidbar måte å representere informasjon om en tjeneste på, å publisere, finne 

fram og hente ut slik informasjon. WSDL beskriver operasjoner, meldinger og adressen til 

tilbyderen, mens WS-Policy (se over) beskriver tjenestens evne til å håndtere transaksjoner og 

pålitelig kommunikasjon. Denne standarden kan brukes til alle andre metadata. De kan enten 

hentes ut gjennom direkte forespørsel (pull), eller inkluderes i meldingshodet (push) i tråd 

med WS-Addressing (avsnitt 4.4.4). Alle metadata om en tjeneste kan hentes ut i en 

operasjon, eller filtreres i henhold til hva mottakeren ber om. 

4.3.3 Teknisk styring og drift av tjenester 

De forrige avsnittene tok for seg grunnleggende metoder for å gjøre informasjon om tjenester 

tilgjengelig for brukerne. Vi tar nå for oss standarder som bygger videre på dette for å styre 

leveranse og forvaltning av tjenester. 

4.3.3.1 WSDM – Distributed Management 

WSDM [104] er en standard fra OASIS som definerer et grensesnitt som styringsverktøy kan 

bruke til å hente informasjon ut fra tjenesteorientert mellomvare. Informasjonen kan deretter 

knyttes sammen med annen status- og styringsinformasjon, og presenteres til brukerne 

gjennom dashboards eller lignende. Slik kan man integrere drift og forvaltning av heterogene 

tekniske arkitekturer. Styringsinformasjonen er tilgjengelig gjennom oppslag (push) eller 

gjennom abonnering på beskjed om hendelser (pull ved hjelp av WS-Notification, se avsnitt 

4.4.3.2). 

WSDM består av to spesifikasjoner: 

Management Using Web Services (MUWS) 

Management Of Web Services (MOWS) 

MUWS definerer hvordan man kan representere og aksessere forvaltningsgrensesnitt for 

ressurser, inkludert webtjenester. Basis egenskaper som identitet, måleparametere for ytelse 

og tilgjengelighet, konfigurering og avhengigheter kan settes sammen til et helhetlig styringssystem. 

MOWS beskriver hvordan webtjenester kan forvaltes som ressurser i tråd med MUWS. 

MOWS definerer mekanismer og metoder for hvordan webtjenester kan forvaltes i en 

interoperabel arkitektur på tvers av virksomhetsgrenser. 

4.3.3.2 WS-Management 

WS-Management er en SOAP-basert standard som maskinvare, applikasjoner og webtjenester 

kan bruke til å publisere informasjon om seg selv og sin status, slik at de lettere kan styres og 

forvaltes [22]. Den spesifiserer følgende funksjoner: 

Oppdagelse av forvaltningsressurser og navigasjon mellom dem, 

20.01.2010 Versjon 1.1 38/89

DIFI 


Opprettelse, lesing, oppdatering og sletting av parametre og verdier for systemforvaltningen, 

Gi oversikt over innholdet i samlinger av ressurser, parametere, logger, 

Abonnering slik at forvaltningskomponenter får beskjed om hendelser som de bør 

reagere på, 

Utførelse av parametriserte forvaltningsmetoder. 

WS-Management er koblet opp til en felles informasjonsmodell for tjenesteforvaltning (CIM) 

som også er standardisert av DMTF. WSDM og WS-Management tilbyr overlappende 

funksjonalitet, og IBM, en av sponsorene bak WSDM, har sammen med Microsoft, HP og Intel 

beskrevet hvordan de to standardene kan kobles sammen [47]. 

WSDM bruker andre standarder fra OASIS, som WS-Notification og WS-Resource Framework. 

WS-Management bygger først og fremst på standarder fra W3C, som WS-Transfer, og 

industriforslag som WS-Eventing og WS-Enumeration. Disse standardene er beskrevet 

nedenfor, i avsnitt 4.4.3 og 4.5.8. 

WS-Management har etter hvert fått mest støtte fra industrien. Samtidig er WSDM mer rettet 

inn mot forvaltning av webtjenester, mens WS-Management er drevet fram av 

maskinvareleverandører, og de to løsningene kan samvirke [47]. 

4.3.3.3 WS-Transfer og WS-ResourceTransfer 

WS-Transfer [187] definerer webtjenester for å hente ut informasjon om ressurser og 

ressursfabrikker som kan opprette nye ressurser. Tjenestene følger typisk mønster fra REST, 

med opprettelse, lesing, skriving og sletting. Ressurser er i denne sammenhengen 

endepunkter i henhold til WS-Adressing (avsnitt 4.4.4). 

WS-Fragment [181] utvider WS-Transfer med mekanisme som tillater klienter å hente ut eller 

endre deler av en ressurs, uten at man trenger å overføre hele ressursen. 

I likhet med til WS-Transfer, som den bygger på, er WS-ResourceTransfer nå utkast til 

standard i W3C [184]. Målet er å støtte felles krav fra WS-Management og WS- 

ResourceFramework (se nedenfor), samt inkorporere andre standarder for sikker, pålitelig og 

transaksjonsbasert meldingsutveksling. En viktig utvidelse er mulighet til å adressere deler av 

en ressurs (fragmenter), ikke bare ressursen som helhet. 

4.3.3.4 WS-Resource Framework 

WSRF [108] definerer et åpent rammeverk for aksess til ressurser og deres tilstander, 

gjennom webtjenester. Dette er altså det motsatte av REST (avsnitt 4.2.6) som forutsetter 

tilstandsløse ressurser. Poenget er å håndtere situasjoner hvor meldinger kan gi ulike svar 

avhengig av tjenestens tilstand, for eksempel for å implementere sekvenser i en 

interaksjonsprotokoll. WSRF har 5 deler: 

WS-Resource som definerer hva en ressurs er og hvordan en webtjeneste kan bli 

identifisert og behandlet som en ressurs, 

WS-ResourceProperties brukes til å definere egenskapene til en tjeneste, og deres 

verdier, gjennom standard operasjoner i tråd med REST (Get, Set, Update, Insert, 

Delete), 

WS-ResourceLifetime definerer standard egenskaper knyttet til ressursens livsløp, dens 

opprettelse, bruk og sletting, 

WS-BaseFault definerer standard feilmeldinger for de ulike operasjonene i WSRF, 

WS-ServiceGroup, som gjør at man kan bruke mekanismene over på grupper av 

tjenester, ikke bare enkelttjenester. 

4.3.3.5 SML - Service Modeling Language 

SML [160] er en standard fra W3C (2009), utviklet av Microsoft, IBM, HP m.fl. SML definerer 

en notasjon i XML for å modellere komplekse systemer og tjenester, deres struktur, 

20.01.2010 Versjon 1.1 39/89

DIFI 


begrensninger, oppførselsregler og beste praksis. Formålet er først og fremst å styre 

forvaltning og drift av systemene, inkludert maskinvare og basis programvarekomponenter, 

fra ulike leverandører. SML er foreslått som språk for innholdet i WSDM/WS-Management [47]. 

SML bruker XSLT og Schematron til å uttrykke logiske regler (boolean), og SML-spesifikasjoner 

holdes adskilt fra de operative spesifikasjonene som inngår i løsningen, slik som filer med 

WSDL og XSD. Ved siden av kjernespråket, definerer SML et utvekslingsformat kalt SML-IF, og 

mekanismer for å definere lenker mellom spesifikasjoner, bygd på toppen av XLink. 

4.4 Kommunikasjon 

Kommunikasjonsstandarder ligger selvfølgelig under enhver meldingsutveksling i 

tjenesteorienterte arkitekturer, men transportstandarder er ikke spesifikke for denne 

anvendelsen. Dette avsnittet tar kort for seg de standarder som er fundamentale for 

tjenestekommunikasjon eller utviklet spesielt for en slik arkitektur. 

4.4.1 Metoder for meldingsutveksling 

Meldingsutveksling kan implementeres på mange måter. Disse kan beskrives som mønstre 

innen følgende områder [46]: 

Uforming av meldinger for kommandoer, dokumentoverføring eller beskjed om 

hendelser, mønstre for meldingsutveksling med spørsmål og svar (se avsnitt 4.2.1.1), 

meldinger som inneholder svaradresse, korrelasjon som sørger for å identifisere hva en 

melding besvarer, oppdeling av store datamengder til sekvenser av mindre meldinger, 

regler for når en melding blir utdatert, og versjonsstyring av meldingsformater. 

Meldingskanaler for punkt-til-punkt kommunikasjon, abonnering og kringkasting, 

kanaler som skiller mellom ulike typer meldinger, egne kanaler for håndtering av 

feilaktige meldinger eller meldinger som systemet ikke klarer å sende til mottaker, 

kanaler med garantert leveranse, kanaladaptere for å koble til eksterne system, broer 

mellom ulike meldingssystem, og meldingsbusser for løs sammenkobling. 

Tilkobling av endepunkter gjennom en synkron eller asynkron gateway, ofte med 

transformering av meldinger til interne formater, transaksjonshåndtering, med jevnlig 

sjekk om det har kommet nye meldinger, eller hendelsesdrevet reaksjon på hver enkelt 

melding. Flere mottakere kan konkurrere om å ta i mot forespørsler på samme kanal, 

eller la dem fordeles av en sentral megler, kanskje avhengig av meldingens type. 

Kanskje trenger man en stabil abonnent som kan lagre meldinger når mottakeren ikke 

er tilgjengelig, og funksjonalitet som sorterer ut duplikatmeldinger? Sist men ikke 

minst, hvordan kan man sørge for at en melding aktiverer en tjeneste hos mottakeren? 

Ruting gjennom filtrering og fordeling av meldinger på ulike kanaler, gjerne styrt av 

meldingens innhold, med lokale filtre som sorterer ut uinteressante meldinger – 

avhengig eller uavhengig av mottakerens tilstand, dynamiske rutere som tillater at 

kanaler legges til eller blir fjernet, distribusjon til dynamiske mottakerlister, oppsplitting 

av meldinger i deler som sendes til ulike adressater, aggregering av delmeldinger, 

sortering av meldinger tilbake til riktig rekkefølge, spredning og samling når samme 

melding kan besvares av flere, omgåelse av steg avhengig av innhold eller tilstand, 

regel- eller prosessmotorer for ruting, og meglere som kobler sender og mottaker fra 

hverandre og sørger for sentral styring med kommunikasjonen. 

Transformering og oversettelse av innholdet i meldingene, mellom ulike datastrukturer, 

datatyper, representasjonsformater og kommunikasjonsprotokoller. Dette inkluderer 

pakking i og åpning av konvolutter, berikelse av innhold ved hjelp av tilknyttede 

databaser, filtrering for forenkling av innholdet, validering av data, normalisering av 

data fra ulike kildeformater til ett felles format, og definisjon av felles, kanoniske 

datamodeller for mange aktører. 

Systemforvaltning gjennom en egen styringsbuss på tvers av ulike systemer, 

teknologier og lokaliseringer, gjennom å rute meldinger om en omvei for validering, 

testing og diagnose av feil, eller gjennom ”avlytting” av trafikken. Andre teknikker 

20.01.2010 Versjon 1.1 40/89

DIFI 


inkluderer logging av historikk og kanskje lagring av alle overførte meldinger, smart 

proxies som tar vare på returadressene til meldingene, egne testmeldinger underveis i 

en strøm av meldinger, og metoder for å tømme kanaler for utdaterte og uønskede 

meldinger. 

Som vi skal se nedenfor, implementerer standardene for meldingsutveksling i 

tjenesteorienterte arkitekturer ulike kombinasjoner av disse mønstrene. 

4.4.2 Standarder for direkte kall til tjenester 

Her ser vi på de grunnleggende standardene for meldingsutveksling. Etterfølgende delavsnitt 

tar for seg protokoller for mer avanserte meldingsmønstre, forbedret sikkerhet eller ytelse på 

toppen av disse metodene. 

4.4.2.1 SOAP 

SOAP er den dominerende protokollen for meldingsutveksling i tjenesteorienterte arkitekturer. 

SOAP overfører meldinger i XML-format over http, og kan derfor gå gjennom typiske 

brannmurer som er stengt for tidligere løsninger som Corba, DCOM og Java RMI. Både versjon 

1.1 [161] og 1.2 [162, 163] er i utstrakt bruk sammen med WSDL 1.1 og 2.0. SOAP erstattet i 

sin tid tidligere løsninger for fjernprosedyrekall med XML over http, som XML-RPC [208]. 

SOAP er en fleksibel protokoll, uavhengig av programmeringsstiler, språk og plattformer. SOAP 

kan bindes til forskjellige underliggende transportstandarder. I standarden er det kun definert 

bindinger til http. 

SOAP definerer en meldingsstruktur bestående av konvolutt og innhold. Konvolutten beskriver 

hva meldingen inneholder og hvordan den skal behandles. Standarden definerer dessuten ulike 

måter å kode innholdet på i XML, og ulike mønstre for meldingsinteraksjon med forespørsler 

og svar. 

W3C har dessuten foreslått en metode for å knytte SOAP-meldinger sammen med innhold som 

har annet format enn XML, som vedlegg etter MIME-standarden [164]. Denne løsningen 

anbefales blant annet for ebXML og av WS-I [210]. 

4.4.2.2 MTOM - Message Transmission Optimization Mechanism 

SOAP MTOM [165] er en anbefalt metode fra W3C for å øke overføringshastigheten på lange 

meldinger. Den baserer seg på å pakke sammen XML-innholdet til et kompakt binært format. 

Man kan velge ut hvilke deler av meldingen som skal pakkes sammen, slik at viktige 

elementer som konvolutten fortsatt kan være lett tilgjengelig. Når en melding sendes via flere 

noder, kan MTOM brukes til et hvilket som helst steg uavhengig av de andre stegene. MTOM 

baserer seg i likhet med SOAP med vedlegg (se over) på MIME multipart, og bruker i tillegg 

XML-binary Optimized Packaging (XOP, se avsnitt 4.5.7) for komprimering av innholdet. 

4.4.2.3 JSON-RPC 

JSON-RPC er en parallell til SOAP som i stedet for XML bruker Javascript Object Notation 

(JSON, avsnitt 4.5.6.1) for representasjon av data. JSON-RPC brukes når AJAX 

brukergrensesnitt (avsnitt 4.6.6) skal kommunisere med underliggende tjenester, gjerne i tråd 

med prinsippene for REST (avsnitt 4.2.6). Løsningen tilbys i bibliotek for flere 

programmeringsspråk, og brukes blant annet av Google web toolkit. I likhet med forgjengeren 

XML-RPC [208] er denne løsningen langt enklere enn SOAP, med færre datatyper og 

operasjoner, og dermed ikke like generell, utvidbar og slagkraftig. SOAPjr [138] er en 

mellomløsning som legger til SOAP sin inndeling av meldinger i konvolutt, hode og kropp, for å 

få en mer standardisert struktur på JSON-RPC. 

4.4.2.4 Komponentbaserte arkitekturer 

Mange av utfordringene som i dag preger tjenesteorientert arkitektur ble tidligere adressert i 

komponentorienterte arkitekturer som CORBA, DCOM og Java Enterprise Edition. OMGs CORBA 

er en åpen arkitektur, med en generell og en internet-basert protokoll for kommunikasjon 

mellom ulike mellomvareinstallasjoner (GIOP og IIOP). Disse skiller seg fra SOAP ved at IIOP 

tar plassen til http, og ved at data kodes binært heller enn med XML. 

20.01.2010 Versjon 1.1 41/89

DIFI 


Komponentbaserte arkitekturer er først og fremst interessant for interoperabilitet mellom 

systemene internt i en virksomhet. De skiller seg typiske fra webtjenester ved: 

Sterkere avhengighet til en IKT-leverandør 

Binær kommunikasjon og færre lag kan gi bedre ytelse 

Bruk av andre porter enn http gjør at trafikken vanskeligere kommer gjennom 

brannmurer 

Mer sofistikerte løsninger for sikkerhet og pålitelighet 

Flere funksjoner innbakt i mellomvaren 

Mer kompleks mellomvare, som er mer krevende å ta i bruk og forvalte 

For virksomheter som allerede har komponentbasert mellomvare på plass, vil det være aktuelt 

å integrere denne i en tjenesteorientert arkitektur. Det finnes verktøy for dette på alle 

plattformene. 

4.4.2.5 Elektronisk post og dynamiske nettverk 

Selv om SOAP over HTTP er den dominerende standarden for web services, så er det også 

mulig å bruke alternativer. For å knytte menneskelig og maskinell kommunikasjon sammen, 

kan det være aktuelt å se på SOAP over SMTP (Simple Mail Transport Protocol) i stedet for 

http. Dette kan brukes til å kalle opp webtjenester ved å sende en epostmelding, hvor 

innholdet enten ligger som XML-tekst i meldingen, eller som et vedlegg (MIME). Dette er f.eks. 

en svært enkel løsning for innsending av registreringsskjemaer, hvor brukeren kan håndtere 

skjemaet som en vanlig melding i sin epost-klient. Verktøy hjelper tjenesteleverandøren til å 

lage skjemaer for denne løsningen i pdf eller html. 

Extensible Messaging and Presence Protocol (XMPP, tildligere kalt Jabber) [212] er en åpen 

protokoll som foreslås som fremtidig standard fra IETF. Det er en enkel løsning for umiddelbar 

meldingsutveksling (instant messaging - IM), synkron kommunikasjon, lettvekts mellomvare 

og generell ruting av XML-data. En SOAP-binding for XMPP, som alternativ til http i mobile og 

dynamiske nettverk, kan være en aktuell transportmekanisme for webtjenester. Den kan 

overføre både synkrone og asynkrone meldinger effektivt og pålitelig, og trenger ikke 

komplekse protokoller i tillegg for å levere meldinger til enheter som ikke har en fast IPadresse. 

4.4.3 Hendelser og notifikasjon 

Hendelsesdrevne arkitekturer, hvor meldinger ikke adresseres direkte til mottakeren, men 

publiseres til de som abonnerer på dem, tilbyr løsere kobling mellom bruker og leverandør av 

tjenester. 

4.4.3.1 WS-Eventing 

WS-Eventing [180] støtter abonnering og publisering av beskjeder om hendelser (publicationsubscription 

eller pub sub). Dette er en enkel løsning uten megling av meldinger eller 

håndtering av temaer man kan abonnere på. Den er foreslått av Microsoft og IBM til W3C, 

men ikke videreført som standard foreløpig. 

4.4.3.2 WS-Notification 

WS-Notification er en mer omfattende løsning for abonnering og publisering av beskjeder om 

hendelser. Den er standardisert av OASIS og består av tre deler: 

WS-BaseNotification [105], enkel pub-sub som ligner WS-Eventing 

WS-BrokeredNotification [106], hvor mellomvare styrer, ruter og filtrerer beskjedene 

WS-Topics [107], som beskriver hvordan man kan ordne ulike typer 

hendelsesmeldinger i et emnehierarki innen et navnerom. 

Både WS-Eventing og WS-Notification bygger på WS-Policy (avsnitt 4.3.2.4) og WS- 

ReliableMessaging (avsnitt 4.8.7). IBM har vært toneangivende i utviklingen av WS- 

20.01.2010 Versjon 1.1 42/89

DIFI 


Notification, mens WS-Eventing har vært drevet fram av Microsoft. De to har sammen med HP 

og Intel gjort et forsøk på å integrere de to standardene, men dette arbeidet skal være lagt på 

is [82]. 

4.4.4 WS-Addressing - ruting og adressering av tjenester 

WS-Addressing [171] er en basis standard fra W3C. Den er inkludert i de fleste profiler og 

brukt av flere andre standarder. Den består av en kjerne, en spesifikasjon av bindinger til 

SOAP 1.1 og 1.2, og en beskrivelse av hvordan generelle metadata egenskaper definert i 

kjernen kan inkluderes i beskrivelsen av et endepunkt i WSDL 1.1 og 2.0. 

Standarden definerer en mengde abstrakte egenskaper for å referere til webtjenester og støtte 

adressering av meldinger fra endepunkt til endepunkt gjennom et nettverk av noder, slik at 

brannmurer, gateways og andre noder kan håndteres uavhengig av hvilke protokoller som 

brukes på transportlaget. 

WS-MessageDelivery var en konkurrerende forslag som nå er inkludert i WS-Adressing. Andre 

tidlige forslag på dette området var kalt WS-Routing og WS-Referral. 

4.5 Data og informasjon 

Utveksling av informasjon er en sentral utfordring innen interoperabilitet, på ulike nivåer: 

Semantisk interoperabilitet, at innholdet og dets mening kan tolkes på samme måte av 

alle parter. 

Syntaktisk interoperabilitet, at informasjonen kodes på en måte som kan skrives og 

leses av alle parter. 

Teknisk nivå, hvor man kan skille mellom distribuerte og sentraliserte løsninger. 

Disse nivåene tilsvarer grovt det som kalles konseptuelt, logisk og fysisk nivå i 

databaselitteraturen. Siden dette området er sentralt, men i liten grad gjenstand for tjenesteorienterte 

standarder, dreier mesteparten av dette avsnittet seg om overordnede 

angrepsmåter. Først identifiserer vi ulike nivåer for dataintegrasjon og interoperabilitet. 

Deretter introduseres generelle metoder for utveksling av informasjon mellom partnere, 

gruppert i fem profiler, før relevante standarder for koding og innhold blir identifisert. 

Semantiske teknologier er gjenstand for en annen kartlegging, og vil ikke bli diskutert her. 

4.5.1 Nivåer for dataintegrasjon 

Figuren nedenfor illustrerer tre ulike nivåer for integrasjon og interoperabilitet, mellom 

virksomheter, mellom applikasjoner eller tjenester, og mellom databaser og andre datalagre. 

Disse nivåene samvirker og står overfor mange av de samme utfordringene, men metodene 

som brukes vil delvis være forskjellige. 

Virksomhets- 

Virksomhet 1 Virksomhet 2 

integrasjon 

Applikasjon eller 

tjeneste 1 

Applikasjonsintegrasjon 

Applikasjon eller 

tjeneste 2 

Database- 

Database 1 Database 2 

integrasjon 

Figur 9. Interoperabilitet på ulike nivåer. 

Det vil selvfølgelig også være utfordringer knyttet til interoperabilitet vertikalt i figuren over, 

f.eks. mellom ulike teknologier for å gjøre databaser tilgjengelig for applikasjoner, eller 

applikasjoner tilgjengelig for virksomheten. Førstnevnte tema faller utenfor fokuset til 

20.01.2010 Versjon 1.1 43/89

DIFI 


tjenesteorientert arkitektur, mens sistnevnte dekkes av avsnittet om interaksjon og 

presentasjon (4.6). 

4.5.1.1 Databaseinteroperabilitet 

Databaseintegrasjon baserer seg på overføring av datamengder mellom databaser som kan ha 

ulike innholdsstrukturer. En typisk tilnærming er ETL (Extract-Tranform-Load) hvor man 

henter ut data fra en kildebase, omformer dem så de passer med målbasen, og deretter laster 

dem inn i målbasen. Dataene kan overføres gjennom synkron kommunikasjon, men store 

datamengder vil typiske overføres satsvis (batch), f.eks. gjennom at filer genereres fra kilden 

og legges på et sted som målsystemet overvåker og kan plukke opp data fra. Eksponering av 

data som webtjenester lar seg gjøre direkte fra databasene ved hjelp av standard verktøy. 

Hvis datamengdene ikke er for store, og det er viktig å overholde regler som er definert på 

applikasjonsnivået, kan det være mer hensiktsmessig å integrere mellom 

applikasjonsprogramvaren i stedet. 

4.5.1.2 Applikasjonsnivå interoperabilitet 

Applikasjonsnivå dataintegrasjon dreier seg om å sørge for at parametere og innhold i 

dokumenter, meldinger og prosedyrekall mellom applikasjonene har riktig koding og et innhold 

som har mening for alle parter. De fleste større leverandører tilbyr webtjenester eller adaptere 

som kan brukes til å eksponere tjenester basert på andre applikasjonsprogrammeringsgrensesnitt 

(API). Sammenkobling på dette nivået gir økt overhead og 

begrenset skalerbarhet sammenlignet med integrasjon på databasenivået, men kan samtidig 

sørge for at oppdaterte data alltid er tilgjengelig. Det åpner også for gjenbruk av funksjonalitet 

og applikasjonslogikk, ikke bare data. 

4.5.1.3 Interoperabilitet mellom virksomheter 

Utveksling av data på tvers av virksomheter stiller sterkere krav til sikkerhet, klart definert 

syntaks og semantikk. Dette området har da også vært gjenstand for standardisering over 

lengre tid, fra EDI til elektroniske forretningstransaksjoner og samhandling i offentlig sektor. 

Kompleksiteten stiger ytterligere når mange virksomheter skal samvirke, og hver av dem har 

utviklet sine egne datamodeller. Dette gjør at andre metoder og standarder kan være egnet 

for interoperabilitet mellom virksomheter, enn internt i en virksomhet. 

4.5.2 Profiler for informasjonsutveksling 

Dette avsnittet ser på ulike angrepsmåter eller overordnede metoder for å oppnå 

interoperabilitet for data. 

4.5.2.1 Dokumentutveksling 

Den enkleste formen for datautveksling bryr seg ikke om semantikk eller detaljert syntaks, 

men sørger simpelthen for å overføre et dokument eller en melding mellom to enheter uten å 

bry seg om innholdet. Innholdet kan enten bli tolket av mennesker, og/eller av applikasjoner 

som finnes på begge sider. 

4.5.2.2 Direkte transformasjon (Punkt til punkt) 

Punkt til punkt sammenkobling innebærer at man definerer en direkte transformasjon 

(mapping) mellom avsenders og mottakers interne dataformater. Slik sørger man også for 

semantisk interoperabilitet. 

4.5.2.3 Felles datamodell (Hub and spoke) 

Hvis man trenger å koble sammen mange ulike applikasjoner, vil punkt til punkt snart bli 

problematisk, siden antallet koblinger vokser med kvadratet av antallet applikasjoner. Da kan 

løsningen være å innføre en felles datamodell for på tvers av applikasjonene (hub, nav), og i 

stedet lage transformasjoner fra alle kilder til det felles formatet (spokes, eiker). Dette kan 

også skape problemer i form av en svært kompleks felles datamodell, som må dekke absolutt 

alle elementer som to eller flere applikasjoner har til felles. 

20.01.2010 Versjon 1.1 44/89

DIFI 


4.5.2.4 Semantisk teknologi 

Semantisk teknologi skaper interoperabilitet gjennom å definere den felles datamodellen på en 

formell og matematisk måte, som en ontologi. Den formelle representasjonen gjør det mulig å 

automatisere transformasjonene mellom ulike språk, basert på oppsatte regler. Dette kan 

forenkle forvaltning og endring av modellene og transformasjonsreglene. Gjennom at 

transformasjonsreglene avledes fra et mer høynivå deklarativt format, heller enn å spesifiseres 

operasjonelt, kan det være lettere for brukere å forstå. Dessverre er de formelle språkene ofte 

enda vanskeligere å forholde seg til enn programmeringsspråk, så disse fordelene skal man 

ikke ta for gitt. 

4.5.2.5 Føderasjoner 

Føderasjoner består av autonome komponenter som settes sammen innenfor et rammeverk av 

felles regler. Dette finnes på fysisk nivå, hvor fødererte databaser kan inneholde ulike 

datamengder som gjennom føderasjonen settes sammen og gjøres tilgjengelig som om det var 

en database. På logisk nivå kan et føderert databaseskjema settes sammen fra 

komponentenes lokale skjema. 

På konseptuelt nivå kan man tillate forskjellige, også delvis inkonsistente, tolkninger av de 

samme dataene innenfor hver enkelt komponent, som et uttrykk for lokalt autonomi. Dette 

kan brukes til å forenkle en felles datamodell, og bruke en hybrid løsning hvor noe data 

utveksles gjennom en felles datamodell, men hvor også punkt-til-punkt transformasjoner kan 

legges til for elementer som ikke deles av særlig mange av partene. 

4.5.3 XML 

XML [152] er den fundamentale datastandarden for tjenesteorientert arkitektur. Den brukes til 

meldingsutveksling og til beskrivelse av tjenester med tilhørende regler. Standarder for 

definisjon og prosessering av XML-strukturer brukes derfor hyppig. Samtidig er XML er svært 

generell standard, og mange metoder spesifiserer derfor hvordan de bruker XML i detalj. 

Likevel er XML langt enklere enn SGML, som den var basert på. XML 1.0 er fortsatt den 

versjonen av standarden som er utbredt, selv om man også har standardisert en versjon 1.1 

som blant annet ga større frihet i bruk av ulike tegn. Dette fjernet problemer knyttet til 

linjeskift, som gjorde at noen XML-dokumenter ikke var gyldige tekstdokumenter i visse 

stormaskinmiljø, men skapte nye problemer for validering, så denne versjonen ble gitt opp. 

4.5.3.1 XML Schema 

XML Schema brukes til å definere den syntaktiske oppbygningen til XML-dokumenter for en 

gitt anvendelse, f.eks. som innhold i en melding eller en tjenestebeskrivelse. Forgjengeren fra 

SGML, DTD (Document Type Definition), tillates ikke i WSDL [173], så XML Schema er like 

allestedsnærværende som XML i tjenesteorienterte arkitekturer. Et XML Schema dokument er 

et XML-dokument som følger skjemaet for XML Schema. Ved siden av konstruksjoner for å 

definere XML-strukturer bestående av elementer, attributter og tekst, definerer XML Schema 

en lang rekke standard datatyper. 

XML Schema finnes som anbefalt standard i versjon 1.0 [198], mens versjon 1.1 [199] er 

kandidat for å bli anbefalt. 1.1 legger bl.a. til 

Muligheter til å definere avhengigheter og regler ved hjelp av XPath 

Mulighet til å definere at typen til et element skal avhenge av dets attributter 

Mer frihet i bruken av åpne spesifikasjonselementer som any og anyAttribute, bl.a. 

mulighet til å definere felles utvidelsesmekanismer for flere elementer i et skjema 

gjennom (arv). 

WSDL2.0 bruker XML Schema 1.1, mens WSDL 1.1 bruker XML Schema 1.0. 

XML Namespaces [188] definerer hvordan skjemaer kan modulariseres ved å dele dem opp i 

navnerom som kan gjenbrukes i ulike sammenhenger. Navnerom kan importeres inn i andre 

navnerom. I XML-dokumentene identifiseres navnerommene som brukes innenfor et element, 

hvor de gis en prefiks som brukes til å kvalifisere navn som brukes i dokumentet, slik at en 

20.01.2010 Versjon 1.1 45/89

DIFI 


parser kan finne ut hvilket navnerom hvert navn tilhører. Navnerom identifiseres med en URI, 

men definisjonen kan spres over flere dokumenter som inkluderes i hoveddokumentet. 

XLink [196] er en XML-standard som brukes til å referere til andre ressurser. Man kan også 

legge til metadata som beskriver lenken, definere lenker på andre steder enn ressursene som 

de knytter sammen, og definere lenker mellom flere enn to ressurser. 

4.5.3.2 Metoder og standarder for manipulering av XML 

XSLT [201, 202] brukes til å definere transformasjoner fra et XML-format til et annet, og er 

svært utbredt i tjenesteorienterte arkitekturer. XSLT opererer på XML-strukturer på et 

syntaktisk nivå. Versjon 1.0 [201] er noe enklere enn 2.0 [202], og fortsatt i utstrakt bruk. 

XSLT bruker XPath [197] til å definere delmengder av XML-strukturen i kildedokumentet som 

skal behandles på samme måte, og til å utføre beregninger og funksjoner. XSLT definerer egne 

funksjoner i tillegg til de i XPath. 

XPath brukes også av XQuery [203], som ble definert for å søke fram data i store samlinger av 

XML-dokumenter. XSLT versjon 2.0 ble utviklet i parallell med XQuery, og de to standardene 

deler datamodell, funksjonsbibliotek og typesystem. Funksjonaliteten til de to standardene 

overlapper altså. XQuery er enklere enn XSLT, og bedre egnet for komplekse søk i 

velstrukturerte dokumenter, f.eks. sammensetting av flere datasett (Join). XSLT er bedre 

egnet til fleksibelt strukturerte dokumenter, utvides enklere med maler (templates) og 

importering, håndterer navnerom bedre, og kan lettere formattere datoer og tallverdier. 

XML Infoset [194] definerer generelle datastrukturer som en XML parser kan produsere fra et 

velformet XML-dokument. Det er således en abstrakt datamodell for XML, som kan tjene som 

en retningslinje for ulike implementasjoner. Spesifikasjonen ligger på logisk nivå, uavhengig 

av teknologiene som XML-strukturen skal sendes videre til. 

Document Object Model (DOM) [150] definerer et standard API for å aksessere og manipulere 

innholdet i et HTML- eller XML-dokument. Fra Level 3 følger DOM XML Infoset. Hvis man skal 

parse store XML-dokumenter i sin helhet, er løsninger som SAX (Simple API for XML) for Java 

og VTD-XML (Virtual Token Descriptor) mer egnet enn DOM. Samtidig er DOM en 

grunnleggende standard for rike, dynamiske brukergrensesnitt, som vi ser på i avsnitt 4.6.6 og 

4.6.7. 

4.5.4 ebXML Core Components 

Core Components Technical Specification (CCTS) [142] tilbyr en mer høynivå og fleksibel 

tilnærming til definisjon av standard dataformater enn det man får ved rett fram bruk av XML 

Schema. CCTS definerer semantiske standarder på en syntaks-nøytral måte, og støtter 

dermed EDI ved siden av XML. Den inneholder en metodikk for å utvikle felles begreper, for å 

definere nye vokabular basert på disse begrepene, og for restrukturering av eksisterende 

vokabular. 

De grunnleggende begrepene er basis, sammensatte og assosierte komponenter (for 

egenskaper, objekter og relasjoner). Komponenter er uavhengig av sammenheng (business 

context), mens informasjonsentiteter (Business Information Entity - BIE) er knyttet til en 

definert sammenheng. I likhet med komponenter, finnes det ulike kategorier av BIE for basis 

egenskaper, assosiasjonsegenskaper, og sammensatte objekter. BIEr utgjør innholdet i CCstandarder 

som UBL og CCL (se nedenfor). 

Informasjonsmodeller med disse byggesteinene kan man også lage i UML gjennom UN/CEFACT 

Modeling Methodology (UMM). Her knyttes informasjonsmodeller på semantisk nivå sammen 

med prosessmodeller, slik at man ikke trenger å bry seg om syntaktiske detaljer under 

utforming av samarbeidsprosessene. Typiske sammenhenger for definisjon og gjenbruk av 

informasjonsentiteter kan være forretningsprosessen, produkttypen, forvaltningssektoren, 

geopolitisk eller juridisk område, stilling eller rolle, og underliggende IKT-systemer. 

Denne metoden gjør CCTS til en utvidbar tilnærming til dataintegrasjon, som vektlegger 

gjenbruk. Når man har definert sin informasjonsmodell basert på egne elementer og elementer 

gjenbrukt fra tilgjengelige standarder, så kan XML Schemas avledes automatisk, slik at en 

standard parser kan prosessere dokumentene. Videre arbeid med disse 

20.01.2010 Versjon 1.1 46/89

DIFI 


gjenbruksmekanismene er på gang i prosjektene Unified Context Methodology og Core 

Components Message Assembly [144]. 

4.5.5 Innholdsstandarder 

En rekke standardiseringsorgan jobber med å definere strukturer for forretningsdokumenter i 

XML. Mange av disse innholdsstandardene er spesifikke for industrier eller sektorer, så her tar 

vi bare for oss de mest utbredte generelle standardene. Noen av standardene er basert på 

ebXML Core Components, andre er definert direkte med XML Schema. I tillegg til disse finnes 

en lang rekke ontologier, definert med semantiske standarder som i OWL (Web Ontology 

Language) eller RDF (Resource Description Framework). 

4.5.5.1 UN CCL – Core Components Library 

Dette biblioteket [143] inneholder kjernen av innhold i Core Components rammeverk. Totalt 

defineres nesten 1000 elementer, tilknyttet nesten 100 objektklasser som beskriver varer og 

tjenester, innkjøp og logistikk, arbeid m.m. Grunnleggende begreper som tjeneste, ressurs, 

kalender og periode, hendelse, pris og kostnad, kommunikasjon, kalkulering, dokument, 

sammensatt beskrivelse, målesystem m.fl. er definert her. 

4.5.5.2 UBL - Universal Business Language 

Denne standarden fra OASIS [96] definerer generelle innholdselementer for elektronisk 

handel, uten binding til noen bestemt industri eller sektor. UBL er definert i henhold til Core 

Components, men kan brukes også innenfor andre rammeverk for tjenesteorientert arkitektur. 

UBL 2.0 innholder ca. 2000 begreper (Business Information Entities), som er oversatt til flere 

språk som del av IDD (International Data Dictionary). Typiske dokumenter i UBL er kataloger, 

bestillinger, anbud, fakturering, og meldinger knyttet til kreditt og transport. UBL definerer 

dessuten mer finkornede innholdselementer, som adresse, pris og betaling. Gjennom CCTS 

kan skjemaer i UBL utvides med egne definisjoner, skreddersys og tilpasses. Det pågår arbeid 

for å knytte sammen UBL og CCL, hvor UBL tilbyr en mer presis syntaktisk knytning til XML 

enn de mer semantisk orienterte CC-standardene. UBL inneholder blant annet rundt 30 XML 

Schemas for de mest vanlige forretningsdokumentene. 

Northern European Subset (NESUBL) [83] definerer profiler og informasjonsmodeller tilpasset 

skandinaviske forhold, basert på UBL. Disse oversettes videre til norsk og presiseres for norske 

forhold av ehandel.no. Gjennom europeisk samarbeid ser man dessuten på samvirke mellom 

UBL, UNSPSC og andre standard vokabular for innkjøp [27]. 

4.5.5.3 UNSPSC - United Nations Standard Products and Services Code 

UNSPSC [42] er et sett med standard koder for ulike grupper produkter og tjenester. Den 

består av over 22000 elementer. UNSPSC finnes i norsk oversettelse fra GS1 Norge. 

Kategorisering av varer og tjenester i henhold til UNSPSC er obligatorisk i produktkataloger 

som skal benyttes på markedsplassen for det offentlige (ehandel.no). 

4.5.5.4 OAGIS - Open Applications Group's Integration Specification 

OAGIS [84] er nok en standard basert på ebXML CCTS. De jobber med kundehåndtering, 

finans og betaling, bestilling, logistikk, lokalisering, rapportering til myndighetene (Sarbanes 

Oxley) og tekniske produkter (sammen med STEP). Standarden er strukturert i 77 substantiv, 

12 verb, og i alt 434 forretningsdokumenter som knytter sammen verb og substantiv. Ved 

siden av generelle standarder defineres lokale løsninger for bil-, IKT-, fly- og 

romfartsindustriene, samt for USAs luftvåpen. 

4.5.6 Andre tekstlige formater 

Ved siden av XML brukes andre tekstlige formater til å utveksle data, særlig på 

databasenivået, og for kommunikasjon mellom brukergrensesnitt og applikasjonstjenester. 

Tekstlige strukturerte dokumenter bruker gjerne skilletegn som komma (CSV) mellom ulike 

felt, eller en fast kolonnebredde. Sammenlignet med XML krever de langt mindre overhead, 

men innholdsstrukturer utover tabeller, som hierarki, er vanskelig å representere. 

20.01.2010 Versjon 1.1 47/89

DIFI 


4.5.6.1 JSON 

Javascript Object Notation (JSON.org) er et enkelt tekstlig overføringsformat, som er leselig 

for mennesker, men samtidig lett for programvare å generere og parse. JSON definerer 

objekter som en mengde navn-verdi-par. Man kan dessuten sette sammen lister av objekter, 

verdier og andre lister. Denne metoden er svært utbredt på de fleste 

programmeringsplattformer, særlig for kommunikasjon mellom brukergrensesnitt og 

underliggende applikasjonstjenester. 

4.5.7 Binær XML 

For raskere overføring av store datamengder har det blitt definert standarder og metoder for 

binær komprimering av XML, for eksempel for multimedia. Dette er særlig viktig for XML, som 

koder innhold svært ineffektivt, blant annet for å gjøre teksten lesbar for mennesker. En rett 

fram løsning som flere programmeringsomgivelser tilbyr, er simpelthen å komprimere og 

pakke (zip) xml-teksten. Slik komprimering krever imidlertid en viss prosesseringstid, som 

ofte overstiger tiden spart på raskere overføring. Dette avhenger selvfølgelig av dokumentenes 

størrelse og form, samt ytelsen til maskinvaren som er i bruk. 

XML binary optimization (XOP) fra W3C er en viktig standard for tjenestearkitekturer gjennom 

at den brukes i SOAP MTOM (se avsnitt 4.4.2.2). XOP skiller ut binært innhold fra XMLdokumentet, 

og sender dem som separate deler i en MIME (multipart) melding. Slik slipper 

man konvertering av binært innhold som del av XML-dokumentet. Hver del komprimeres for 

seg. XOP definerer også en inkluderingsmekanisme for å sette de ulike delene inn på riktig 

sted i hoveddokumentet. Lange tekster i XML-elementer kan også optimeres, men ikke 

elementnavn eller attributtverdier. 

XOP brukes for overføring over internett, men W3C har også satt ned en arbeidsgruppe kalt 

EXI (Efficient XML Interchange) som utvikler en spesifikasjon for effektiv prosessering av XML 

information sets (avsnitt 4.5.3.2). Målet med EXI er et generelt, minimalt, effektivt, fleksibelt 

og interoperabelt format. Meldinger i EXI inkluderer et hode og en kropp, og hodet forklarer 

hvordan kroppen skal dekodes ved hjelp opsjoner definert av EXI. EXI koder kildedokumentet i 

henhold til hvordan det ville blitt gjennomløpt av en sekvensiell parser som SAX, som en serie 

hendelser. Basert på generelle regler eller et gitt XML Schema, tilordnes kortere kode til de 

hyppigst forekommende hendelsene i grammatikken. EXI er altså en semantisk koding, mens 

XOP gir en komprimering av kodingen på binært nivå. EXI koder hele dokumentet, inkludert 

XML-elementer og attributter, mens XOP bare koder tekstlig og binært innhold i elementer. 

FAST Infoset [55] er en eldre standard fra ISO for binær koding for XML. Den er knyttet til 

kommunikasjonsstandarden ASN.1 (X.680), men kodingen kan brukes også for overføring over 

http. WAP Binary XML (WBXML) fra Open Mobile Alliance er optimert for rask overføring over 

trådløse nettverk, mens VTD-XML er en åpen implementasjon som koder XML binært med vekt 

på rask koding og dekoding. Andre løsninger for spesifikke datatyper inkluderer Binary MPEG 

format for XML (BiM) og Binary XML Encoding Specification for geo-related data (GML). 

4.5.8 WS-Enumeration - Tjenesteorientert tilgang til sammensatte data 

WS-Enumeration [179] er et forslag til W3C som definerer webtjenester for tilgang til en 

ordnet liste av data. Denne kan brukes til meldingslogger, køer, eller lister med brukerdata. 

Dette er en protokoll som ikke er tilstandsløs, siden en kommando for å hente neste element 

nødvendigvis avhenger av hvilke elementer som allerede er hentet. Funksjonene benyttes 

blant annet av WS-Management (avsnitt 4.3.3.2). Microsoft har dessuten definert en åpen 

utvidelse av dette for katalogdata, kalt WS-Enumeration Directory Services Protocol 

Extensions (WSDS). 

4.5.9 Databaseintegrasjon 

Metoder for kopiering og satsvis overføring mellom databaser, distribusjon og lastbalansering 

er viktige deler av infrastrukturen for tjenesteorientert arkitektur. Til dels kan dette også være 

alternative løsninger til en tjenesteorientert implementering, særlig for å sikre akseptabel 

ytelse. 

20.01.2010 Versjon 1.1 48/89

DIFI 


4.5.9.1 Filoverføring 

Den enkleste formen for databaseintegrasjon er nok å eksportere dataene på en fil, overføre 

dem manuelt eller automatisk, og så laste dem inn i en ny database. Filene kan ha binært eller 

tekstlig format, for den saks skyld også XML. Automatiserte satsvise jobber kan 

implementeres ved at mottakerdatabasen følger med på et filområde hvor avsenderdatabasen 

laster opp filene (såkalt file drop), gjerne med ftp. 

4.5.9.2 ETL – Extract Transform Load 

ETL brukes typisk til å kopiere data inn i et datavarehus for rapportering, som skilles ut fra den 

operative databasen hvor dataene oppdateres. Egne verktøy brukes til å strukturere 

databasekallene som gjør jobben, og til å transformere dataene til en struktur som passer 

bedre for bruksmønsteret til datavarehuset. For å sikre integritet og kontinuerlig operasjon 

under overføringen, brukes gjerne egne tabeller til å holde på transformerte data før de 

sendes til datavarehuset (staging). Adaptere brukes dessuten for f.eks. å gjøre data fra 

stormaskinmiljø tilgjengelig på relasjonsform. 

4.5.9.3 Føderasjon med virtuelt skjema 

En føderasjon skaper et virtuelt skjema på tvers av ulike databaser, kanskje også ulike 

databasesystemer. Optimalisering og caching brukes til å sørge for rask aksess og 

sammenstiling av data på tvers av de ulike databasene. Dette gjør en løs kobling mellom 

databasene mulig. Dette kan enten implementeres gjennom omformulering av forespørsler fra 

felles skjema til lokale databaser (local as view), eller gjennom å definere det virtuelle 

skjemaet som et database view over de lokale tabellene (global as view). 

4.5.9.4 Adaptere for tilgjengeliggjøring av databaser 

Adaptere brukes av mellomvare og systemer for dataintegrasjon til å gjøre proprietære data 

tilgjengelig, f.eks. i henhold til tjenesteorienterte standarder. En åpen løsning for dette er Java 

Connector Architecture (JCA) [9]. Adaptere kalles tynne hvis de bare gir tilgang til dataene 

direkte, og tykke hvis de utnytter semantisk informasjon til å transformere dataene, eller 

håndterer feil og køer. Statiske adaptere er hardkodet til et gitt databaseskjema, mens 

dynamiske adaptere kan tilpasse seg endringer i skjemaet automatisk. 

4.6 Portaler, interaksjon og presentasjon 

De foregående avsnittene har tatt for seg standarder som ikke er synlige for brukerne av en 

tjeneste. Vi ser nå på ulike aspekter ved brukergrensesnitt og interaksjon. Igjen er det 

vanskelig å avgrense hvilke metoder som hører til tjenesteorientert arkitektur. En smal 

tolkning er at kun standarder basert på webtjenester er aktuelle. Det er i så fall begrenset til 

WSRP (avsnitt 4.6.3). Vi velger her å inkludere flere teknologier som gjerne brukes over 

webtjenester, men samtidig å holde diskusjonen på et overordnet nivå. 

4.6.1 Kanaler 

Offentlig sektor gjør sine tjenester tilgjengelig gjennom mange forskjellige manuelle og 

automatiserte kanaler. Vi fokuserer i dette avsnittet på automatiserte kanaler for IKTtjenester, 

enten de anvendes av ansatte i offentlig sektor eller brukerne av offentlig sektors 

tjenester. Ulike kanaler varierer typisk med hensyn på nettverkstilkoblingens båndbredde, om 

klienten er tilkoblet kontinuerlig, vanligvis, eller sporadisk, og om klientens plassering i 

nettverket er statisk eller dynamisk. Skjerm og annet presentasjonsutstyr varierer i størrelse, 

og forskjellig utstyr brukes for å gi data inn til systemet og navigere i brukergrensesnittet. 

Andre variasjoner er omgivelsen brukeren befinner seg i, f.eks. om tjenesten gjøres 

tilgjengelig gjennom en offentlig portal eller plugges inn i en kommersiell eller bedriftsintern 

portal. Mediene som brukes kan inkludere tekst, tale, bilde og video. Spesifikke standarder for 

dette er utenfor fokus for denne rapporten, men virkninger på tjenestearkitekturen tas med. 

Brukernes varierte situasjon og egenskaper krever utforming med tanke på tilgjengelighet for 

alle, mens fleksibilitet og robusthet gjør at manuelle sidekanaler kan være påkrevd ved siden 

av de IKT-baserte. 

20.01.2010 Versjon 1.1 49/89

DIFI 


4.6.2 HTML 

Referansekatalogen [32] sier at HTML 4.01 [153] og XHTML 1 [155] skal være primærformat 

for publisering av dokumenter med tekstlig innhold på statlige nettsteder. For 

tjenestegrensesnitt kreves rikere og mer dynamiske webomgivelser, hvor skjemaer, oppførsel, 

og presentasjon gjerne organisert i en portal, og hvor brukergrensesnittet tilpasser seg 

brukeren. Dette gjør at referansekatalogen kanskje bør inkludere mer enn dokumentformater, 

f.eks. standarder for skjemaer og scripting. 

HTML 5 [154] er under utarbeidelse, og det vil gå tid før den eventuelt kan ta over for versjon 

4 og XHTML, som den integrerer. Også før denne versjonen tas i bruk i full bredde, kan den 

likevel være interessant som brukergrensesnitt for webtjenester, særlig for dynamisk 

manipulering av HTML i AJAX-omgivelser (se avsnitt 4.6.6). Det virker fornuftig å ta i bruk 

fremtidige standarder på dette området tidlig, når alternativet er proprietære løsninger. 

Pågående standardisering innenfor dette området beskrives i avsnitt 4.6.7. 

4.6.2.1 Scripting 

ECMAScript [24] er en felles standard for Javascript, ActionScript, JScript og andre dialekter, 

og som støttes av de aller fleste moderne browsere. Den er standardisert som ISO/IEC 16262, 

i ulike utgaver. 5. utgave er snart klar, og vil blant annet legge til et bibliotek for JSON (jf. 

avsnitt 4.5.6.1 og 4.4.2.3). For standardisering i dag er versjon 3 den stabile og utbredte 

utgaven. 

4.6.2.2 XForms 

XForms er et XML-format for å spesifisere skjemaer og andre brukergrensesnitt, og en 

prosesseringsmodell for disse. XForms er laget for HTML/XHTML, men er generell nok til å 

kunne brukes med andre presentasjonsspråk. Versjon 1.0 [189] ble opprinnelig anbefalt av 

W3C i 2003, og er nå i sin 3. utgave. Versjon 1.1 [190] ble godkjent i 2009. Den forbedrer 

fleksibel sammensetting av skjemaer ved hjelp av maler, og tilbyr flere løsninger for å sende 

inn dataene i skjemaet, som REST, SOAP, Atom og tekst (f.eks. JSON). 

XForms følger en model-view-controller (MVC) tilnærming. Et dokument består av en modell 

av XML-data, og XPath brukes til å knytte brukergrensesnittelementer til modellelementene. 

Utseendet kan styres med stilark (CSS). Det finnes verktøy for å kjøre XForms som kan 

plugges inn i ulike browsere, også på mobile plattformer, og i verktøy som OpenOffice. 

4.6.3 Tilgjengelighet for alle 

Web Content Accessibility Guidelines (WCAG) [169] gir retningslinjer for tilgjengelighet til 

nettsider for folk med ulike funksjonshemminger. Referansekatalogen [32] anbefaler å legge 

de delene av WCAG som blir gjengitt i Norge.no sine kvalitetskrav til offentlige nettsteder til 

grunn ved utforming av offentlige nettsider. WCAG har seinere kommet i versjon 2.0 [170], 

som ser bredere på mer avanserte teknologier, hvor kravene er enklere å forstå, mer 

teknologiuavhengige, og kan testes mer presist. Ved siden av WCAG utvikler W3C standarder 

for å ta hensyn til retningslinjene i 

Verktøy for å lage websider (Authoring Tool Accessibility Guidelines, ATAG), 

Browserne som viser sidene (User Agent Accessibility Guidelines, UAAG), 

Automatisert testing (Evaluation and Report Language, EARL), og 

Rike web-grensesnitt (Accessible Rich Internet Applications, WAI-ARIA) [148]. 

4.6.4 ELMER 

Elmer II [75] definerer obligatoriske retningslinjer for næringslivsskjemaer på offentlige 

nettsider. Retningslinjene er helt uavhengige av teknologi. De omhandler oppbygning av 

skjema, navigasjon, rekkefølge, ulike skjemaelementer, hjelp og tilbakemeldinger, og 

koblinger til skjemaets omgivelser. Innholdet består av ufravikelige krav (skal), anbefalinger 

(bør), og eksempler som illustrerer retningslinjene. 

20.01.2010 Versjon 1.1 50/89

DIFI 


4.6.5 WSRP – Web Services for Remote Portlets 

WSRP [110] definerer et grensesnitt av webtjenester som gjør det mulig å integrere 

applikasjoner og innhold fra ulike leverandører i en portal, uten å programmere. Lokale 

portlets kan være implementert i proprietær teknologi knyttet i den enkelte portal, f.eks. i 

Java gjennom de åpne grensesnittene JSR 168 og JSR 286. Gjenbrukbare interaktive 

fellestjenester trenger en åpen standard som WSRP. Standarden finnes i to versjoner, fra 2003 

og 2008. Portlets må tilby tjenester for brukerinteraksjon og for å generere 

presentasjonsfragmenter. WSRP definerer dessuten standard tjenester for å publisere, finne og 

binde sammen portlets i en portal. 

En portlet kan bli bedt om å presentere seg i ulike modi, for visning, editering, hjelp eller 

forhåndsvisning. Man kan dessuten legge til sine egne modi for mer skreddersydd oppførsel. 

Ulike størrelse bør også tilbys, som minimert, normal, maksimert og for seg selv. 

Brukerinteraksjonen kan styres av en sesjonstilstand, som sammen med 

konfigurasjonstilstanden er med på å styre portletens oppførsel. Man kan selvfølgelig også 

lage tilstandsløse portleter. Brukerhandlinger fanges opp av portalen og blir sendt til portlettjeneren 

som hendelser. Det diskuteres å bruke WS-Notification (avsnitt 4.4.3.2) for dette, 

men spesifikasjonen inkluderer foreløpig ikke noe slikt krav. En slik løsning ville gjort det mulig 

for ulike portlets innen en portal å kommunisere seg imellom, på en løst sammenkoblet måte. 

4.6.6 AJAX 

AJAX (Asynchronous Javascript And XML) er en metode som kombinerer industristandarder til 

å skape rike, dynamiske web-omgivelser: 

Presentasjon med HTML og stilark (Cascading Style Sheets, CSS) 

Javascript eller tilsvarende språk styrer interaksjonen med brukeren og kommunikasjon 

med tjenersiden 

Brukergrensesnittet oppdateres dynamisk gjennom at deler av HTML-dokumentet 

overskrives via DOM (avsnitt 4.5.3.2) 

Asynkron kommunikasjon med tjeneren (ofte gjennom XMLHttpRequest) gjør at 

brukeren kan fortsette å jobbe videre mens tjeneren prosesserer tidligere hendelser 

Innholdet kommuniseres mellom klient og tjener som XML, sekundært HTML eller 

JSON. XSLT kan brukes til å omforme innholdet til det formatet som brukes i 

presentasjonen, f.eks. XML til XHTML. 

Det finnes en lang rekke rammeverk for AJAX, hvorav mange har åpen kildekode. Noen 

fokuserer mest på å tilby en lang rekke parametriserbare brukergrensesnittkomponenter, ofte 

kalt widgets, som man kan bygge sine applikasjoner med, mens andre er sterkere på 

kommunikasjon mellom komponenter og mellom klient og tjener via beskjed om hendelser i 

henhold til oppsatte abonnement. AJAX kombineres ofte med REST (avsnitt 4.2.6) for å 

forenkle interaksjonen mellom klient og tjener til noen få operasjoner (CRUD), med en 

tilstandsløs representasjon av hver komponent, som speiles mellom klient og tjener. Som vi 

skal se i neste avsnitt, er W3C i ferd med å etablere standarder for AJAX og lignende 

grensesnitt. 

4.6.7 W3C Webapps 

Denne gruppen i W3C ble skapt gjennom en fusjon av arbeidsgruppene for WebAPI og WAF 

(Web Application Formats). De arbeider for tiden med en lang rekke standarder for 

webapplikasjoner, som adresserer funksjonalitet i dagens AJAX-omgivelser [168]: 

Manipulering av XML-data, gjennom enklere navigeringsgrensesnitt for DOM, bruk av 

mønstre til å plukke ut noder fra en XML-struktur, på samme måte som i stilark som 

XSLT, og XML Binding Language (XBL) hvor elementer kan knyttes til scripts, stiler eller 

mer komplekse innholdsmodeller, på en enklere måte. 

20.01.2010 Versjon 1.1 51/89

DIFI 


Hendelser, for å abonnere på beskjeder om endringer i en dynamisk XML-struktur, for å 

overvåke framdriften av en operasjon, og for å åpne kanaler hvor tjeneren kan sende 

beskjeder om hendelser til klienten. 

Databasetilgang, for å lagre navn-verdi-par på klientsiden, og for å jobbe mot 

databaser på klientsiden ved hjelp av SQL. 

Kommunikasjon mellom klient og tjener, inkludert toveis kanaler. 

Programmeringsmodell for grensesnitt (API) og parallell prosessering (asynkront). 

Sikkerhet og tilgangskontroll for forespørsler på tvers av domener, kopiering og filvalg. 

Man utvikler dessuten et rammeverk for brukergrensesnittkomponenter som dynamisk eller 

deklarativt inkluderes i et brukergrensesnitt, kalt Widgets 1.0. Disse kan, i likhet med portlets, 

utgjøre brukergrensesnittet til en webtjenester. Denne familien av standarder skal dekke 

funksjonaliteten man i dag finner i proprietære rammeverk som Yahoo Konfabulator, Windows 

Vista Sidebar, Google Desktop Gadgets, Opera Widgets, Apple Dashboard, Nokia Web-Runtime 

og Joost. Landskapet som en gjenbrukbar widget blir anvendt i, illustrerer de slik: 

Figur 10. Arkitektur for dynamiske brukergrensesnitt for webtjenester [168]. 

4.6.8 Interaktivt multimedia og rike grensesnitt 

Metoder for enda rikere grensesnitt enn det en dynamisk webomgivelse med AJAX tilbyr, er 

foreløpig i liten grad standardisert. W3C har en standard for presentasjon av multimedia, 

Synchronized Multimedia Integration Language (SMIL) men denne dekker ikke interaktive 

brukergrensesnitt. Entusiaster for åpne standarder har demonstrert at rike grensesnitt kan 

lages ved hjelp av SVG [158] med scripts knyttet til brukerhendelser, uten at denne bruken er 

særlig utbredt. Manglende støtte i Internet Explorer har vært et problem. Verktøystøtten for 

designere er begrenset, selv om dette kan endres gjennom utvikling med åpen kildekode i 

tiden framover. Google har gjennom sin SVGWeb lagt muskler bak SVG som sitt svar på de to 

industristandarder som foreløpig dominerer, XAML fra Microsoft og MXML/SWF fra Adobe. SVG 

er dessuten egnet for mobile klienter, og en egen variant kalt SVG Tiny er definert for dette. 

Dette området bør overvåkes framover. SVG er allerede tatt inn i referansekatalogen som en 

av to standarder for grafikk. 

4.7 Samhandling, prosesser og komposisjon av tjenester 

Tjenesteorientert arkitektur dreier seg fundamentalt om å sette sammen basistjenester til 

høyere nivås tjenester som har verdi for en bruker. Slik sammensetting kalles ofte ”mashups”. 

Dette skjer gjennom portaler og andre brukergrensesnitt, men først og fremst gjennom 

20.01.2010 Versjon 1.1 52/89

DIFI 


prosesser hvor hvert steg er en tjeneste, eller andre metoder for koordinering av 

sammenhørende tjenester. Prosesser brukes også til å sikre transaksjonsegenskaper, og til å 

orkestrere kompleks ruting av meldinger i tjenestebusser og annen mellomvare. 

4.7.1 BPEL 

BPEL er en XML-basert beskrivelse av en prosess. BPEL realiserer prosessens interaksjon med 

andre aktører gjennom web service operasjoner. Hovedhensikten med BPEL er å gi en 

formalisert beskrivelse for å koordinere meldingsutvekslingen i en kompleks prosess. En 

prosess kan i BPEL defineres som en abstract og/eller som executable prosess. 

En abstrakt prosess skal ikke eksekveres. Hensikten med en slik beskrivelse er å 

representere prosessens meldingsutveksling til andre aktører, uten å avsløre 

prosessens interne implementasjon. Dette er altså en grensesnittbeskrivelse. 

En eksekverbar prosess definerer en fullstendig og presis modell som kan eksekveres i 

et datasystem. Beskrivelsen til en eksekverbar prosess skal inneholde interaksjon med 

andre parter gjennom webtjenester, og logikk for å koordinere interaksjon. 

Begge typene beskrives med samme konstruksjoner og syntaks. BPEL er basert på mange 

WS-standarder: WSDL for partner- og meldingsdefinisjon, XSD for datadefinisjon, samt XSLT 

og XPath for manipulering av data. Følgende hovedfunksjoner og elementer støttes av BPEL 

Forespørre og utføre web service operasjoner, 

Datavariable, enkle beregningsuttrykk og tilordning, 

Lenker til partnere og referanser til endepunkter, 

Meldingskorrelasjon, hvilke meldinger hører sammen, 

Atomiske og sammensatte, strukturerte aktiviteter , 

Feilhåndtering, kompensasjon for transaksjoner og håndtering av hendelser. 

Den seneste versjon er WS-BPEL 2.0 som forvaltes av OASIS [97]. BPEL erstattet tidligere 

forslag fra Microsoft og IBM som Xlang og WSFL. 

4.7.1.1 BPEL4People og WS-HumanTask 

BPEL4People [1] er en utvidelse av BPEL for å støtte menneskelig interaksjon i en prosess. 

Den ble forelått av IBM og SAP i 2005. Interaksjonen er definert gjennom roller, som knytter 

brukere til oppgaver og tjenester. Metoden gjør det mulig å definere oppgaver i en prosess og 

knytte dem opp til en rolle eller til en bestemt bruker. Typiske scenarioer blir håndtert, som 

delegering, eskalering og behovet for å ha flere personer til å se på en oppgave. 

I 2007 ble det gitt ut en oppdatering hvor dette forslaget er integrert med et parallelt initiativ 

kalt WS-HumanTask [2]. Nå inkluderer bidragsyterne bl.a. Adobe, BEA, IBM, Oracle and SAP. 

Dette arbeidet videreføres nå i en egen teknisk komité i OASIS. Forslaget er allerede 

implementert i BPM-system fra store leverandører. 

Konseptet til WS-HumanTask er å definere generiske tjenester som beskriver menneskelig 

interaksjon med en prosess, gjennom oppgaver i en tjenesteorientert omgivelse. Forslaget 

definerer to typer grensesnitt, det første når et menneske tilbyr en tjeneste gjennom en 

oppgave, den andre når et menneske bruker en tjeneste. 

Disse standardene baserer seg på WSDL 1.1, XML Schema 1.0, XPath, WS-Addressing, WS- 

Coordination, og WS-Policy. 

4.7.2 WS-CDL 

Web Services Choreography Description Language (WS-CDL), tidligere også kjent som WSCI 

og WS-Choreography, er en kandidat til standard fra W3C [204]. Den har imidlertid ikke blitt 

anbefalt som standard på 4 år, og er ikke implementert av mange store leverandører. 

WS-CDL er et språk for å beskrive hvordan autonome og likestilte deltakere (peer-to-peer) 

skal samarbeide. Dette skiller seg fra orkestreringsløsninger som BPEL, som ser prosessen 

20.01.2010 Versjon 1.1 53/89

DIFI 


som styrende for de partnernes handlinger, og partnerne reduseres til å svare på definerte 

forespørsler om webtjenester. En koreografibeskrivelse er en kontrakt som beskriver 

deltagernes observerbare atferd, og organiserer meldingsutvekslingen mellom dem for å 

oppnå et felles mål. 

4.7.3 ebXML BPSS 

ebXML sin meldingsutvekslingsstandard (ebMS) og datadefinisjonstilnærming (Core 

Components) fortsatt er i utstrakt bruk, og gjenstand for løpende standardisering i ulike 

sektorer av elektronisk forvaltning og forretning. ebXML sin standard for prosesser, BPSS eller 

ebBP, har ikke vært like utbredt. Dens tilnærming er koreografi, i likhet med WS-CDL, men her 

defineres samarbeid mellom partnere som en overbygning over flere prosesser. BPSS utgjør 

ikke et alternativ til BPEL, men noe arbeid er gjort for å bruke BPSS som en spesifikasjon for 

elektronisk forretning og forvaltning på toppen av BPEL [45]. På dette området konkurrerer de 

delvis med mer generelle standarder fra OMG, som omhandles i avsnitt 4.10.1. 

4.7.4 WS-CAF – Composite Applications Framework 

Dette var en arbeidsgruppe i OASIS som utviklet standarder for å koordinere avhengigheter 

mellom ulike applikasjoner og tjenester. De jobbet med tre områder, hvorav to, Coordination 

Framework (WS-CF [99]) og Transaction Management (WS-TXM) ble videreført i WS- 

Transactions, se nedenfor. Den tredje, WS-Context [98], ble til en standard som sørger for 

deling av informasjon om underliggende infrastruktur og pågående sesjoner mellom ulike 

endepunkter, delvis overlappende med WS-MetadataExchange (4.3.2.5). 

4.7.5 WS-Transactions 

Denne arbeidsgruppen i OASIS har utviklet 3 standarder for transaksjonshåndtering på tvers 

av tjenester og endepunkter. 

WS-AtomicTransaction [100] definerer protokoller for å sørge for atomiske 

transaksjoner hvor alle steg eller ingen blir utført, f.eks. ved hjelp av to-fase låsing 

(two phase commit). 

WS-Coordination [102] spesifiserer tjenester som brukes til å skape en 

koordineringskontekst for en aktivitet, til å registrere deltagere i denne aktiviteten, og 

til å skape enighet om aktiviteten er avsluttet komplett og korrekt. De øvrige 

transaksjonsprotokollene bygger på denne. 

WS-BusinessActivity [101] er en protokoll for lengelevende aktiviteter basert på 

kompensering. Både atomiske og mer komplekse resultatkrav håndteres. To ulike 

protokoller er definert basert på om de deltagende tjenestene selv vet når deres del av 

aktiviteten er ferdig, eller om dette bestemmes av en sentral koordinator. 

Disse standardene støttes av flere store leverandører av mellomvare. 

4.7.6 Overvåking og styring av prosesser 

BPAF (Business Process Analytics Format) [207] er en ny standard under utvikling fra WfMC 

som definerer et verktøyuavhengig format for å beskrive hendelser som inntreffer i løpet av 

eksekveringen av en prosess. Hendelsene dreier seg om oppstart og avslutning av aktiviteter, 

tjenestekall, applikasjonshendelser og infrastrukturhendelser. Ved hjelp av BPAF kan samme 

styringsverktøy brukes til å følge opp prosesser som kjører i ulike omgivelser. 

4.7.7 Business Centric Methodology (BCM) og Content Assembly Mechanism (CAM) 

BCM [86] skiller seg fra andre standarder på området ved å være drevet fram av brukerne, 

heller enn leverandørene. Offentlig sektor, særlig forsvar, helse og omsorg, har vært i fokus. 

Samtidig finnes det ikke støtte for denne standarden hos noen av de store leverandørene. Det 

finnes imidlertid en implementasjon med åpen kildekode. Standarden er utviklet med norsk 

deltagelse fra Sintef og eprForum. 

20.01.2010 Versjon 1.1 54/89

DIFI 


BCM kan være interessant fordi den dekker et område som i dag styres av proprietære 

løsninger, nemlig dynamisk sammensetting av applikasjoner fra innhold, webtjenester og 

annen funksjonalitet. BCM befinner seg således på et høyere abstraksjonsnivå, nærmere 

brukerne enn andre standarder. Målet er å sette sluttbrukere i stand til å skreddersy sine egne 

løsninger, gjennom tilpasning og anvendelse av maler (templates). Malene brukes på fire lag 

av arkitekturen: Implementasjon, utvidelser, forretningsoperasjon og konsepter, og kan 

defineres for ulike sektorer, organisasjoner og spesifikke prosesser. Malene skaper 

organisatorisk og semantisk interoperabilitet gjennom kontrakter som innholder svar på 6 

spørsmål: Hvorfor? Når? Hva? Hvor? Hvordan? Hvem? Beslutningspunkter (choice points) i 

malene styrer hvilket innhold som skal inkluderes, basert på informasjon om hvilken 

forretningssammenheng (context) brukeren befinner seg i. Beslutninger kan delegeres til 

eksterne webtjenester, inkludert BPEL-prosesser. 

BCM kan ses på som en metodikk for arkitektur, som knytter sammen modelleringsmetoder og 

tekniske standarder Søskenstandarden Content Assembly Mechanism (CAM) [87] definerer 

maler for operative løsninger. CAM prosesserer XML, først og fremst for konstruksjon og 

validering av meldingsinnhold, men mekanismen kan også brukes for brukergrensesnitt eller 

prosesser. 

4.7.8 Andre standarder 

BPML, SWAP, WSFL, WSCI, WSCL og XLang er blant de mange standarder og forslag innenfor 

dette området som i praksis er erstattet av løsningene over. WS-CAF og WS-CDL ser heller 

ikke ut til å ha stor støtte bak seg. 

4.8 Sikkerhet og pålitelighet 

Sikkerhet er kanskje den viktigste tjenestekvaliteten. Det er i hvert fall det området hvor 

standardisering har kommet lengst. Dette avsnittet beskriver sikkerhetstillegg for 

tjenestelaget, og standarder for å autorisere brukeres adgang til tjenester, informasjon og 

andre ressurser. Sikkerhetsmekanismer på transportlaget og andre deler av infrastrukturen er 

utenfor fokus for denne studien, men blir nevnt med der hvor standarder for tjenesteorientert 

arkitektur refererer til dem. 

4.8.1 eID og ID-porten 

Rammeverket for eID og PKI i offentlig sektor definerer [34]: 

4 risikonivåer – ingen (1), liten (2), moderat (3), og stor (4) 

4 sikkerhetsnivåer tilsvarende de 4 risikonivåene, med ulike krav til løsninger: 

o Autentiseringsfaktorer - antall, om de er statiske eller dynamiske, om de kan 

lagres eller ikke 

o Utlevering til bruker 

o Offentlig godkjenning 

o Uavviselighet, logging 

3 sertifikatklasser: Person standard (nivå 3), Person høyt (nivå 4), Virksomhet (nivå 4) 

ID-porten som implementerer felles autentiseringsløsning for offentlig sektor (MinID), er laget 

med Sun OpenSSO. Denne plattformen bruker eller tilbyr flere av standardene beskrevet i 

avsnittene nedenfor: 

SAML 2.0 for autentiseringsmerker og føderert engangs innlogging 

SPML 2.0 for identitetsforvaltning 

XACML 2.0 for autorisasjon 

WS-Federation for engangs innlogging 

WS-Trust for å etablere tillitsområder mellom ulike tjenere 

20.01.2010 Versjon 1.1 55/89

DIFI 


WS-Security for autentisering og integritet, med X.509, Kerberos, og enkel brukernavnpassord-merking 

WS-SecurityPolicy for spesifikasjon av ulike sikkerhetsregler 

XML Signature og XML Encryption for å sikre integriteten til meldingsinnholdet, 

gjennom en egen komponent, kalt ”Fedlet” 

OpenId for innlogging på lavt sikkerhetsnivå 

Alle disse standardene er aktuelle for ID-porten, selv om f.eks. OpenId ikke gir kobling til 

fødselsnummer som er sentralt for autentisering mot offentlige tjenester. Versjon 3 av MinId 

bruker foreløpig SAML og X.509, mens framtidige versjoner gjennom EU-samarbeidet STORK 

vil se på blant annet WS-Federation, WS-Trust og XAdES [25], som bruker XML Signature. 

SPML og XACML er aktuelle når identitetshåndtering og autorisasjon til offentlige registre blir 

vurdert. ID-porten følger dessuten arbeidet til Liberty Alliance med profiler for sikkerhet og 

autentisering i eForvaltning [72]. For sikkerhetsnivå 4 er det lite trolig at engangs innlogging 

vil bli brukt, siden løsningene som er tilgjengelig i markedet ikke tilfredsstiller kravene på 

dette nivået. 

4.8.2 SAML 

Security Assertion Markup Language (SAML) er en standard fra OASIS [89]. Den er nå i 

versjon 2.0, og versjon 1.0 og 1.1 ble også akseptert som standarder. SAML definerer hvordan 

ulike sikkerhetsdomener kan utveksle informasjon om autentisering og autorisasjon, ofte 

utsagn (assertions) som produseres av en identifikasjonsleverandør (identity provider) og 

brukes av ulike tjenesteleverandører. Det viktigste bruksområdet er å sørge for engangs 

innlogging (single sign-on), hvor SAML har blitt den dominerende metoden. Standarden består 

av flere deler: 

En kjerne med standard syntaks og semantikk for sikkerhetsutsagn, og protokoller for å 

forespørre og utveksle meldinger om slike utsagn. 

Bindinger for hvordan meldingene overføres med bl.a. SOAP, gjennom synkron 

overføring, og regler for bruk av sikkerhet på transportlaget. 

Profiler for hvordan SAML kan brukes i ulike scenarioer (use cases), f.eks. engangs 

innlogging i web-applikasjoner (Holder-of-Key), som Id-porten vil følge. 

Metadata, et utvidbart format for å beskrive elementene i en sikkerhetsarkitektur, som 

identifikasjonsleverandør, tjenesteleverandør, tilknytning, attributtautoritet, attributtkonsument, 

og beslutningspunkt (policy decision point). 

Autentiseringssammenhenger for egendefinerte og standard sammenhenger (contexts) 

for internett, mobile nettverk, telekommunikasjon m.m. med ulike sikkerhetsnivåer. 

Krav for konformitet, hvilke spesifikasjoner og XML Schemas som må brukes for at en 

implementasjon kan sies å følge SAML, for ulike komponenter i en SAML-arkitektur. 

WS-Security (se nedenfor) inneholder en profil som knytter SAML-utsagn til meldinger til og 

fra webtjenester. 

4.8.3 XACML 

eXtensible Access Control Markup Language (XACML) er en standard fra OASIS [88]. Den er 

nå i versjon 2.0, og versjon 1.0 og 1.1 ble også akseptert som standarder, mens 3.0 er 

tilgjengelig som utkast. XACML brukes til å definere adgangskontroll (access control policies) 

for autorisasjon, gjennom å tildele eller nekte subjekter som brukere, roller eller grupper, 

adgang til å utføre ulike aksjoner på ressurser i en omgivelse. Desentralisert adgangskontroll 

gjøres mulig gjennom delegering til andre subjekter, og bruk av flere beslutningspunkter 

(policy decision points - PDP). For forenkling knyttes reglene gjerne til attributter som 

beskriver subjektene og ressursene, og XACML inneholder et regelspråk med en lang rekke 

funksjoner for å definere sammensatte adgangsspesifikasjoner. 

Der SAML fokuserer på autentisering med noe støtte for autorisasjon, konsentrerer XACML seg 

om autorisasjon. XACML kan bygge på SAML. Ved siden av kjernespesifikasjonen består 

20.01.2010 Versjon 1.1 56/89

DIFI 


standarden av profiler for rollebasert adgangskontroll (RBAC), hemmeligholdelse, hierarkiske 

ressurser og samtidig tilgang til flere ressurser, samt dokumenter som beskriver hvordan 

standarden skal bruke SAML og XML Digital Signature. XACML 2.0 bygger på XML Schema 1.0, 

XSLT 1.0, XPath 2.0, XQuery 1.0, og benytter attributter definert som del av LDAP, eller ved 

hjelp av SAML. 

Det foreslås stadig nye rammeverk som bygger på XACML. Oracle har f.eks. drevet fram et 

Identity Governance Framework (IGF) bestående av AAPML (Attribute Authority Policy Markup 

Language) som brukes til å styre tilgangen til data om brukere fra applikasjoner, og CARML 

(Client Attribute Requirement Markup Language) som brukes til å spesifisere hvilke brukerdata 

ulike applikasjoner bruker. 

4.8.3.1 SPML – Service Provisioning Markup Language 

SPML fra OASIS er et standard språk i XML for å utveksle informasjon om brukere, ressurser 

og tjenesteleveranser mellom ulike virksomheter [92]. Dette gir en åpen løsning for definisjon 

av brukeres eller systemers rettigheter til å bruke ulike tjenester. Tilnærmingen baserer seg 

på at forespørsler går via et eller flere tjenesteleveransesystem (service provisioning system), 

som sjekker adgangsrettigheter og deretter kaller opp de ressurser og tjenester som faktisk 

leverer tjenesten. 

SPML sprang ut fra arbeidet med en tidligere spesifikasjon som het WS-Provisioning. Den 

benytter sikkerhetsspesifikasjoner i SAML (avsnitt 4.8.2), og koder informasjonen i henhold til 

Directory Services Markup Language (DSML) eller sitt eget XML Schema. DSML er en OASISstandard 

for XML-representasjon av LDAP (Lightweight Directory Access Protocol). Mens 

kataloger som UDDI inneholder tjenester, identifiserer LDAP brukere, brukergrupper, og 

kanskje ressurser som møterom, printere og dokumenter. Ressursbegrepet i forvaltningsstandarder 

for webtjenester kan til en viss grad sies å bygge bro mellom disse katalogtypene 

(jf. avsnitt 4.3.3). 

4.8.4 WS-Security 

Den mye brukte OASIS-standarden WS-Security består av en kjernespesifikasjon [115] som 

beskriver utvidelser til SOAP for å sikte integritet og konfidensialitet. Kjernen definerer også en 

generell mekanisme for å knytte sikkerhetsmerking (security tokens) til meldingsinnholdet. 

Denne løsningen er uavhengig av hva slags merking man vil bruke, men i tillegg til kjernen 

defineres 6 profiler for slik merking: 

Username Token Profile [116] for å sende brukernavn og kanskje passord som 

autentisering av den som kommer med forespørselen. 

X.509 Token Profile [117] beskriver hvordan X.509-sertifikater kan sikre autentisering 

og integritet for meldinger til/fra webtjenester. 

SAML Token Profile [118] beskriver hvordan man kan knytte inn SAML 1.0 og 2.0 

spesifikasjoner til meldingene. 

Kerberos Token Profile [119] beskriver hvordan Kerberos-billetter kan sikre gjensidig 

autentisering av klient og tjener. 

Rights Expression Language (REL) Token Profile [120] beskriver hvordan ISO/IEC 

21000-5 kan brukes til å styre autorisasjon til å bruke webtjenester. 

SOAP with Attachments (SWA) Profile [121] knytter WS-Security sammen med 

mulighet til å sende deler av meldingene i andre formater enn XML, som vedlegg. 

Merkingen kan være signert (Kerberos, X.509) eller usignert, og innholder en eller flere 

påstander som kan verifiseres av en ekstern autoritet. Signaturer brukes til å garantere 

meldingens integritet og avsenders identitet. XML Signature [200] sørger for integritet, mens 

XML Encryption [192] beskytter meldingens konfidensialitet, se for øvrig avsnitt 4.8.5. 

Rammeverket er svært åpent, siden fremtidige standarder for merking lett kan legges til som 

nye profiler. En mekanisme for å beskrive nye merker er standardisert, sammen med løsninger 

for XML-representasjon av merker, binær koding av merker, og trygg innkapsling av merker 

som uvedkommende ikke kan få innsyn i. 

20.01.2010 Versjon 1.1 57/89

DIFI 


Ved siden av de grunnleggende profilene for webtjenester (se avsnitt 4.2.5), definerer WS-I en 

egen profil for sikre og pålitelige tjenestearkitekturer [211]. Denne baserer seg på WS- 

Security, og legger til retningslinjer for hvordan disse løsningene knyttes opp til andre profiler 

fra WS-I. 

4.8.4.1 WS-SecurityPolicy 

Denne standarden [111] definerer hvordan WS-Security, WS-Trust og WS-SecureConversation 

gjør bruk av WS-Policy (avsnitt 4.3.2.4), på en slik måte at de blir uavhengig av hvilken 

versjon av WS-Policy som brukes. En rekke standard regler (policies) blir definert for 

beskyttelse, sikkerhetsmerking (tokens), transportsikkerhet, krypteringsalgoritmer og 

signering av meldinger. 

4.8.4.2 WS-SecureConversation 

WS-SecureConversation [112] fra OASIS utvider WS-Security med et rammeverk for å 

forespørre og utveksle sikkerhetsmerking (tokens). Løsningen baserer seg på etableringen av 

en sikkerhetssammenheng (security context) hvor nøkler og annen sikkerhetsinformasjon kan 

utveksles trygt. Sammenhengen etableres ved hjelp av WS-Trust, og autentiseres ved hjelp av 

et eget merke (security context token) i tråd med WS-Security. 

4.8.4.3 WS-Trust 

WS-Trust [113] fra OASIS utvider WS-Security med et rammeverk for å utstede, fornye og 

validere sikkerhetsmerker (tokens), og for å megle fram og avklare tillitsrelasjoner mellom 

aktørene. Standarden introduserer 

Sikkerhetsmerketjeneste (Security Token Service - STS), en webtjeneste som utsteder 

merker 

Standardformater for meldingene som brukes til å forespørre og utveksle merker (som 

WSDL-tjenester) 

Mekanismer for utveksling av nøkler. 

Ulike tillitsmodeller støttes for å initiere kommunikasjonen, som faste rot-autoriteter, 

hierarkiske sertifikater og eksterne autentiseringstjenester. 

4.8.4.4 WS-Federation 

WS-Federation ble opprinnelig foreslått av Microsoft, IBM, BEA, Verisign og RSA i 2003, og 

implementert i flere verktøy. En arbeidsgruppe ble opprettet i OASIS, og standarden ble 

godkjent i mai 2009 [114]. Den beskriver språk og protokoll for megling av identitet, 

sikkerhetsattributter, autentisering og autorisasjon mellom ulike domener som inngår i en 

føderasjon. Dette gjør at et domene kan gi tilgang til ressurser i andre domener, eller 

autentisere brukere for andre domener. 

WS-Federation bygger på WS-Security, WS-Trust, WS-SecurityPolicy, WS-Policy, WS- 

MetadataExchange, WS-Eventing, WS-ResourceTransfer og WS-Adressing. WS-Federation fikk 

kritikk av miljøet bak SAML, Liberty Alliance, fordi den har overlappende funksjonalitet med 

SAML, særlig for engangs innlogging. I den endelige standarden har man derfor lagt seg 

tettere opp til SAML, og man foretrekker SAML som mekanisme for å definere 

sikkerhetsutsagn, selv om også andre mekanismer tillates. WS-Federation baserer seg 

dessuten på WS-Eventing, som ikke er en godkjent standard, og ikke WS-Notification (se 


4.8.5 XML kryptering og signering 

W3C definerer to fundamentale standarder for sikring, integritet og uavviselighet av 

meldingers innhold. 

4.8.5.1 XML Signature Syntax and Processing 

XML Signature eller DSIG [200] brukes til å signere en ressurs, som kan være en hvilken som 

helst URI, og som ofte er et XML-dokument eller en identifiserbar del av et slikt dokument. 

20.01.2010 Versjon 1.1 58/89

DIFI 


Signaturen kan være frikoblet fra innholdet (detached), inkludert som en del av innholdet 

(enveloped), eller den kan selv fungere som konvolutt og innkapsle innholdet (enveloping). 

XML Signature brukes av WS-Security og SAML, og signering valideres med nøkler fra X.509, 

PGP, SPKI eller RSA/DSA. ETSI definerer en standard profil for XML Signature, XAdES [25], 

som blir brukt av ID-porten. Tilsvarende profiler finnes dessuten for signering av pdf (PAdES). 

4.8.5.2 XML Encryption Syntax and Processing 

XML Encryption [192] kan brukes til kryptering av alle typer innhold, inkludert XMLdokumenter 

eller deler av disse. Det krypterte innholdet gjenfinnes i en XML-struktur, og 

standarden definerer hvordan man kan spesifisere krypteringsalgoritmer og nøkler i XML. Ulike 

krypteringsmetoder og algoritmer støttes, og begreper fra XML Signature gjenbrukes. 

4.8.5.3 Nøkkelforvaltning med XKMS 

XML Key Management Specification (XKMS) [195] er en standard fra W3C som spesifiserer 

protokoller for å registrere og distribuere offentlige nøkler (public keys), for bruk i tilknytning 

til XML Signature og Encryption. Slike systemer består av to tjenester: 

X-KISS - XML Key Information Service Specification som gjør det mulig for en klient å 

delegere all prosessering av XML-signaturer til en XKMS-tjeneste. 

X-KRSS - XML Key Registration Service Specification som gjør det mulig å knytte 

informasjon til en nøkkel for registrering av hvem som bruker den, som sertifikater, 

attributter, tillits- og styringsinformasjon. 

XKMS støtter ulike standarder for PKI som X.509, SPKI, PGP, og ulike krypteringsalgoritmer. 

4.8.6 Åpne industristandarder for autentisering og autorisasjon 

OpenId [133] er et åpent, desentralisert rammeverk for autentisering av brukere på weben, 

som anvendes av en lang rekke sentrale leverandører og websites. Løsningen er utformet for å 

passe i AJAX-omgivelser. OAuth er et API for delegert autorisasjon som fungerer bra sammen 

med OpenId og tilsvarende løsninger. 

4.8.7 Pålitelig meldingsutveksling 

WS-ReliableMessaging fra OASIS [109] definerer elementer for meldingshoder i SOAP som kan 

brukes til å sikre pålitelig overføring av meldinger, gjennom kvitteringer, sending om igjen, og 

feilmeldinger. En tidligere spesifikasjon kalt WS-Reliability gjorde mye av det samme, og den 

er nå samordnet med WS-ReliableMessaging. 

4.8.8 ISO/IEC 27000 

Denne familien av standarder [56] for informasjonssikkerhet avklarer begreper, og gir en 

oversikt over ulike metoder og hvordan de kan brukes sammen. Det er en standard mer på 

organisatorisk nivå, som ikke er knyttet til en bestemt teknisk implementasjon. Familien 

består av en rekke eksisterende standarder og noen som er under utvikling: 

27001 – spesifikasjon av et generelt styringssystem for informasjonssikkerhet 

27002 – beskriver et hundretalls ulike styringsmekanismer som kan benyttes i et 

system for informasjonssikkerhet 

27003 – retningslinjer for implementering av et styringssystem for 

informasjonssikkerhet 

27004 - målemetoder og –parametere for informasjonssikkerhet (under utarbeidelse) 

27005 – generell tilnærming til risikohåndtering, ikke knyttet til noen bestemt metode 

27006 – retningslinjer for akkreditering av organisasjoner som tilbyr sertifisering av 

styringssystem for informasjonssikkerhet 

20.01.2010 Versjon 1.1 59/89

DIFI 


4.9 Avhengigheter mellom standarder 

Figur 8 på side 31 introduserte en oversikt over standarder for webtjenester. Figuren nedenfor 

viser avhengighetene mellom disse. De viktigste avhengighetene er illustrert, men lenker til 

kjernestandardene SOAP, WSDL, XML og XML Schema er skjult for å unngå en for kompleks 

figur. 

I tillegg til de viste avhengighetene innen definisjonen av standarder, kan selvfølgelig 

standarder kobles sammen i bruk. For eksempel kan man bruke WS-Security og WS- 

ReliableMessaging til å øke sikkerhet og pålitelighet i forbindelse med alle de andre 

standardene. 

WSDM 

WS- 

Notification 

XML 

Namespaces 

XML 1.0 

WS-Resource 

Framework 

WS- 

Fragment 

4.10 Modellering av tjenester 

Figur 11. Avhengigheter mellom standarder for webtjenester. 

Hittil har vi sett på standarder som brukes operativt i en tjenesteorientert arkitektur. Nå er det 

på tide å se på metoder og retningslinjer for utvikling av slike løsninger. Her tar vi for oss 

rammeverk og spesifikke metoder for modellering av prosesser, applikasjoner og tjenester, 

samt virksomhetsarkitekturer for styring og forvaltning av tjenesteporteføljer. 

4.10.1 Prosesser og sammenstilling av tjenester 

Fokus på prosesser et fundamentalt trekk ved tjenesteorientering [59]. En tjeneste, en 

aktivitet noen utfører for noen andre, inngår ofte som et steg i en større prosess. Ulike 

standarder for prosessmodellering har derfor spilt en viktig rolle i utvikling av 

tjenesteorienterte arkitekturer, for å identifisere hvilke IKT-tjenester man bør implementere, 

og for å knytte IKT-tjenestene sammen til forretningstjenester. 

4.10.1.1 IDEF 

WS- 

Management 

WS-Eventing 

WS-Resource 

Transfer 

WS- 

Discovery 

UDDI 

WS- 

Inspection 

WS-Transfer 

WS- 

Federation 

WS- 

Enumeration 

WSDL 1.1 WSDL 2.0 

SOAP 1.1 

XML Schema 

1.0 

WS-Metadata 

Exchange 

WS- 

Adressing 

WS-Trust 

SOAP 1.2 

XML Schema 

1.1 

WS-Security 

Policy 

WS-Policy 

WS-Secure 

Conversation 

WS-Remote 

Portlets 

SOAP MTOM 

IDEF (Integrated Definition) [48] er en tidlig standard for strukturert analyse og design av 

programvare. IDEFØ for modellering av funksjoner og prosesser, og IDEF1X for 

datamodellering er de mest brukt brukte notasjonene. De er standardisert av henholdsvis 

20.01.2010 Versjon 1.1 60/89 

XOP 

WS-Reliable 

Messaging 

WS- 

Transaction 

WS-BPEL 

WS-Security 

SOAP with 

Attachments 

MIME 

SPML 

WS-CAF 

Context 

XPDL 

XForms 

SAML 

EXI 

XML Info.Set 

WS-CDL 

Choreography 

BCM 

CAM 

XML 

Encryption 

XML 

Signature 

XSLT 

XPath

DIFI 


NIST og IEEE. IDEFØ definerer prosesser bestående av funksjoner, og funksjoner kan 

dekomponeres som prosesser. Ved siden av inn- og ut-flyt for sekvensering, kan man også 

definere kontrollflyt som styrer funksjonen, og mekanismer som brukes til å utføre funksjonen. 

Mange seinere språk og dialekter baserer seg på dette mønsteret, selv om langt fra alle tar 

med kontrollflyt og mekanismer. I utgaven som NIST standardiserte har man dessuten lagt til 

kall til andre funksjoner som spesiell type mekanisme, egnet f.eks. for webtjenester. 

4.10.1.2 BPMN 

BPMN (Business Process Model and Notation, tidligere Modeling Notation) [122] er en nyere 

standard for prosessmodellering fra OMG. Den er definert i forbindelse med tjenesteorientert 

arkitektur. Ved siden av prosesser som består av aktiviteter, hendelser, flyt og 

beslutningspunkter mellom dem, kan en prosess i BPMN inndeles i ulike svømmebasseng 

(pools) og -baner (swimlanes). Hver bane kan f.eks. definere en rolle, en organisasjon, eller et 

lag i en lagdelt arkitektur. Slik får man tydelige skiller, f.eks. mellom tjenesteleverandør og 

bruker, og man kan skille interne prosesser fra eksterne grensesnitt for kommunikasjon og 

tjenesteyting. Man har også enkel modellering av dataflyt, selv om mange verktøy velger å 

representere datastrukturene i en melding med andre språk, nærmere knyttet til XMLstrukturene. 

Versjon 2.0 legger dessuten til modellering av samarbeid, samtaler (conversation) og 

koreografi, som interaksjon mellom aktører. BPMN har en klart definert semantikk for 

eksekvering, og noen leverandører implementerer da også sitt BPMS (Business Process 

Management System) gjennom direkte tolkning av BPMN-modeller. Andre konverterer BPMN til 

BPEL, en transformasjon som også er standardisert. Gjennom OMG har BPMN fått en 

spesifikasjon som følger standarder for objektorientert modellering (MOF, UML), men også en 

langt mer kompleks spesifikasjon enn de første versjonene. 

4.10.1.3 UML aktivitetsdiagram 

Før BPMN ble tatt over av OMG hadde man der også definert egne språk for 

prosessmodellering. I UML er aktivitetsdiagram sentralt for representasjon av prosesser. Selv 

om dette språket er utviklet for å definere prosessene som foregår i programvaren, ikke i 

virksomheten, blir det pragmatisk brukt også på virksomhetsnivået. I de siste versjonene har 

aktivitetsdiagrammer blitt enda mer rendyrket som språk for IKT-nivået, underordnet 

objektklasser og med konstruksjoner fra programmeringsspråk som løkker og betingelser. 

4.10.1.4 XDPL 

XPDL (XML Process Definition Language) [206] fra WfMC er siste generasjon av en standard 

for prosessmodellering som har utviklet seg over 15 år. Opprinnelig en av fem standarder for 

arbeidsflyt og BPM, er XPDL nå blitt til et standard XML filformat for BPMN-modeller, som 

mange verktøy for eksekvering, simulering og overvåking er i stand til å utveksle. 

4.10.1.5 BPDM 

BPDM (Business Process Definition Metamodel) [123] er et forsøk fra OMG på å definere et 

utvekslingsformat i XML for prosessmodeller. BPDM bringer sammen UML aktivitetsdiagram og 

BPMN til et felles format for transformasjon til eksekvering i f.eks. BPEL. BPMN hadde allerede 

definert direkte transformasjon til BPEL fra dag 1, så fokuset ble raskt utveksling mellom ulike 

prosessmodelleringsspråk, først og fremst i OMG-familien. BPDM har konkurranse fra XPDL, en 

etablert standard som i motsetning til BPDM er implementert mange leverandører. BPDM 

fokuserer mer på det semantiske nivået, mens XPDL er sterkere på overføring av også de 

grafiske aspektene ved en prosessmodell. BPDM er dessuten svært generell, og i motsetning til 

XPDL lite spesifikt tilpasset prosessmodellering. Løfter om åpent tilgjengelige verktøy som 

skulle demonstrere BPDM fra modeldriven.org er ikke oppfylt, og materialet om BPDM er ikke 

lenger profilert der. Standarden virker altså ikke å ha så mye kraft bak seg. 

4.10.1.6 Dynamic Business Activity Modeling 

De fleste løsninger for BPM baserer seg på en modell hvor prosessene er definert på forhånd, 

og samme modell brukes til å styre mange forekomster. Alle beslutninger om hvilke aktiviteter 

som skal utføres når, fattes av prosessmotoren basert på lokale data og predefinerte regler. 

20.01.2010 Versjon 1.1 61/89

DIFI 


Mange prosesser, f.eks. innen saksbehandling, krever større rom for skjønnsmessige 

vurderinger og menneskelig styring. OMG har startet et standardiseringsarbeid for slike 

prosesser, i tilknytning til BPMN [17]. 

4.10.1.7 Andre standarder 

Tidligere har en lang rekke standarder og forslag blitt fremsatt for prosessmodellering i 

tilknytning til tjenesteorientert arkitektur, uten å få stort gjennomslag, blant annet 

BPDL – et språk for avbilding (depiction) av prosesser slik at de skal være mer 

forståelige for folk som ikke er IKT-eksperter 

BPQL – et språk for å søke (query) etter prosesser i lagre av modeller 

ebBP/BPSS fra ebXML 

PIP (Partner Interface Process) fra RosettaNet 

ITIL, eTOM, SCOR, VCOR og andre rammeverk som beskriver beste praksis prosesser innen 

ulike sektorer og funksjoner har hatt mer suksess. 

4.10.1.8 Mønstre i arbeidsflyt 

Ved siden av språk for prosessmodellering er det viktig å vurdere hvilke mønstre av 

prosessflyt som et BPMS støtter [213]. Slike mønsterkataloger kan også være en god kilde til 

ideer for å koble sammen tjenester til høyere nivå virksomhetstjenester. 

4.10.2 Modelldrevet utvikling av tjenester 

Tjenesteorientering krever metoder som muliggjør: 

Klar definisjon av roller, myndighet og eierskap 

Langsiktig visjon, iterativ utvikling av tjenesteporteføljer 

Strategi for informasjon, grensesnitt og funksjonalitet 

Hyppige leveranser, målbarhet av kostnader mot nytte 

Gjenbrukbar design 

Tverrgående virksomhetspolitikk for organisasjonsenheter 

Kontinuerlig samarbeid mellom arkitekter, forretningsanalytikere, utvikling og drift 

Tjenester kan realiseres med ulik granularitet, fra fullstendige applikasjonsløsninger til enkle 

prosedyrekall. Ulike nivåer krever ulike organiseringsprinsipper. Derfor finnes det flere 

tilnærminger til modelldrevet utvikling av tjenesteorienterte arkitekturer. 

4.10.2.1 UML og MDA 

UML [124] er den dominerende modelleringstilnærmingen til utvikling av programvare. UML er 

objektorientert, med god støtte for å definere komponenter og deres grensesnitt. En mer 

funksjonell, tjenesteorientert tilnærming er mulig gjennom use cases og aktiviteter, men dette 

er i utgangspunktet underordnet objektstrukturene. UML definerer f.eks. tjeneste ganske 

snevert som en funksjonell, tilstandsløs komponent som beregner en verdi. OMG har imidlertid 

definert en rekke spesialtilpassede profiler av relevans for tjenesteorientert arkitektur, som 

SOAML (se neste avsnitt) 

EDOC (Enterprise Distributed Object Computing), som bl.a. inkluderer en Component 

Collaboration Architecture i tråd med ebXML BPSS, samt modellering av 

forretningsprosesser, hendelser, organisasjons- og informasjonsenheter. 

CWM (Common Warehouse Model) for datavarehus og andre registre 

BMM (Business Motivation Model) for virksomhetsplaner 

SVBR (Semantics of Business Vocabulary and Business Rules) for regler på 

forretningsnivå 

20.01.2010 Versjon 1.1 62/89

DIFI 


PRR (Production Rule Representation) for regler på implementeringsnivå 

ODM (Ontology Definition Metamodel) for begrepsmodeller 

RAS (Reusable Asset Specification) for gjenbruk og flerbruk 

SysML (Systems Modeling Language) for produktutvikling 

UML Profile for Enterprise Application Integration 

UML Profile for Data Distribution 

AMP (Agent Metamodel & Profile) under utarbeidelse. 

EMP (Event Metamodel & Profile) under utarbeidelse. 

VDM (Value Delivery Modell) under utarbeidelse. 

I tillegg til disse finnes en lang rekke domenemodeller for ulike virksomhetsområder. 

4.10.2.2 SOAML 

SOAML (Service Oriented Architecture Modeling Language) [125] er UML-profilen for 

tjenesteorientert arkitektur. Den definerer modelleringsspråk for 

Identifikasjon av tjenester, kravene de skal møte, og forventede avhengigheter mellom 

dem, 

Spesifikasjon av tjenester, deres funksjonalitet, hvilke forventninger som stilles til 

brukerne av tjenestene, protokoller og informasjonsutveksling, 

Definisjon av tjenestebrukere og –leverandører, hvilke tjenester de anvender og tilbyr, 

hvordan de kobles sammen, og hvordan tjenestene er implementert slik at 

spesifikasjoner og krav blir fulgt, 

Regler (policies) for bruk og leveranse av tjenester, 

Klassifikasjonsrammer med aspekter som støtter et bredt utvalg av oppdelingsmåter og 

begrensninger på arkitektur, organisasjon og fysiske komponenter, 

Kobling av tjenester og tjenestekrav til relaterte modeller som BMM planer, BPDM 

prosesser, BPMN 2.0, UML use cases, SBVR, ODM, DoDAF og MoDAF m.fl. 

Perspektivet til SOAML fokuserer på virksomhetens tjenesteyting og arkitektur, og begrepene 

er så langt som mulig i tråd med OASIS sin referansemodell [90]. Ved siden av definisjon av 

modelleringsspråk, inneholder standarden en beskrivelse av prinsipper for beste praksis, som 

skille mellom ulike aspekter, delegering, innkapsling, dynamisk samarbeid, skille spesifikasjon 

og realisering, håndtering av tilstander og sesjoner, samt ulike interaksjonsmønstre 

(tilsvarende de vi diskuterte i avsnitt 4.4). 

4.10.2.3 UMM 

UMM (UN/CEFACT Modeling Methodology) er et UML-basert modelleringsspråk for ebXML. 

Sammenlignet med basis UML og SOAML fokuserer de enda mer på virksomhetsnivået, og på 

virksomhetenes operasjonelle sider. Standarder rettet mot programvareutvikling fokuserer 

gjerne mer på virksomhetens strategi, ledelse og utvikling, og på hvilke krav dette stiller til 

IKT, heller enn de operasjonelle strukturene av økonomi, organisering, roller, ressurser, 

prosesser, lokasjoner, produkter o.l. UMM har noe, men begrenset, verktøystøtte. 

4.10.2.4 SOMA - Service-Oriented Modeling and Architecture 

SOMA er IBM’s UML-profil for modellering av tjenesteorientert arkitektur, implementert i 

Rational Software Architect. Den er utviklet over flere versjoner siden 2004. Modellen ser på 

tjenester som arenaen hvor forretning og IKT møtes, og modellerer forretningsprosesser med 

ytelsesparametere i tillegg til objektorientert analyse og design. 

20.01.2010 Versjon 1.1 63/89

DIFI 


4.10.2.5 SOMF - Service-Oriented Analysis, Design, and Architecture 

Bell [3] har utarbeidet en omfattende metodikk for modelldrevet utvikling av tjenester. I 

motsetning til mange andre er den ikke avledet fra UML, noe som gjør den mer målrettet og 

tjenesteorientert, med et effektiv og tilpasset modelleringsspråk. SOMF støtter hele 

livssyklusen til en tjeneste, og dekker både forretningsarkitekturen og overordnet IKTarkitektur, 

fra et funksjonelt perspektiv. 

4.10.3 Modellering av regler 

Regler kan brukes til å spesifisere vilkårene for en tjeneste, og til å bygge løsninger som 

knytter sammen ulike tjenester, f.eks. i en prosessorientert eller hendelsesdrevet arkitektur. 

XSLT kan ses på som et språk for transformasjonsregler for XML. 

4.10.3.1 Regelspråk fra OMG 

OCL er UML sin basisnotasjon for regler [124], selv om standarden også tillater at regler 

uttrykkes i naturlig språk eller programmeringsspråk. Regler i OCL er logiske uttrykk. Regler i 

OCL brukes ofte til å legge begrensninger (constraints) på sammenhenger mellom elementer 

eller elementers verdi. Derfor dreier mye av språket seg om å identifisere de elementene som 

regelen gjelder for, gjennom navigering, søk og forespørsler (queries). 

Siden UML tilbyr andre språk for å beskrive oppførsel, som tilstandsmaskiner, har OCL en ren 

deklarativ syntaks, uten å spesifisere operasjonelt hva som skal skje hvis regelen er oppfylt 

eller i hvilke sammenhenger regelen skal testes. For operasjonelle spesifikasjoner dekker OCL 

bare betingelsene som skal testes. Action semantics i UML knytter betingelsene til handlinger, 

mens Product Rule Representation definerer inferensregler, begge i formen if-then. 

SVBR (Semantics of Business Vocabulary and Business Rules) er et mer høynivå regelspråk, 

som bruker strukturert naturlig språk til å uttrykke forretningsregler. SVBR brukes gjerne til å 

presisere en begrepsmodell (ontologi) med begrensninger og avledninger. Reglene kan ha en 

av fire modale operatorer, for å uttrykke om utsagnet er mulig eller nødvendig, tillatt eller 

obligatorisk. Språket er avstemt med ISO/IEC 24707 for felles logikk. 

4.10.3.2 RuleML 

RuleML [137] er et felles språk for inferensregler, reaksjonsregler og transformasjonsregler. 

Syntaksen er XML, og ved siden av basisversjonen finnes det varianter spesielt tilpasset RDF 

for semantisk web og MOF for objektorientert modellering. På semantisk nivå er RuleML 

knyttet opp til matematiske regler i MathML, agenter i DAML, data mining i PMML og 

datatransformasjon med XSLT. Reaksjonsreglene legger til hendelsen som trigger regelen, slik 

at vi får ”when Event if Condition then Action” (ECA), ikke bare if-then. 

4.10.3.3 SWRL – Semantic Web Rule Language 

SWRL [166] er et forslag til W3C som knytter RuleML til OWL (Web Ontology Language). I 

likhet med mange andre standarder for semantikk er den drevet fram av akademia, men liten 

industriell deltagelse. 

4.10.3.4 RIF – Rule Interchange Format 

RIF [157] er et standard utvekslingsformat for regler fra W3C. RIF er utvidbart, og definerer 

dialekter for ulike typer regler, som produksjonsregler med aksjoner og rene logiske utsagn. 

Standarden er ganske ny, så verktøy er i ferd med å bli utviklet. 

4.10.4 Virksomhetsarkitektur for forvaltning av tjenester 

Virksomhetsarkitektur er et område som i stor grad er drevet fram av offentlig sektor, spesielt 

i USA etter Clinger-Cohen Act fra 1996. Ved siden av å etablere et rammeverk for utvikling og 

forvaltning av tjenesteorientert arkitektur, vil en slik tilnærming være nyttig for å identifisere 

fellestjenester, og behov for tilpasning av disse til ulike virksomheter. 

Virksomhetsarkitekturens viktigste mål er å sikre at helheten ivaretas i valg av løsninger, og at 

arkitekturen tillater utvikling i tråd med endrede forutsetninger og nye muligheter. Dette er å 

anse som broen mellom virksomhetens tjenesteyting og informasjonsteknologi. 

20.01.2010 Versjon 1.1 64/89

DIFI 


Virksomhetsarkitektur er et verktøy for å utarbeide forretningsstrategien i form av 

teknologiske målsetninger, og fokuserer på optimalisering på tvers av forretningsprosesser og 

informasjonssystemer. Planer for realisering vil være et hjelpemiddel for strategiske og 

taktiske beslutninger og tiltak, og gi sporbarhet tilbake til forretningsmessige behov. 

Virksomhetsarkitekturen gir: 

Figur 12. Bruk av virksomhetsarkitektur. 

En helhetlig plan for videreutvikling av informasjonsteknologi i virksomheten 

Styringsmekanismer som effektivt understøtter realisering av planen 

Sporbarhet i teknologiske investeringer og beslutninger tilbake til forretningsmessige 

behov 

4.10.4.1 Rammeverk, metoder og språk 

Gjennom de siste 15 årene er det utviklet en lang rekke rammeverk, metoder og språk for 

virksomhetsmodellering. Rammeverk gir en overordnet struktur på innholdet i en arkitektur, 

gjerne som en samling diagrammer eller utsnitt av den underliggende arkitekturmodellen. 

Noen rammeverk definerer også sine egne metoder for utvikling av arkitekturen, mens andre 

baserer seg på standard metoder som TOGAF ADM (Architecture Development Methodology). 

Noen rammeverk definerer også egne modelleringsspråk, mens andre gjenbruker standard 

språk, og setter dem inn i sin egen sammenheng. 

4.10.4.2 Zachman 

Zachmans rammeverk var et av de tidligste verktøyuavhengige rammeverkene, og det har 

hatt stor innflytelse på mange etterfølgere. Det deler arkitekturen inn i 6 lag for ulike roller: 

Avgrensning – for strategisk ledelse, identifikasjon av elementer 

Forretning – for ledere, definisjon av elementer 

System – for arkitekter, representasjon av elementer 

Teknologi - ingeniører, spesifikasjon av elementer 

Komponent – for teknikere, konfigurasjon av elementer 

Operasjon – for driftsorganisasjonen, instansiering av elementer 

Hvert lag deles inn i 6 ulike aspekter, slik at rammeverket får 6x6 celler: 

Hva – produkter og informasjon som lagres 

Hvordan – prosesser og transformasjon 

Hvor – nettverk av lokasjoner 

Hvem – organisasjon og roller 

Når – tid og livssykler 

Hvorfor – visjon, mål og motivasjon 

20.01.2010 Versjon 1.1 65/89

DIFI 


Dette rammeverket brukes gjerne som utgangspunkt, men det er viktig at man avklarer hvilke 

av de 36 ulike diagrammene man har nytte av å definere, heller enn å forsøke å dekke alle 

aspekter på alle nivåer. 

4.10.4.3 TOGAF 

The Open Group Architecture Framework (TOGAF) [132] er den eneste generelle 

internasjonale standarden for virksomhetsarkitektur, og et naturlig utgangspunkt hvis man 

skal komme med anbefalinger og retningslinjer på dette området. Denne standarden består av 

Et innholdsrammeverk, 

En metodikk for utvikling av arkitektur, 

Retningslinjer og teknikker for de ulike fasene i metodikken, 

Referansemodeller for typiske tekniske arkitekturer, 

Beskrivelse av sammenhengen mellom ulike typer arkitekturer, f.eks. hvordan 

referansearkitekturer kan gjenbrukes i lokale virksomhetsarkitekturer, og bruk av 

verktøy for å realisere dette, 

Rammeverk for å vurdere og utvikle kompetanse og modenhet i virksomheten. 

Kjernen i innholdsrammeverket fokuserer på virksomhetstjenester (business service) som 

bindeledd mellom organisasjon og IKT [132]: 

4.10.4.4 FEAF 

Figur 13. Hovedbegreper i TOGAF [132]. 

FEAF (Federal Enteprise Architecture Framework) [12] er det generelle rammeverket for 

virksomhetsarkitektur på statlig nivå i USA. Der defineres arkitektur på fire nivåer: forretning, 

data, applikasjon og teknologi. Ulike etater kan definere en segmentarkitektur for sitt område, 

basert på fem felles referansemodeller, som definerer standard elementer av disse typene: 

Performance Reference Model (PRM) for eGovernment: Områder, kategorier og grupper 

av indikatorer 

Business Reference Model (BRM): Forretningsområder, linjer og funksjoner 

20.01.2010 Versjon 1.1 66/89

DIFI 


Service Component Reference Model (SRM): Domener og typer av tjenester, med 

komponenter 

Data Reference Model (DRM): Dataenes beskrivelse, sammenheng og delingsmetoder 

Technical Reference Model (TRM): Tjenesteområde, -kategori og -standard 

Standarder som DoDAF, TEAF (Treasury) og NIH (National Institute of Health) Enterprise 

Architecture Framework er eksempler på segmentspesifikke arkitekturrammeverk fra offentlig 

sektor i USA. DoDAF har ledet videre til Nato Architecture Framework, som også det norske 

forsvaret forholder seg til. 

FEAF inneholder også et eget sett med retningslinjer for tjenesteorientert arkitektur [13], med 

visjoner og målbilde, nøkkelprinsipper for implementasjon, og veikart for innføring. Interessant 

nok ser de på hendelsesdrevet arkitektur som en essensiell del av en tjenesteorientert 

arkitektur. For en arkitekturorientert tilnærming til tjenesteorientering virker disse 

retningslinjene gode. Bruken av felles referansemodeller, og definisjonen av hele den føderale 

offentlige sektoren som en (1) virksomhet med en felles arkitektur, delt opp i segmenter, går 

svært langt i å ta et helhetlig perspektiv. 

4.10.4.5 OIO 

I Danmark har man valgt en annen tilnærming enn i USA. Heller enn obligatoriske standarder 

for rapportering, har man under paraplyen OIO (Offentlig Informasjon Online) kommet med 

retningslinjer for virksomhetsarkitektur og tjeneste-orientering. Tanken er at godt faglig 

fundamenterte rammeverk blir brukt når de gjøres tilgjengelig, selv om det ikke er påbudt. 

Dette har gitt en lavere terskel for å definere mønstre og profiler som offentlig sektor rådes til 

å ta i bruk. Det er da også lagt vekt på å skape et åpent felleskap hvor folk kan delta i 

diskusjoner og dele sine erfaringer, i tilknytning til arkitektur og standarder (digitaliser.dk). 

For virksomhetsarkitektur definerer OIO 

Et rammeverk (reol) inspirert av Zachman, men forenklet til 4 lag, konseptuelt, logisk, 

fysisk og styring, og 5 aspekter, strategi, forretning, informasjon, applikasjon og 

teknologi. Til hver celle hører en spesifikasjon av typiske arkitekturmodeller og 

dokumenter. 

En metode for utvikling av arkitekturer, med detaljerte anbefalinger for hvert steg, 

inkludert hvilke aktører som bør delta, 

Sammenhenger med andre arkitekturrammeverk, 

Anvendelse av metoder og modelleringsspråk, 

Klassifikasjonsstruktur for dokumenter og andre deler av arkitekturbeskrivelsen, 

Felles prinsipper for, og krav til, arkitektur og arkitekturbeskrivelser. 

4.10.4.6 Archimate 

Archimate [128] er et rammeverk og språk for virksomhetsarkitektur utviklet i Nederland, som 

støttes av mange verktøy. Språket er nå akseptert som standard av Open Group, og neste 

versjon vil bli integrert bedre med TOGAF. Språket dekker tre aspekter: Informasjon eller 

passiv struktur, oppførsel og aktiv struktur, over 3 lag: Forretning, applikasjon og teknologi. 

Basisbegrepene er tjeneste, objekt, oppførselselement, strukturelement og grensesnitt. I 

motsetning til UML og andre standard språk er utgangspunktet for denne standarden 

virksomhetsnivået, noe som gjør resultatet enklere og mer brukervennlig for mange grupper. 

For å gjøre presentasjonen av arkitekturen mer målrettet, definerer Archimate ulike perspektiv 

(viewpoints) for arkitekter, beslutningstakere og publikum, på tre nivåer: Oversikt, 

avstemming og detaljer. 

4.10.4.7 ISO-standarder for virksomhetsmodellering 

ISO har definert en flere standarder på dette området, ofte knyttet produksjonsindustri [23]: 

ISO Reference Model for Open Distributed Processing, ISO 10746, 1996. 

20.01.2010 Versjon 1.1 67/89

DIFI 


Concepts and Rules for Enterprise Models, ISO 14258, 1998. 

Requirements for Enterprise Reference Architecture and Methodologies, ISO 15704, 

2000. 

Enterprise Integration - Framework for Enterprise Modelling, ISO 19439, 2006. 

Enterprise Integration - Constructs for Enterprise Modelling, ISO 19440, 2006. 

Recommended Practice for Architectural Description of Software-intensive Systems, 

ISO/IEC 42010, 2007. 

Disse brukes mest som referansemodeller og begrepsrammeverk. 

4.10.4.8 Rammeverk fra industrien 

Selv om det finnes flere standarder for virksomhetsarkitektur som er støttet av tilgjengelige 

verktøy, har mange leverandører og konsulentfirmaer utviklet sine egne rammeverk. Mest 

kjent er kanskje ARIS sitt kvalitetshus. Noen rammeverk er uavhengige og åpent tilgjengelig, 

som Pragmatic EA Framework (PeaF) og Institute For Enteprise Architecture Development 

(IFEAD) sitt Extended EA (E 2 A). 

20.01.2010 Versjon 1.1 68/89

DIFI 


5 Råd for videre arbeid 

Referansekatalogen for IKT-standarder i offentlig sektor [32] angir obligatoriske standarder, 

og anbefalte standarder, noen ganger med flere alternative å velge mellom. Dette kapittelet 

foretar en første grovsortering av standarder for tjenesteorientert arkitektur med tanke på 

inkludering i fremtidige versjoner av referansekatalogen. Difi og Standardiseringsrådet vil 

foreta mer grundige evalueringer av de mest aktuelle standardene. 

Vi begrenser oss her til å snakke om standarder for tjenesteorientert arkitektur, selv om flere 

av standardene bør vurderes også opp mot andre områder. 

5.1 Basis standarder som trolig bør anbefales 

De grunnleggende standardene fra WS-I Basic profile [209] har i flere år vært etablert som 

basis for tjenesteorientert arkitektur, og er dermed første gruppe av kandidater til 

referansekatalogen. Disse standardene bør anbefales samlet som en ”pakke” eller ”profil”. 

Standard Område Organ Vurdering 

WSDL 1.1 Tjenester W3C Lav formell status (notat), men allestedsnærværende. 

Man bør vurdere å gjøre WSDL 2.0 

til et likestilt alternativ til 1.1. Anvendelsesområder 

for alternativet ebXML bør avgrenses. 

Man bør også gi anbefalinger for hvordan WSDL 

bør brukes (f.eks. i tråd med WS-I Basic Profile), 

men heller som en egen profil enn som del av 

referansekatalogen. 

XML 1.0 Data W3C Allerede indirekte inkludert i standardkatalogen 

som basis for XHTML, SVG m.m.. Bruksområdet 

bør kanskje avgrenses. 

XML 

Namespaces 

1.0 

XML Schema 

1.0 

SOAP Kommunikasjon 

SOAP With 

Attachments 

Data W3C For modularisering av datadefinisjoner. Profiler 

bør klargjøre bruken av navnerom, og hvordan 

ulikheter mellom verktøy blir håndtert. 

Data W3C Brukes av WSDL 1.1 til å definere datainnhold, og 

definerer dessuten grunnleggende datatyper for 

verdier. Versjon 1.1 bør følges videre, og på sikt 

kanskje anbefales som alternativ. I WSDL tillates 

ikke alternativet DTD. 

Kommunikasjon 

W3C Valg av versjon 1.1 og/eller 1.2 bør utredes. 

Trolig bør begge anbefales. Bør avgrenses mot 

EDI. 

W3C For overføring av andre format enn XML, inkludert 

binær optimalisering av XML. Anbefales av WS-I 

og for ebXML, og er basis for andre standarder 

som MTOM. Basert på MIME. 

WS-Adressing Tjenester W3C Fleksibel adressering og beskrivelse av 

webtjenester, med bindinger til SOAP. Basis for 

flere andre standarder som Policy, Security og 

MetadataExchange. Det bør vurderes om denne 

skal gjøres obligatorisk for alle webtjenester, eller 

bare anbefales. 

Som dokumentert av OIO [61] er det likevel ikke slik at bruken av disse standardene 

garanterer interoperabilitet. Ulike verktøy implementerer ulike deler av standarden, og 

20.01.2010 Versjon 1.1 69/89

DIFI 


introduserer slik nye barrierer. En ytterligere presisering av hvilke krav som stilles er dermed 

ønskelig. 

Standardene for WS-I Basic Security Profile [211] har også flere års historie som stabile 

standarder med stor utbredelse. Forslagene under skal sammenfalle med teknologivalg gjort 

for ID-porten (jf. avsnitt 4.8.1). 


WS-Security 

1.1 

WS-Security 

1.1 Username 

token profile 

WS-Security 

1.1 X.509 

token profile 

Sikkerhet OASIS Grunnleggende for sikkerhet i tjenesteorientert 

arkitektur. Vurder først og fremst avgrensning av 

anvendelsesområder, og hvor standardene bør 

være obligatoriske i forhold til sikkerhetsnivåer. 

Sikkerhet OASIS Grunnleggende innlogging for lavere 

sikkerhetsnivå. 

Sertifikater OASIS Kobling til X.509-sertifikater, som brukes i Idporten. 

SAML 2.0 Autentisering OASIS Brukes i ID-porten. Bør vurderes opp mot 

alternativer som WS-Federation, men utgjør et av 

alternativene som bør anbefales. 

WS-Security 

1.1 SAML 

token profile 

WS-Security 

Policy 1.3 

Autentisering OASIS Bør standardiseres sammen med SAML. 

Sikkerhet 

spesifikasjon 

WS-Policy 1.5 Spesifikasjon 

og metadata 

XML 

Encryption 

XML 

Signatures 

Sikkerhet, 

kryptering 

Sikkerhet 

signering 

OASIS Brukes av WS-Security 

W3C Basis for SecurityPolicy, men bruken på andre 

områder bør avgrenses opp mot bl.a. WS- 

MetadataEchange. 

W3C Grunnleggende, vil sannsynligvis bli brukt i IDporten. 

W3C Grunnleggende, vil sannsynligvis bli brukt i IDporten. 

Profilen XAdES fra ETSI kan presisere 

bruken. 

20.01.2010 Versjon 1.1 70/89

DIFI 


5.2 Andre standarder som kan anbefales 

I tillegg til de grunnleggende standardene for tjenesteorientert arkitektur og sikkerhet over, 

finnes det en lang rekke standarder som er modne for anbefaling innenfor sine 

anvendelsesområder. 


XSLT Data - 

transformering 

W3C Svært utbredt standard for transformasjon av 

XML. 

XPath Data - søking W3C Svært utbredt. Brukes av XSLT og andre 

standarder. 

XQuery Data - søking W3C Bør vurderes nærmere, særlig verktøystøtten. 

XForms Brukergrensesnitt 

DOM Brukergrensesnitt 

og data 

Ecmascript Brukergrensesnitt 

W3C Kan anbefales, men neppe gjøres obligatorisk i 

et område med mange proprietære løsninger 

som stadig utvikles, og tilbyr rikere 

funksjonalitet. 

W3C Bør trolig anbefales, men hvilke nivåer og 

varianter må vurderes nærmere. 

ECMA Kan anbefales, men bør neppe gjøres 

obligatorisk så lenge store leverandører ikke 

følger standarden fullt ut. 

JSON Dataoverføring JSON.org Bør vurderes i tilknytning til ecmascript, DOM 

og andre standarder for AJAX, men man kan 

også standardisere på XML som 

overføringsformat mellom brukergrensesnitt og 

tjenestelag. 

UDDI Tjenestekatalog OASIS Stabil og vel etablert standard. Liten risiko ved 

å anbefale. Hvilke versjoner bør vurderes. 

MTOM og 

XOP 

WS- 

Transaction 

Kommunikasjon W3C Anbefalt av WS-I Basic Profile 1.2, utvidelse av 

SOAP with Attachments for effektiv overføring 

av binære data. 

Applikasjon OASIS Godt utbredte standarder for ulike 

transaksjonsløsninger. Bør trolig anbefales. 

WS-BPEL Prosess OASIS Kan anbefales, men neppe gjøres obligatorisk, 

da mer fleksible løsninger finnes basert på 

høyere nivås standarder som BPMN og XPDL. 

WS- 

Reliable 

Messaging 

XACML Sikkerhet - 

autorisasjon 

Pålitelighet OASIS Bruken av standarder for dette på meldingsnivå 

bør vurderes opp mot hva som tilbys på 

transportlaget. Brukes av PEPPOL [187]. 

XKMS Sikkerhet - 

administrasjon 

OASIS Knyttet til andre standarder som SAML, utbredt, 

men ikke allestedsnærværende. 

W3C Verktøystøtte bør vurderes, status i ID-porten 

er avgjørende. 

XMPP Kommunikasjon XMPP.org Bør vurderes nærmere for mobile og dynamiske 

nettverk. 

En rekke standarder for innhold og semantikk til data bør også vurderes på dette nivået, se 

avsnitt 4.2.9, 4.5.4 og 4.5.5. Dette studeres i andre prosjekt, og er ikke vurdert i detalj her. 

20.01.2010 Versjon 1.1 71/89

DIFI 


5.3 Standarder som kan vurderes seinere 

Standardene nedenfor har en viss utbredelse, men noen er foreløpig umodne, og de fleste har 

begrenset verktøystøtte. 


EXI Data - 

komprimering 

SPML 2.0 Identitetsforvaltning 

WS-Security 

1.1 Kerberos 

token profile 

WS-Secure 

Conversation 

W3C Kommende standard for komprimert overføring. 

Verktøystøtten må vurderes før anbefaling. 

OASIS Vurdering er avhengig av fremtidig bruk i IDporten, 

og utbredelsen av verktøy. 

Sertifikater OASIS Kobling til Kerberos og avhengig av dennes 

status i referansekatalogen/eId. 

Sikkerhet OASIS Verktøystøtten bør vurderes nærmere 

WS-Trust Sikkerhet OASIS Brukes av WS-SecureConversation. Verktøystøtten 

bør vurderes, aktuell for ID-porten. 

WS- 

Federation 

WS- 

Notification 

WS- 

BPEL4people 

WS-Remote 

portlets 

WS- 

Metadata 

Exchange 

Sikkerhet- 

autentisering 

Kommunikasjon 

- hendelser 

OASIS Nylig standardisert, bør overvåke 

verktøystøtten og vurderes opp mot SAML. 

OASIS WS-Eventing er en enklere konkurrent, men 

WS-Notification er etablerte standarder (Topics, 

BaseNoritification, BrokeredNotification). 

Verktøystøtten bør forbedres, men hendelsesdrevne 

arkitekturer blir viktig framover. 

Prosess OASIS Bør vurderes i neste runde hvis WS-BPEL blir 

anbefalt, avhengig av verktøystøtte. 


Spesifikasjon 

og metadata 

OASIS Bør vurderes opp mot mer utbredte løsninger 

som AJAX og Java JSR 168/286. Verktøystøtte 

er utbredt, men ikke overalt. 

W3C Bør vurderes når standarden er godkjent og 

verktøystøtten er utbredt. Bør avgrenses mot 

WS-Policy. 

WS-Transfer Kommunikasjon W3C For tilgang til data om ressurser iht. REST, 

brukes bl.a. av PEPPOL [187], men ennå ikke 

godkjent som standard. 

WS- 

Management 

WSDM 

Forvaltning OASIS Disse standardene og de tilhørende for 

ResourceFramework, ResourceTransfer. 

Fragment og Enumeration har ikke stabilisert 

seg. 

På lenger sikt bør flere standarder som er på vei for brukergrensesnitt basert på AJAX og/eller 

REST også vurderes, f.eks. W3C Webapps og HTML5 (se avsnitt 4.6.2 og 4.6.7). 

5.4 Områder for videre kartlegging 

Ved siden av de rent tekniske standardene som omfattes av referansekatalogen vil 

tjenesteorientering dra nytte av retningslinjer innenfor mer organisatoriske sider ved utvikling, 

yting og forvaltning av tjenester. 

20.01.2010 Versjon 1.1 72/89

DIFI 


5.4.1 Forvaltning og drift av tjenester 

ITIL [63, 126] er de facto standard for drift av IKT-tjenester, og en sannsynlig basis for avtaler 

det offentlig inngår på dette området. Retningslinjer for anskaffelse av slike tjenester, og 

kanskje en offentlig standardkontrakt for webtjenester, bør man vurdere å utvikle. Det vil også 

være behov for slike avtaler mellom enheter i offentlig sektor, knyttet til flerbruk og gjenbruk 

av tjenester og komponenter. 

5.4.2 Tjenester i skyen 

Software as a service (SaaS) er en modell som blir stadig vanligere, ikke bare for klienttjener-applikasjoner, 

men også for kontorstøtte og andre løsninger som hittil har vært 

installert på brukernes lokale maskiner. Standardisering og dominerende industrirammeverk 

for dette bør overvåkes. 

5.4.3 Pragmatisk semantikk 

Semantiske teknologier studeres på mange områder i offentlig sektor. Praktiske anvendelser 

som setter slik teknologi i drift er langt sjeldnere. De sofistikerte delene av teknologien, de 

som skiller den fra vanlig datamodellering, utnyttes i minimal grad i operative løsninger. 

Mange har oppdaget at formelle språk er til hinder for menneske-maskin- og 

mellommenneskelig kommunikasjon, og legger i større grad vekt på tilgjengelighet, enkelhet 

og visualisering. En forståelse av at en begrepsmodell bør være åpen blir mer og mer utbredt, 

selv om dette ikke i tråd med grunnsynet til de formelle regelspråk som benyttes. Semantisk 

teknologi kan være i ferd med å bli redusert til vanlig informasjonsmodellering. Da er det 

grunn til å spørre om ikke de løsningene industrien lenge har brukt på dette området holder 

mål, om semantisk teknologi tilfører merverdi. 

Gustafsson og Höglund [43] rapporterer fra 20 års erfaring med utvikling av felles 

begrepsmodeller på tvers av organisasjonsgrenser i industri og offentlig virksomhet, blant 

annet justissektoren. De konkluderer på flere områder stikk i strid med rådende praksis innen 

semantisk teknologi: 

Hierarkier som taksonomi, klassifisering, gruppering og komponering er som oftest 

lokale for et fagområde, og har ingen plass i en felles ontologi. 

Et element defineres primært gjennom sine relasjoner til andre elementer, ikke av sine 

egenskaper eller klassetilhørighet. 

Tilsvarende erfaringer er gjort av andre [65]. OASIS Business Centric Methodology (avsnitt 

4.7.7) bygger på lignende konklusjoner, og legger opp til klassifikasjon i mange ulike fasetter 

eller dimensjoner. Semantisk teknologi legger til tekniske lag i tillegg til det som er nødvendig 

for tjenesteorientert arkitektur, nemlig XML Schema, og skaper således økt kompleksitet. 

5.4.4 Virksomhetsarkitektur 

Det felles arkitekturarbeidet i offentlig sektor har kommet godt i gang, med veldefinerte 

prinsipper, analyser av felleskomponenter og valg av standarder. I det videre arbeidet bør 

virksomhetsarkitekturer knytte sammen høynivå prinsipper med konkrete komponenter og 

standarder. Dette betyr samtidig at man bør gå bort fra kun å inkludere allmenngyldige 

elementer som det er enighet om, til å komme med mer fleksible anbefalinger og forslag 

tilpasset ulike bruksområder. Figuren under viser ulike nivåer som referansearkitekturer kan 

utvikles for. SERES [5] foreslår en Norsk Offentlig Arkitektur etter lignende prinsipper. 

20.01.2010 Versjon 1.1 73/89

DIFI 


Figur 14. Ulike nivåer av virksomhetsarkitektur i offentlig sektor [37]. 

Som vi diskuterte kort i avsnitt 4.10.4, kan arkitekturmodellene inkludere: 

Rammeverk for interoperabilitet og tjenesteorientert arkitektur, som definerer typiske 

byggesteiner i en arkitektur, både på virksomhetsnivå og innen IKT. 

Profiler som bygges nedenfra, fra teknologien og oppover, og beskriver hvordan ulike 

teknologier kan kobles sammen for å løse typiske problemer, gjerne med ulike 

varianter. 

Mønstre, som beskriver typiske problemer med løsningsforslag, motsvarende profiler 

men ovenfra og ned, fra virksomhet og brukere mot teknologi. Mønstre vil noen ganger 

ikke definere hvilke komponenter som skal brukes, men heller beskrive samspillet 

mellom typiske komponenter i løsningen. Bruksscenarioene i denne rapporten er 

eksempler på områder man kan definere mønstre innen. 

Antimønstre, typiske løsninger som bør unngås, og deres konsekvenser. 

Prinsipper og retningslinjer for utforming av arkitekturen, f.eks. REST. 

Laplace [71] beskriver 13 anti-mønstre som preger feilslåtte implementeringer av 

tjenesteorientert arkitektur: 

Hvis vi bygger det så kommer de, hvor tjenester bygges uten etterspørsel. 

Sminke grisen, hvor man klistrer et grensesnitt for webtjenester rett på eksisterende 

applikasjoner, uten en tjenesteorientert rekonstruksjon. 

Høyre-klikk arkitektur, hvor man bruker programmeringsverktøy til automatisk 

generering av webtjenester fra eksisterende grensesnitt, uten å tenke på tjenestenes 

formål, kontrakter o.l. 

Søppel inn, søppel ut, hvor man eksponerer virksomhetens data uten å fikse 

underliggende problemer ved dataenes kvalitet og struktur. 

Hel enchilada, hvor forretningsprosessering og teknisk prosessering blandes sammen i 

en komponent, noe som gjør gjenbruk vanskelig. 

A for applikasjon, ikke arkitektur, hvor tjenester bygges for bruk innen en applikasjon, 

uten tanke på gjenbruk. 

S for silo, ikke service, hvor hver organisasjon lager sine tjenesteorienterte 

arkitekturer, uten noen felles styring eller arkitektur. 

Sikkerhet, hvilken sikkerhet, hvor man skreddersyr sikkerhetsløsningene til den enkelte 

komponent, heller enn å lage en helhetlig sikkerhetsarkitektur. Dette krever ofte 

rekonstruksjon som gir kostnadsoverskridelser mot slutten av prosjektet. 

20.01.2010 Versjon 1.1 74/89

DIFI 


BPEL = SOA, hvor man fokuserer på standarder heller enn forretningsnytte, på 

prosesser heller enn hele arkitekturen. 

Bare støttesystemer, hvor tjenester kun brukes til bakenforliggende implementasjon, 

og presentasjon og interaksjon med brukerne blir tatt for lett på. 

Masser av data, hvor man bygger tjenester for tilgang til registerdata nedenfra opp 

uten en forretningsanalyse. 

Babels tårn, hvor det ikke finnes noen felles referansemodell for dataene. 

Flunkende nytt leketøy, hvor man bygger tjenester for teknologiens skyld, som et 

teknisk eksperiment for å følge med i tiden. 

Alle disse anti-mønstrene har manglende virksomhetsarkitektur som en av flere årsaker. 

Overordnede prinsipper er neppe tilstrekkelig for å løse disse utfordringene. 

5.4.5 Modelldrevne applikasjoner 

Modelldrevne applikasjoner bruker modellering heller enn programmering til å definere 

applikasjonslogikk, prosesser og brukergrensesnitt. Enkle løsninger som BPM baserer seg på 

fullstendig automatisert tolkning av modellene, men mer fleksible løsninger med økt grad av 

brukerstyring er under utvikling av Microsofts Oslo-prosjekt og i ulike grupper tilknyttet OMG 

[17] (jf. avsnitt 4.10). Dette er et logisk neste steg som kombinerer tjenesteorientert IKTarkitektur 

med brukerrettet tjenesteorientering. OASIS BCM/CAM (avsnitt 4.7.7) er en lovende 

standard på dette området, men den er foreløpig umoden. Rammeverk for Widgets fra W3C 

Webapps (avsnitt 4.6.7) kan utgjøre en basis for modelldrevne brukergrensesnitt og 

spennende ”mashups”. 

20.01.2010 Versjon 1.1 75/89

DIFI 


Vedlegg A. Referanser 

1. Active Endpoints, Adobe, BEA, IBM, and SAP AG: WS-BPEL Extension for People 

(BPEL4People), versjon 1.0, 2007. 

2. Active Endpoints, Adobe, BEA, IBM, and SAP AG: Web Services Human Task (WS- 

HumanTask), versjon 1.0, 2007. 

3. Bell: Service-Oriented Modeling – Service analysis, Design, and Architecture, Wiley 

2008. 

4. Brønnøysundregistrene: Semantikkregisteret for elektronisk samhandling (SERES), 

2009. http://www.brreg.no/samordning/semantikk/ 

5. Brønnøysundregistrene: Konseptskisse for SERES, v.1.0, 2008. 

6. Butler Group: SOA Platforms – Software Infrastructure Requirements for Successful 

SOA Deployments, 2007. 

7. Butler Group: Planning and Implementing SOA – Ensuring the Successful Deployment 

of a Service-Based Approach, 2006. 

8. Butler Group: SOA Governance – Applying Governance to Ensure the Long Term 

Benefits of SOA. 

9. Butler Group: Integration Technologies – Reducing Costs through an Agile Approach to 

Integration. 

10. Chappell: Enterprise Service Bus, O’Reilly 2004. 

11. Chappel: The Case Against BPEL: Why the Language is Less Important Than You Think, 

2005, http://www.davidchappell.com/HTML_email/Opinari_No14_10_05.html. 

12. CIO Council: A Practical Guide to Federal Enterprise Architecture, v. 1.0, 2001. 

13. CIO Council: A Practical Guide to Federal Service Oriented Architecture, v. 1.1, 2008. 

14. Commitment: Oversikt over begrepsbruk innen tjenesteorientert arkitektur, Notat til 

Difi, 2009. 

15. Commitment: Oversikt over referansemodeller for tjenesteorientert arkitektur, Notat til 

Difi, 2009. 

16. Cospaces: Open Collaboration Reference Architecture, Integrated Project, EU 2009. 

17. DeMan: Response from Cordys to the OMG Dynamic Business Activity Modeling RFI, 

Cordys 2009. 

18. Direktoratet for forvaltning og IKT (Difi): Overordnede IKT-arkitekturprinsipper for 

offentlig sektor, versjon 1, 2009. 

19. Direktoratet for forvaltning og IKT (Difi): Overordnede IKT-arkitekturprinsipper for 

offentlig sektor, versjon 2, 2009. 

20. Direktoratet for forvaltning og IKT (Difi): Statens standardavtaler, 

http://www.difi.no/hovedEnkel.aspx?m=51881&amid=1790806 

21. Direktoratet for forvaltning og IKT (Difi): Los - Ein informasjonsstruktur for offentlege 

tenester, http://los.difi.no 

22. Distributed Management Task Force (DMTF): Web Services for Management, standard, 

2008. 

23. EA Standards, http://www.enterprise-architecture.info/EA_Standards.htm 

24. ECMA: ECMAScript Language Specification, Release 5, 2009. 

25. ETSI: XAdES version 1.4.1, ETSI TS 101 903, standard, 2009. 

26. EU Commission: European interoperability framework for pan-European eGovernment 

services, EU Commission 2004. 

20.01.2010 Versjon 1.1 76/89

DIFI 


27. EU Commission: Functional, technical, legal and organisational specifications for the 

development of building blocks software enabling crossborder use of eCatalogues, 

PEPPOL, EU 2009. 

28. EU Commission: PEPPOL Infrastructure 1.0 Specifications, 2009. 

29. EU Commission: Enterprise Interoperability Research Roadmap, (DG INFSO D5) 2008. 

30. Fielding, Taylor: Principled Design of the Modern Web Architecture, ACM Transactions 

on Internet Technology 2 (2), 2002. 

31. Fornyings- og administrasjonsdepartementet (FAD): Ei forvaltning for demokrati og 

fellesskap, St.meld. nr. 19 (2008-2009) 

32. Fornyings- og administrasjonsdepartementet (FAD): Referansekatalog for IT-standarder 

i offentlig sektor - Versjon 2.0, 2009. 

33. Fornyings- og administrasjonsdepartementet (FAD): Strategi for eID og e-signatur i 

offentlig sektor, 2007. 

34. Fornyings- og administrasjonsdepartementet (FAD): Rammeverk for autentisering og 

uavviselighet i elektronisk kommunikasjon med og i offentlig sektor, 2008. 

35. Fornyings- og administrasjonsdepartementet (FAD): Eit informasjonssamfunn for alle, 

St.meld. nr. 17 (2006-2007). 

36. Fornyings- og administrasjonsdepartementet (FAD): Nasjonale retningslinjer for å 

styrke informasjonssikkerheten 2007-2010, 2007. 

37. Fornyings- og administrasjonsdepartementet (FAD): Felles IKT-arkitektur i offentlig 

sektor, FAOS-rapporten, 2007. 

38. Fornyings- og administrasjonsdepartementet (FAD): Bedre samordning og styring av 

store og/eller strategisk viktige IKT-prosjekter i staten, 2008. 

39. Gamma, Helm, Johnson, Vlissides: Design Patterns, Addison-Wesley 1994. 

40. Gartner Group: Preparation for Update European Interoperability Framework 2.0 – Final 

Report, 2007. 

41. Gartner Group: Introduction to Service-Oriented Architecture, 2003. 

42. GS1 Norge: UNSPSC, http://www.gs1.no/unspsc/ 

43. Gustafsson, Höglund: The Common Model of an Enterprise’s Value Objects, Presented 

in Relevant Business Views, Springer, Conference on Practice of Enterprise Modeling, 

Springer, 2009. 

44. Helse- og omsorgsdepartementet: Samspill 2.0 - Nasjonal strategi for elektronisk 

samhandling i helse- og omsorgssektoren 2008 – 2013, 2008. 

45. Heravi, Razzazi: Utilizing WS-BPEL Processes through ebXML BPSS, International 

Conference on Internet Technology and Secured Transactions, London 2007. 

46. Hohpe, Woolf: Enterprise Integration Patterns, Addison-Wesley 2005. 

47. IBM: WSDM/WS-Man Reconciliation - An Overview and Migration Guide, 2006. 

48. IDEF: Integrated Definition Methods, http://www.idef.com/ 

49. IFEAD - Institute for Enterprise Architecture Developments, www.enterprisearchitecture.info 

50. IMS Global: Adoption of Service Oriented Architecture (SOA) for Enterprise Systems in 

Education: Recommended Practices, 2009, 

http://www.imsglobal.org/SOA/imsSOAWhitePaper_v1p0pd.html 

51. Intalio: Best Practices for Process and Message Versioning, 2007. 

52. ISO/IEC/ITU: Reference Model of Open Distributed Processing (RM-ODP), ITU-T Rec. 

X.901-X.904, ISO/IEC 10746, 1996-1998. 

20.01.2010 Versjon 1.1 77/89

DIFI 


53. ISO: Enterprise Integration - Framework for Enterprise Modelling, ISO TC 

184/SC5/WG1 - CEN TC 310/WG1, ISO/IEC 19439, 2006. 

54. ISO: Enterprise Integration - Constructs for Enterprise Modelling, ISO TC 

184/SC5/WG1 - CEN TC 310/WG1, ISO/IEC 19440, 2006. 

55. ISO/IEC/ITU: Information technology — Generic applications of ASN.1: Fast Infoset, 

ISO/IEC 24824-1, 2007. 

56. ISO: ISO 27000 Information Security Standards, http://www.27000.org. 

57. IT og Telestyrelsen: Roadmap for serviceorienteret infrastruktur 2.0, digitalisering.dk, 

2009. 

58. IT og Telestyrelsen: Valg af webservice-standard i det offentlige – Implementeringsmodell 

for forretningsservices, digitalisering.dk, 2008. 

59. IT og Telestyrelsen: Serviceorienteret arkitektur – hva og hvorfor, digitalisering.dk, 

2006. 

60. IT og Telestyrelsen: Standardkontrakt for webservices, digitalisering.dk, 2008. 

61. IT og Telestyrelsen: OIOWSDL – Vejledning for udvikling og anvendelse, 

digitalisering.dk, 2008. 

62. IT Service Management Forum: An Introductory Overview of ITIL v. 3, 2007. 

63. ITSMF Norge: ITIL Terminologiliste – Norsk oversettelse, 2009. 

64. JSON-RPC Specification v. 1.2, http://groups.google.com/group/json-rpc?pli=1 

65. Jørgensen: Enterprise Modeling – What We Have Learned, and What We Have Not, 

Keynote, Conference on Practice of Enterprise Modeling, Springer, 2009 

66. Kommunenes sentralforbund (KS): eKommune 2012 – lokal digital agenda, 2008. 

67. Krafzig, Banke, Slama: Enterprise SOA. Prentice Hall 2005. 

68. Kompetansesenteret for IT i helse- og sosialsektoren (KITH): Rammeverk for 

elektronisk meldingsutveksling i helsevesenet - Basert på ebXML, 2006. 

69. Kompetansesenteret for IT i helse- og sosialsektoren (KITH): Elektronisk samhandling i 

helse- og omsorgssektoren - Aktører og samhandlingskjeder – status og utfordringer, 

2009. 

70. Kompetansesenteret for IT i helse- og sosialsektoren (KITH): Profil for web services i 

helse- og sosialsektoren, Versjon 1.2, 2009. 

71. Laplace: SOA Anti-Patterns, BEA, Arch2Arch Summit, 2007. 

72. Liberty Alliance: eGovernment Special Interest Group, 

http://www.projectliberty.org/liberty/strategic_initiatives/egovernment/ 

73. Norstella: Forslag til Norsk Referansekatalog for bruk av åpne standarder i offentlig 

sektor, 2006. 

74. Nærings- og handelsdepartementet (NHD): Tid til nyskaping og produksjon - En 

handlingsplan for å redusere bedriftenes administrative kostnader, 2008. 

75. Nærings- og handelsdepartementet (NHD): ELMER 2 – Retningslinjer for 

brukergrensesnitt i offentlige skjemaer på Internett, 2006. 

76. Masud: Use RosettaNet-based Web services, IBM developerworks, 2003. 

77. Moderniseringsdepartementet (MOD): Strategi for webbasert tjenesteyting i offentlig 

sektor, 2005. 

78. Moderniseringsdepartementet (MOD): eNorge 2009 – det digitale spranget, 2005 

79. Moderniseringsdepartementet (MOD): Bruk av åpne IT-standarder og åpen kildekode i 

offentlig sektor, 2005. 

20.01.2010 Versjon 1.1 78/89

DIFI 


80. Moderniseringsdepartementet (MOD): Arkitektur for elektronisk samhandling i offentlig 

sektor, Forprosjektrapport, 2004. 

81. Microsoft, IBM: Web Services Inspection Language, 2001, revised 2007. 

82. HP, IBM, Intel, Microsoft: Toward Converging Web Service Standards for Resources, 

Events, and Management, joint whitepaper, 2006. 

83. NESUBL: Northern European Subset of UBL, http://www.nesubl.eu/ 

84. OAG: Open Applications Group Integration Specification, versjon 9.4.1, 2001. 

85. OASIS & The Open Group: Navigating the SOA Open Standards Landscape around 

Architecture, 2009. 

86. OASIS: Business Centric Methodology (BCM), standard v. 1.0, 2006. 

87. OASIS: Content Assembly Mechanism (CAM), standard v.1.1, 2007. 

88. OASIS: eXtensible Access Control Markup Language (XACML), standard v. 2.0, 2005. 

89. OASIS: Security Assertion Markup Language (SAML), standard v. 2.0, 2005. 

90. OASIS: OASIS Reference Model for SOA, Version 1.0, 2006. 

91. OASIS: OASIS Reference Architecture for SOA Foundation, Version 1.0, 2008. 

92. OASIS: OASIS Service Provisioning Markup Language (SPML) Version 2, standard, 

2006. 

93. OASIS: UDDI Version 2.0 Specifications, 2001-2002. 

94. OASIS: UDDI Version 3.0 Specification, 2004. 

95. OASIS: UDDI as the registry for ebXML Components, Technical Note, 2004. 

96. OASIS: Universal Business Language v2.0, standard, 2006. 

97. OASIS: Web Services Business Process Execution Language Version 2.0, standard, 

2007. 

98. OASIS: Web Services Context Specification (WS-Context) Version 1.0, standard, 2007. 

99. OASIS: Web Services Coordination Framework Specification (WS-CF), utkast, 2005. 

100. OASIS: Web Services Atomic Transaction (WS- AtomicTransaction), standard versjon 

1.2, 2009. 

101. OASIS: Web Services Business Activity (WS- BusinessActivity), standard versjon 1.2, 

2009. 

102. OASIS: Web Services Coordination (WS-Coordination), standard versjon 1.2, 2009. 

103. OASIS: Web Services Dynamic Discovery, standard versjon 1.1, 2009. 

104. OASIS: Web Services Distributed Management, standard versjon 1.1, 2006. 

105. OASIS: WS-BaseNotification, standard v.1.3, 2006. 

106. OASIS: WS-BrokeredNotification, standard v.1.3, 2006. 

107. OASIS: WS-Topics, standard v.1.3, 2006. 

108. OASIS: Web Services Resource Framework 1.2, standard, 2006. 

109. OASIS: Web Services Reliable Messaging 1.1, standard, 2004. 

110. OASIS: Web Services Remote Portlets 2.0, standard, 2008. 

111. OASIS: WS-SecurityPolicy 1.3, standard 2009. 

112. OASIS: WS-SecureConversation 1.4, standard 2009. 

113. OASIS: WS-Trust 1.4, standard 2009. 

20.01.2010 Versjon 1.1 79/89

DIFI 


114. OASIS: Web Services Federation Language (WS-Federation) Version 1.2, standard, 

2009. 

115. OASIS: Web Services Security: SOAP Message Security 1.1, standard, 2006. 

116. OASIS: Web Services Security: Username Token Profile 1.1, standard, 2006. 

117. OASIS: Web Services Security: X.509 Token Profile 1.1, standard, 2006. 

118. OASIS: Web Services Security: SAML Token profile 1.1, standard, 2006. 

119. OASIS: Web Services Security: Kerberos Token Profile 1.1, standard, 2006. 

120. OASIS: Web Services Security: Rights Expression Language (REL) Token Profile 1.1, 

standard, 2006. 

121. OASIS: Web Services Security: SOAP with Attachments (SWA) Profile 1.1, standard, 

2006. 

122. Object Management Group (OMG): Business Process Model and Notation (BPMN) 

Specification 2.0, 2009. 

123. Object Management Group (OMG): Business Process Definition MetaModel (BPDM), 

Version 1.0, 2008. 

124. Object Management Group (OMG): UML 2.2 Superstructure Specification, 2009. 

125. Object Management Group (OMG): SoaML UML Profile, 2009. 

126. Office of Government Commerce: Best practice for Service Delivery – ITIL, 2001. 

127. Office of Government Commerce: Glossary of Terms and Definitions, 2008. 

128. Open Group: Archimate 1.0, http://www.archimate.org/ 

129. Open Group: The Open Group SOA Reference Architecture, 2009. 

130. Open Group: The Open Group SOA Ontology, 2009. 

131. Open Group: The Open Group Service Integration Maturity Model (OSIMM), 2009. 

132. Open Group: The Open Group Architecture Framework (TOGAF), v. 9, 2009. 

133. OpenId, http://openid.net/ 

134. Provost: On The Cusp: A Global Review of the Semantic Web Industry, 2008. 

135. Riksrevisjonen: Riksrevisjonens undersøkelse av elektronisk informasjonsutveksling og 

tjenesteutvikling i offentlig sektor, Dokument nr. 3:12 (2007–2008). 

136. RosettaNet, http://www.rosettanet.org. 

137. RuleML, http://ruleml.org/ 

138. SOAPjr, http://www.soapjr.org/ 

139. Swenson: WYDIWYE: The Answer to BPEL Transform Problems, 2008, 

http://kswenson.wordpress.com/2008/04/03/wydiwye-the-answer-to-bpel-transformproblems/ 

140. Trenaman: WSDL Versioning Best Practices, IONA Technologies, 2007. 

141. UN/CEFACT: ebXML, http://www.ebxml.org/ 

142. UN/CEFACT: Core Components Technical Specification, versjon 2.01, 2003. 

143. UN/CEFACT: Core Components Library, 

http://www.unece.org/etrades/download/downmain.htm 

144. UN/CEFACT: Techniques and Methodologies Group, http://www.untmg.org/ 

145. UN/CEFACT: UN/CEFACT Modeling Methodology (UMM) User Guide, 2003. 

146. Verva – Verket för forvaltningsutveckling: Nationellt ramverk för interoperabilitet, 2008. 

20.01.2010 Versjon 1.1 80/89

DIFI 


147. Wasznicky: Using Web Services Instead of DCOM, Microsoft, 2002. 

148. W3C: Accessible Rich Internet Applications (WAI-ARIA) 1.0, draft, 2009. 

149. W3C: Architecture of the World Wide Web, Volume One, Recommendation, 2004. 

150. W3C: Document Object Model (DOM) Technical Reports, 

http://www.w3.org/DOM/DOMTR 

151. W3C: Efficient XML Interchange (EXI) Format 1.0, Draft, 2007. 

152. W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition), Recommendation, 2008. 

153. W3C: HTML 4.01 Specification, Recommendation, 1999. 

154. W3C: HTML 5 - A vocabulary and associated APIs for HTML and XHTML, Draft 2009. 

155. W3C: XHTML 1.0 The Extensible HyperText Markup Language (Second Edition), 

Recommendation 2000, 2002. 

156. W3C: OWL-S: Semantic Markup for Web Services, Member submission, 2004. 

157. W3C: RIF Core Dialect, Candidate recommendation, 2009. 

158. W3C: Scalable Vector Graphics (SVG) 1.1 Specification, Recommendation 2003. 

159. W3C: Semantic Annotations for WSDL and XML Schema, Recommendation, 2007. 

160. W3C: Service Modeling Language, Version 1.1, Recommendation, 2009. 

161. W3C: SOAP Version 1.1, Note, 2000. 

162. W3C: SOAP Version 1.2 Part 1: Messaging Framework, Second Edition, 

Recommendation, 2007. 

163. W3C: SOAP Version 1.2 Part 2: Adjuncts, Second Edition, Recommendation, 2007. 

164. W3C: SOAP Messages with Attachments, 2000. 

165. W3C: SOAP Message Transmission Optimization Mechanism, 2005. 

166. W3C: SWRL: A Semantic Web Rule Language Combining OWL and RuleML, Member 

submission, 2004. 

167. W3C: Web Application Description Language, Member submission, 2009. 

168. W3C: WebApps Working Group, http://www.w3.org/2008/webapps/ 

169. W3C: Web Content Accessibility Guidelines 1.0, Recommendation, 1999. 

170. W3C: Web Content Accessibility Guidelines 2.0, Recommendation, 2008. 

171. W3C: Web Services Addressing 1.0, Recommendation, 2006. 

172. W3C: Web Services Glossary, W3C Working Group Note, 2004. 

173. W3C: Web Service Definition Language Version 1.1, Note, 2001. 

174. W3C: Web Service Description Language Version 2.0 – Part 0: Primer, 2007. 

175. W3C: Web Service Description Language Version 2.0 – Part 1: Core Language, 


176. W3C: Web Service Description Language Version 2.0 – Part 2: Adjuncts, 


177. W3C: Web Service Description Language Version 2.0 – Additional MEPs, 2007. 

178. W3C: Web Service Metadata Exchange, public draft, 2009. 

179. W3C: Web Services Enumeration (WS-Enumeration), member submission, 2006. 

180. W3C: Web Services Eventing (WS-Eventing), member submission, 2006. 

181. W3C: Web Services Fragment (WS-Fragment), working draft, 2009. 

20.01.2010 Versjon 1.1 81/89

DIFI 


182. W3C: Web Services Policy 1.5 – Framework, Recommendation, 2007. 

183. W3C: Web Services Policy 1.5 – Attachment, Recommendation, 2007. 

184. W3C: Web Services Resource Transfer (WS-RT), Draft, 2009. 

185. W3C: Web Service Semantics - WSDL-S, Member submission, 2005. 

186. W3C Member Submission 7 November 2005 

187. W3C: Web Services Transfer (WS-Transfer), Draft, 2009. 

188. W3C: Namespaces in XML 1.0 (Second Edition), Recommendation, 2006. 

189. W3C: XForms 1.0, Recommendation, 3. utgave, 2007. 

190. W3C: XForms 1.1, Recommendation, 2009. 

191. W3C: XML-binary Optimized Packaging, Recommendation, 2005. 

192. W3C: XML Encryption Syntax and Processing, Recommendation, 2002. 

193. W3C: XML Events - An Events Syntax for XML, Recommendation 2003. 

194. W3C: XML Information Set, Recommendation, 2001. 

195. W3C: XML Key Management Specification (XKMS 2.0), Recommendation, 2005. 

196. W3C: XML Linking Language (XLink) Version 1.0, Recommendation, 2001. 

197. W3C: XML Path Language (XPath) 2.0, Recommendation, 2007. 

198. W3C: XML Schema 1.0 - Second Edition, Recommendation, 2004. 

199. W3C: XML Schema Definition Language (XSD) 1.1, Candidate recommendation, 2009. 

200. W3C: XML Signature Syntax and Processing, Recommendation, 2002. 

201. W3C: XSL Transformations (XSLT) Version 1.0, Recommendation, 1999. 

202. W3C: XSL Transformations (XSLT) Version 2.0, Recommendation, 2007. 

203. W3C: XQuery 1.0: An XML Query Language, Recommendation, 2007. 

204. W3C: Web Services Choreography Description Language Version 1.0, Candidate 

recommendation, 2005. 

205. WfMC: Terminology & Glossary, 1999. 

206. WfMC: Process Definition Interface – XML Process Definition Language 2.1, standard, 

2008. 

207. WfMC: Business Process Analytics Format (BPAF), draft standard, 2009. 

208. Winer: XML-RPC specification, http://www.xmlrpc.com/ 

209. WS-I – Web Service Interoperability Organization: Basic Profile Version 1.2, 2007. 

210. WS-I – Web Service Interoperability Organization: Basic Profile Version 2.0, 2007. 

211. WS-I – Web Service Interoperability Organization: Basic Security Profile Version 1.0, 

2007. 

212. XMPP: Extensible Messaging and Presence Protocol, http://xmpp.org/ 

213. Aalst, Hostede: Workflow patterns, www.workflowpatterns.com 

20.01.2010 Versjon 1.1 82/89

DIFI 


Vedlegg B. Forkortelser 

AAPML Attribute Authority Policy Markup Language 

ADM Architecture Development Methodology (TOGAF) 

ADO Active Data Objects 

AJAX Asyncgronous Javascript and XML 

AMP Agent Metamodel & Profile (OMG) 

API Application Programming Interface 

AS2 Applicability Statement 2 

ASN.1 Abstract Syntax Notation One 

ATAG Authoring Tool Accessibility Guidelines 

BCM Business Centric Methodology 

BIE Business Information Entity 

BIM Building Information Model 

BiM Binary MPEG format for XML 

BMM Business Motivation Model (OMG) 

BPAF Business Process Analytics Format 

BPDL Business Process Depiction Language 

BPDM Business Process Definition Metamodel 

BPEL Business Process Execution Language, også kalt WS-BPEL 

BPM Business Process Management 

BPML Business Process Modeling Language 

BPMN Business Process Model and 

BPMS Business Process Management System 

BPQL Business Process Query Language 

BPSS Business Process Specification Schema 

BRM Business Reference Model (FEAF) 

CAM Content Assembly Mechanism 

CARML Client Attribute Requirement Markup Language 

CC Core Components (ebXML) 

CCL Core Components Library (ebXML) 

CCTS Core Components Technical Specification (ebXML) 

COM Component Object Model 

CORBA Common Object Request Broker Architecture 

CPP Collaboration Protocol Profile 

CPP Collaboration Protocol Agreement 

CRM Customer Relations Management 

CRUD Create, Read, Update, Delete 

CSS Cascading stylesheets 

CSV Comma Separated Values 

20.01.2010 Versjon 1.1 83/89

DIFI 


CWM Common Warehouse Model (OMG) 

DAML DARPA Agent Markup Language 

DCOM Distributed Component Object Model 

Difi Direktoratet for forvaltning og IKT 

DISCO Discovery of File 

DMTF Distributed Management Task Force 

DNS Domain Name System 

DoDAF Department of Defence Architecture Framework 

DOM Document Object Model 

DRM Data Reference Model (FEAF) 

DSA Digital Signature Algorithm 

DSIG Digital Signature 

DSML Directory Services Markup Language 

DTD Document Type Definition 

E2A Extended Enterprise Architecture 

EA Enterprise Architecture 

EAI Enterprise Application Integration 

EARL Evaluation and Report Language 

ebBP ebXML Business Process Specification Schema (BPSS) 

ebMS ebXML Messaging Service 

ebXML eBusiness XML 

ECA Event Condition Action 

EDI Electronic Data Interchange 

EDOC Enterprise Distributed Object Computing (OMG) 

eID Elektronisk identifikasjon 

EIF European Interoperability Framework 

EIM Engineering Information Management 

EIPS Engineering Information Property Sets (RosettaNet) 

EMP Event Metamodel & Profile (OMG) 

ERP Enterprise Resource Planning 

ESB Enterprise Service Bus 

ETL Extract-Tranform-Load 

eTOM enhanced Telecom Operations Map 

ETSI European Telecommunications Standards Institute 

EXI Efficient XML Interchange 

FAOS Felles arkitektur i offentlig sektor 

FEAF Federal Enteprise Architecture Framework 

ftp File Transfer Protocol 

GAB Grunneiendom-, adresse- og bygningsregistert 

20.01.2010 Versjon 1.1 84/89

DIFI 


GIOP General Inter-ORB Protocol 

GML Binary XML Encoding Specification for geo-related data 

HR Human Resources 

HTML HyperText Markup Language 

http Hypertext Transfer Protocol 

IDEF Integrated Definition Methods 

IEC International Electrotechnical Commission 

IEEE Institute of Electrical and Electronics Engineers 

IFEAD Institute for Enterprise Architecture Developments 

IGF Identity Governance Framework 

IIOP Internet Inter-ORB Protocol 

IKT Informasjons- og kommunikasjonsteknologi 

IP Internet Protocol 

ISO International Organization for Standardization 

ITIL Information Technology Infrastructure Library 

ITSMF IT Service Management Forum 

ITST IT og Telestyrelsen 

ITU International Telecommunication Union 

JCA Java Connector Architecture 

JDBC Java Database Connection 

JDO Java Data Objects 

JMS Java Message Service 

JPA Java Persistence API 

JSON JavaScript Object Notation 

JSR Java Specification Request 

KITH Kompetansesenteret for IT i helse- og sosialsektoren 

KOSTRA Kommune stat rapportering 

LDAP Lightweight Directory Access Protocol 

LINQ Language-Integrated Query 

MIME Multipurpose Internet Mail Extensions 

ML Markup Language, Modeling Language 

MMS Multiple Messaging Services (RosettaNet) 

MoDAF Ministry of Defence Architecture Framework 

MOF Meta Object Facility 

MOM Meldingsorientert mellomvare 

MOWS Management Of Web Services 

MTOM Message Transmission Optimization Mechanism 

MUWS Management Using Web Services 

MVC Model View Controller 

20.01.2010 Versjon 1.1 85/89

DIFI 


MXML Macromedia eXtensible Markup Language 

NAF Nato Architecture Framework 

NESUBL Northern European Subset of UBL 

NIH National Institute of Health 

NIST National Institute of Standards and Technology 

Noark Norsk arkivstandard 

OAG Open Applications Group 

OASIS Organization for the Advancement of Structured Information Standards 

OCL Object Constraint Language 

ODBC Open Database Connection 

ODM Ontology Definition Metamodel (OMG) 

OIO Offentlig Informasjon Online 

OMG Object Management Group 

OO Object Oriented 

OSIMM TM The Open Group Service Integration Maturity Model 

OWL Web Ontology Language 

OWL-S Ontology Web Language - Services 

PDP Policy Decision Point 

PEAF Pragmatic Enterprise Architecture Framework 

PEPPOL Pan-European Public eProcurement On-Line 

PGP Pretty Good Privacy 

PIP Partner Interface Process (RosettaNet) 

PKI Public Key Infrastructure 

PMML Predictive Model Markup Language 

PRM Performance Reference Model (FEAF) 

PRR Production Rule Representation (OMG) 

RAE RosettaNet Automated Enablement 

RAS Reusable Asset Specification (OMG) 

RBAC Role Based Access Control 

RDF Resource Description Framework 

REL Rights Expression Language 

REST Representational State Transfer 

RFI Request For Information 

RIF Rule Interchange Format 

RMI Remote Method Invocation (Java) 

RM-ODP Reference Model of Open Distributed Processing 

RNIF RosettaNet Implementation Framework 

RPC Remote Procedure Call 

RSA Rivest, Shamir, Adleman 

20.01.2010 Versjon 1.1 86/89

DIFI 


SAML Security Assertion Markup Language 

SAWSDL Semantic Annotations for WSDL and XML Schema 

SAX Simple API for XML 

SCOR Supply Chain Operations Reference 

SERES Semantikkregisteret for elektronisk samhandling 

SGK Statens Generelle Kravspesifikasjon 

SGML Standard Generalized Markup Language 

SLA Service Level Agreement 

SMIL Synchronized Multimedia Integration Language 

SML Service Modeling Language 

SMTP Simple Mail Transfer Protocol 

SOA Service Oriented Architecture 

SoaML Service oriented Architecture Modeling Language 

SOAP Tidligere: Simple Object Access Protocol, nå egennavn 

SOMA Service-Oriented Modeling and Architecture (IBM) 

SOMF Service-Oriented Modeling Framework 

SOX Sarbanes Oxley 

SPKI Simple Public key Infrastructure 

SPML Service Provisioning Markup Language 

SQL Structured Query Language 

SRM Service Component Reference Model (FEAF) 

SSB Statistisk Sentralbyrå 

SSBP Simple SOAP Binding Profile 

SSL Secure Sockets Layer 

SSO Single Sign On 

STEP Standard for the Exchange of Product Model Data 

STORK Secure Identity Across Borders Linked 

STS Security Token Service 

SVBR Semantics of Business Vocabulary and Business Rules (OMG) 

SVG Scalable Vector Graphics 

SWA SOAP with Attachments 

SWAP Simple Workflow Access Protocol 

SWF Small Web Format, Shockwave Flash 

SWRL Semantic Web Rule Language 

SysML Systems Modeling Language (OMG) 

TEAF Treasury Enterprise Architecture Framework 

TLS Transport Level Security 

TOGAF TM The Open Group Architecture Framework 

TPIR Trading Partner Implementation Requirements (RosettaNet) 

20.01.2010 Versjon 1.1 87/89

DIFI 


TRM Technical Reference Model (FEAF, TOGAF) 

UAAG User Agent Accessibility Guidelines 

UBL Universal Business Language 

UDDI Universal Description Discovery and Integration 

UML Unified modeling Language 

UMM UN/CEFACT Modeling Methodology 

UNSPSC United Nations Standard Products and Services Code 

URL Uniform resource Locator 

VCOR Value Chain Operations Reference 

VDM Value Delivery Modell (OMG) 

VTD Virtual Token Descriptor 

W3C World Wide Web Consortium 

WADL Web Application Description Language 

WAF Web Application Formats 

WAI-ARIA Accessible Rich Internet Applications 

WBXML WAP Binary XML 

WCAG Web Content Accessibility Guidelines 

WCF Windows Communication Foundation 

WfMC Workflow Management Coalition 

WS Web service 

WS-BPEL Web Services – Business Process Execution Language 

WS-CAF Web Services Composite Applications Framework 

WS-CDL Web Services Choreography Description Language 

WS-CF Web Services Coordination Framework 

WS-CF Web Services Coordination Framework 

WSCI Web Service Choreography Interface 

WSCL Web Services Conversation Language 

WSDL Web Service Description/Definition Language 

WSDL-S Web Service Description Language - Semantics 

WSDM Web Services for Distributed Management 

WSDS WS-Enumeration Directory Services Protocol Extensions 

WSFL Web Services Flow Language 

WS-I Web Service Interoperability Organization 

WSIL Web Services Inspection Language 

WSML Web Services Modeling Language (ESSI) 

WSMO Web Services Modeling Ontology (ESSI) 

WSRF Web Services Resource Framework 

WSRP Web Services for Remote Portlets 

WS-RT Web Services Resource Transfer 

20.01.2010 Versjon 1.1 88/89

DIFI 


WSS Web Service Security 

WS-TXM Web Services Transaction Management 

WYDIWYE What You Draw Is What You Execute 

XACML eXtensible Access Control Markup Language 

XAdES XML Advanced Electronic Signatures 

XAML Extensible Application Markup Language 

XBL XML Binding Language 

XHTML Extensible HyperText Markup Language 

XKMS XML Key Management Specification 

XLink XML Linking Language 

XML Extensible Markup Language 

XMPP Extensible Messaging and Presence Protocol 

XOP XML-binary Optimized Packaging 

XPath XML Path Language 

XPDL XML Process Definition Language 

XQuery XML Query Language 

XRX XForms–REST–XQuery 

XSD XML Schema Definition 

XSLT XML Transformations 

20.01.2010 Versjon 1.1 89/89

Kartlegging av mulige standarder for tjenesteorientert arkitektur ... - Difi

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?