Kartlegging av mulige standarder for tjenesteorientert arkitektur i offentlig sektor. Forprosjektrapport

Transkript

1 Kartlegging av mulige standarder for tjenesteorientert arkitektur i offentlig sektor Forprosjektrapport På oppdrag for Lysaker, 20. januar 2010 Versjon 1.1

2 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 Versjon 1.1 2/89

3 Innhold 1 Sammendrag Anbefaling av standarder Andre anbefalinger Innledning Bakgrunn Målsetninger Avgrensning Viktige begreper Rapportens struktur Anvendelse av metoder og standarder i ulike scenarioer Scenario: Informasjonsutveksling mellom enheter i offentlig sektor Tekniske løsninger Standarder for meldingsutveksling Standarder for sikkerhet Løsninger for kommunikasjon Løsninger for store datamengder Dataformater Tjenestekataloger Scenario: Tilgjengeliggjøring av registerdata Tekniske løsninger Løsninger for søk Løsninger for semantisk interoperabilitet Scenario: Saksbehandling Krav til interaksjon med tjenestebrukere Tekniske løsninger Prosessmotor og regelmotor Interoperabilitet mellom fagsystem Arkivering Kontakt med bruker Interaksjon mellom brukergrensesnitt og prosess Scenario: Innrapportering til det offentlige Tekniske løsninger Løsninger for skalerbarhet Løsninger for prosess, koordinering og fordeling Løsninger for dataoverføring Metoder og standarder for tjenesteorientert arkitektur Arkitekturmessige betraktninger på bruksscenarioene Metoder og standarder for tjenestelaget Web services WSDL Modularisering av tjenester og data Versjonsstyring av tjenester og dataformat Standarder tilknyttet WSDL Profiler for webtjenester REST ebxml for ehandel RosettaNet Semantiske tjenestebeskrivelser Mellomvare Ulike typer mellomvare Beskrivelse og oppdagelse av tjenester Teknisk styring og drift av tjenester Kommunikasjon Metoder for meldingsutveksling Standarder for direkte kall til tjenester Hendelser og notifikasjon Versjon 1.1 3/89

4 4.4.4 WS-Addressing - ruting og adressering av tjenester Data og informasjon Nivåer for dataintegrasjon Profiler for informasjonsutveksling XML ebxml Core Components Innholdsstandarder Andre tekstlige formater Binær XML WS-Enumeration - Tjenesteorientert tilgang til sammensatte data Databaseintegrasjon Portaler, interaksjon og presentasjon Kanaler HTML Tilgjengelighet for alle ELMER WSRP Web Services for Remote Portlets AJAX W3C Webapps Interaktivt multimedia og rike grensesnitt Samhandling, prosesser og komposisjon av tjenester BPEL WS-CDL ebxml BPSS WS-CAF Composite Applications Framework WS-Transactions Overvåking og styring av prosesser Business Centric Methodology (BCM) og Content Assembly Mechanism (CAM) Andre standarder Sikkerhet og pålitelighet eid og ID-porten SAML XACML WS-Security XML kryptering og signering Åpne industristandarder for autentisering og autorisasjon Pålitelig meldingsutveksling ISO/IEC Avhengigheter mellom standarder Modellering av tjenester Prosesser og sammenstilling av tjenester Modelldrevet utvikling av tjenester Modellering av regler Virksomhetsarkitektur for forvaltning av tjenester Råd for videre arbeid Basis standarder som trolig bør anbefales Andre standarder som kan anbefales Standarder som kan vurderes seinere Områder for videre kartlegging Forvaltning og drift av tjenester Tjenester i skyen Pragmatisk semantikk Virksomhetsarkitektur Modelldrevne applikasjoner Vedlegg A. Referanser Vedlegg B. Forkortelser Versjon 1.1 4/89

5 Figurer Figur 1. Bruksområder for tjenesteorientert arkitektur Figur 2. Scenarioer for tjenesteorientert arkitektur Figur 3. Offentlig tjenesteyting før tjenesteorientert arkitektur Figur 4. Første generasjon tjenesteorientert arkitektur Figur 5. Andre generasjon tjenesteorientert arkitektur Figur 6. Komponenter i tjenesteorientert arkitektur Figur 7. Ulike løsninger for tilgjengeliggjøring av registerdata Figur 8. Oversikt over standarder for webtjenester Figur 9. Interoperabilitet på ulike nivåer Figur 10. Arkitektur for dynamiske brukergrensesnitt for webtjenester [168] Figur 11. Avhengigheter mellom standarder for webtjenester Figur 12. Bruk av virksomhetsarkitektur Figur 13. Hovedbegreper i TOGAF [132] Figur 14. Ulike nivåer av virksomhetsarkitektur i offentlig sektor [37] Versjon 1.1 5/89

6 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] Versjon 1.1 6/89

7 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] Versjon 1.1 7/89

8 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 Versjon 1.1 8/89

9 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 Versjon 1.1 9/89

10 Tilgjengeliggjøring av registerdata 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). Offentlig sektor 2 Innbyggere Enhet 1 1 Enhet n 4 Næringsliv 3 Næringsliv Enhet 2 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 Scenarioene henger sammen som illustrert i figuren under: Offentlig sektor Saksbehandling Informasjonsutveksling Innrapportering Register Figur 2. Scenarioer for tjenesteorientert arkitektur 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 Versjon /89

11 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? Versjon /89

12 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 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) 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 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: Versjon /89

13 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 ) WS-Security 1.0 for signering/kryptering og autentisering (avsnitt 4.8.4) o o o o o Kravspesifikasjon for PKI i offentlig sektor og sertifikater fra eid for personer og virksomheter SAML hvis tjeneste for engangs innlogging brukes X.509 sertifikater og brukersertifikater WS-SecurityPolicy for sikkerhetsregler og -parametere 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 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 ). 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 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 ), men også den grunnleggende Versjon /89

14 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 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) 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 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 Versjon /89

15 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 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 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] Versjon /89

16 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 Versjon /89

17 Det kan være ulike forventninger til datakvalitet og presisjon, inkludert oppdateringshyppighet Tekniske løsninger 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 avsnitt 4.5.9). 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 Versjon /89

18 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 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 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 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 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 Versjon /89

19 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 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 Tekniske løsninger Ved siden av informasjonsutveksling mellom virksomheter i offentlig sektor og tilgjengeliggjøring av registre, vil saksbehandling ofte kreve interoperabilitet mellom Versjon /89

20 fagsystem, ulike løsninger for kommunikasjon med tjenestebrukeren, samt generell saksbehandlingsstøtte fra prosess- eller regelmotorer 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 ). 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 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 ), 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 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 Versjon /89

21 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 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 Kontakt med bruker Saksbehandling vil utgjøre et av hovedelementene ved innbyggernes, næringslivets og organisasjoners interaksjon med offentlig IKT-tjenester. Sammenlignet med Versjon /89

22 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 e- post i tillegg til web-skjemaer. Xforms (avsnitt ) og proprietære løsninger fra f.eks. Adobe og Microsoft tilbyr dette (jf. avsnitt 4.6.8). Altinn I bruker Xforms 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, Versjon /89

23 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] Tekniske løsninger 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 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 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 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 Versjon /89

24 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 Versjon /89

25 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]: Innbyggere Næringsliv Offentlig virksomhet Offentlig virksomhet Saksbehandlere Saksbehandlere Brukergrensesnitt Brukergrensesnitt Brukergrensesnitt Brukergrensesnitt Applikasjon Applikasjon Applikasjon Applikasjon Database Database Database 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: Versjon /89

26 Innbyggere Næringsliv Offentlig virksomhet Offentlig virksomhet Saksbehandlere Portaler Portaler Saksbehandlere Tjenester Tjenester Brukergrensesnitt Brukergrensesnitt Applikasjon Database 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.: Innbyggere Næringsliv Fellestjenester for offentlig sektor Offentlig virksomhet Offentlig virksomhet Presentasjon og interaksjon Saksbehandlere Saksbehandlere Samhandling Tjenester Tjenester Brukergrensesnitt Komponenter Brukergrensesnitt Applikasjon Database Infrastruktur Database Applikasjon Figur 5. Andre generasjon tjenesteorientert arkitektur. 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 Versjon /89

27 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. Innbyggere Portal Næringsliv Interaksjon Portal Samhandling Portal Komponenter Andre enheter Applikasjonsbrukergrensesnitt Meldingsutveksling Database Infrastruktur API API API API Applikasjon Ansatte Utviklingsverktøy Forvaltning, drift og utvikling 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, Lavnivå tjenester fra grensesnittet til applikasjonen, Versjon /89

28 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. Innbyggere Portal Næringsliv Interaksjon Portal Samhandling Portal Komponenter Andre enheter Database Infrastruktur API API API API Applikasjon Meldingsutveksling Applikasjonsbrukergrensesnitt Ansatte 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 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 Versjon /89

29 fortsatt i bruk på noen områder. For brukerinteraksjon og løst sammenkoblede tjenester har arkitekturstilen REST etablert seg, delvis overlappende med webtjenester 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 ), som overfører meldinger med innhold i XML over http. WSDL bruker derfor XML Schema (avsnitt ) 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 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 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 Versjon /89

30 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 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 Versjon /89

31 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 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 BCM CAM WS-Remote Portlets Sikkerhet og pålitelighet WS-Trust WS- Federation Forvaltning XPDL WS-BPEL XForms WS-Secure Conversation WS-Security SPML WS- Management WSDM WS-CDL Choreography WS- Transaction WS-CAF Context WS-Reliable Messaging WS-Security Policy SAML WS-Resource Framework Tjenester og mellomvare WS-Metadata Exchange WS-Policy WS- Enumeration WS-Resource Transfer WS- Inspection UDDI WS- Discovery WS- Adressing WS- Fragment WS-Transfer WSDL 1.1 WSDL 2.0 Kommunikasjon SOAP 1.1 SOAP 1.2 SOAP MTOM WS-Eventing WS- Notification SOAP with Attachments MIME Data XML Namespaces XSLT XML Schema 1.0 XML 1.0 XOP EXI XML Signature XML Infoset XPath XML Schema 1.1 XML Encryption Profiler for webtjenester 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]: 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 Versjon /89

32 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 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 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 : ebxml Collaborative Partner Profile Agreement ISO : ebxml Messaging Service Specification ISO : ebxml Registry Information Model ISO : ebxml Registry Services Specification ISO : ebxml Core Components Technical Specification Versjon /89

33 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 Tjeneste BPEL WSDL BPSS, CPP/CPA Register UDDI ebxml Registry Meldinger SOAP SOAP, ebms Informasjon XML Schema Core components XML Schema 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] 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 ) 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 Versjon /89

34 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 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 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 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 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 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 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) Implementasjon - RosettaNet Implementation Framework RosettaNet Implementation Framework (RNIF) spesifiserer løsninger for pakking, ruting og transport av meldinger som inngår i en PIP Versjon /89

35 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 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 Versjon /89

36 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 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 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] 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 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 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 Meldingsmeglere Meldingsmeglere (message brokers) støtter transformasjon, lagring og ruting av meldinger basert på hendelser og regler, på toppen av MOM Versjon /89

37 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 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 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] 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 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å Versjon /89

38 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 ), 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 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 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 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 ). 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 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, Versjon /89

39 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 og 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] 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 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 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, Versjon /89

40 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 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 ), 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 Versjon /89

41 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 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 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] 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 JSON-RPC JSON-RPC er en parallell til SOAP som i stedet for XML bruker Javascript Object Notation (JSON, avsnitt ) 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 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 Versjon /89

42 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 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 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 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 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 ) og WS- ReliableMessaging (avsnitt 4.8.7). IBM har vært toneangivende i utviklingen av WS Versjon /89

43 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] 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 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. Applikasjon eller tjeneste 1 Applikasjon eller tjeneste 2 Virksomhetsintegrasjon Virksomhet 1 Virksomhet 2 Applikasjonsintegrasjon Databaseintegrasjon Database 1 Database 2 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 Versjon /89

44 tjenesteorientert arkitektur, mens sistnevnte dekkes av avsnittet om interaksjon og presentasjon (4.6) 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 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 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 Profiler for informasjonsutveksling Dette avsnittet ser på ulike angrepsmåter eller overordnede metoder for å oppnå interoperabilitet for data 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 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 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 Versjon /89

45 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 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 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 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 Versjon /89

46 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 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 og 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 Versjon /89

47 gjenbruksmekanismene er på gang i prosjektene Unified Context Methodology og Core Components Message Assembly [144] 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) 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 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 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] 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 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) 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 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 Versjon /89

48 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 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 ). 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 ). 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) 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 ). Microsoft har dessuten definert en åpen utvidelse av dette for katalogdata, kalt WS-Enumeration Directory Services Protocol Extensions (WSDS) 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 Versjon /89

49 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 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 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) 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å 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 Versjon /89

50 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 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 og ). For standardisering i dag er versjon 3 den stabile og utbredte utgaven 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 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 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] 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 Versjon /89

51 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 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 ) 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 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 ) 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 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 Versjon /89

52 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] 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 Versjon /89