Bruk av Web Services i AltInn - på vei mot et enklere Norge? Bjørn Tore Egeberg. Institutt for informasjonsvitenskap, Høgskolen i Agder, Kristiansand

Transkript

1 Bruk av Web Services i AltInn - på vei mot et enklere Norge? Bjørn Tore Egeberg Institutt for informasjonsvitenskap, Høgskolen i Agder, Kristiansand 1

2 Forord Denne rapporten er en masteroppgave i informasjonssystemer ved Høgskolen i Agder, Kristiansand. Arbeidet med undersøkelsen som har ført fram til rapporten har vært lærerikt og interessant. Jeg har møtt mange mennesker med høy IT-kompetanse. Flere av disse har demonstrert stor tålmodighet og gode pedagogiske evner. Det har også vært en nyttig erfaring å styre planleggingen og framdriften med undersøkelsen på egen hånd. Rapporten er skrevet på norsk. Det har gitt meg noen utfordringer jeg ikke hadde regnet med. Mange faguttrykk har jeg bare funnet i kilder på engelsk. Jeg har brukt norske uttrykk der disse er innarbeidet. I tillegg har jeg oversatt noen faguttrykk sjøl, der det har vært mulig å få til en språklig entydig oversettelse. Men i mange tilfeller har jeg ikke funnet noe entydig norsk uttrykk. I de tilfellene har jeg brukt de engelske betegnelsene. Jeg beklager at språket i oppgaven lider under at mange norske setninger inneholder engelske ord. Et grunnleggende språklig valg er at jeg bare bruker den engelske flertallsformen Web Services. Når jeg har hatt behov for en entallsform, har jeg skrevet webtjeneste, selv om det er en nyanseforskjell mellom dette ordet og det engelske Web Service. Jeg har hatt mange gode hjelpere. Jeg vil takke min veileder, 1.lektor Even Aaby Larsen ved institutt for informasjonsvitenskap, Høgskolen i Agder. Jeg vil også takke alle som har lest hele eller deler av manuset og kommet med verdifulle innspill. Til slutt vil jeg takke Lindis Christie for uredde kommentarer og varm moralsk støtte i hele oppgaveperioden. Kristiansand, mai 2004 Bjørn Tore Egeberg 2

3 Sammendrag Web Services er en teknologi som har blitt møtt med store forventninger. Teknologien hevdes å være spesielt godt egnet når man skal ha forskjellige datasystemer til å snakke sammen. Dette er bakgrunnen for at regjeringen Bondevik har satset på Web Services i et stort prosjekt som omfatter flere offentlige etater. Prosjektet heter AltInn. Prosjektets mål er å samle all innrapportering fra næringslivet til offentlige etater i en kanal. Jeg har en todelt innstilling til nye IT- teknologier. Jeg er på den ene siden nysgjerrig, og er aktiv til å sette meg inn i hva de tilbyr. På den andre siden er jeg kritisk, og vil ha dokumentert at de nye teknologiene gir varige framskritt. Problemstillingen jeg har undersøkt forstås best i lys av denne innstillingen. Den er: Hvor godt egnet er Web Services til integrasjonsløsninger som er begrenset til dataintegrasjon? I 2. Teori om webtjenester og Web Services definerer jeg de viktigste begrepene. Jeg har valgt å gi min egen definisjon, blant annet fordi det finnes mange konkurrerende definisjoner i faglitteraturen. Ifølge min definisjon er en webtjeneste et dataprogram som tilbyr tjenester til andre dataprogrammer. Web Services er webtjenester som er bygd opp etter bestemte spesifikasjoner. Ut fra denne definisjonen har jeg dekning for å si at AltInn inneholder Web Services. Og for å si at AltInn inneholder en webtjeneste. Jeg bruker disse to uttrykkene om hverandre i beskrivelsen av AltInn. I løpet av de siste årene har det vært en rivende utvikling i nye anvendelser av Web Services. Det har vært nødvendig å etablere mange nye faguttrykk for å beskrive dette. Mange av disse ordene er nødvendige for å bygge et teoretisk fundament rundt bruk av Web Services. Det mest grunnleggende uttrykket er løse koblinger, som er en helhetlig tilnærming for å bygge inn fleksibilitet i grensesnittene mellom to datasystemer. Denne undersøkelsen består av teoristudier, informasjonssøk på Internett og en intervjuundersøkelse. I 3. Forskningstilnærming og metode forklarer hva jeg har gjort, og begrunner de metodevalgene jeg har tatt. I 4. Funn presenterer jeg de viktigste funnene fra informasjonssøk og intervjuer. I 5. Evaluering og diskusjon gjennomfører jeg en evaluering av integrasjonsløsningene i AltInn. Disse løsningene inneholder Web Services. På grunnlag av evalueringen går jeg videre og drøfter egnetheten av Web Services til denne typen oppgaver. Konklusjonen i denne studien er at Web Services er meget godt egnet til integrasjonsløsninger som er begrenset til dataintegrasjon, forutsatt at aktørene gjør en profesjonell jobb med semantikken. Det kommer til å bli spennende å følge utviklingen og utbredelsen av Web Services i årene som kommer. Nøkkelord: Asynkron meldingstjeneste, integrasjon, løse koblinger, samhandling, semantikk, tjenesteorientert arkitektur, Web Services, webtjenester 3

4 1. Introduksjon Stadig flere IT-prosjekter dreier seg om å få forskjellige systemer til å snakke sammen. Dette kalles vanligvis integrasjon og samhandling. Mange sliter med å få dette til. Kjent teknologi kommer til kort. Prosjektene blir for dyre; ofte fordi man må gjøre store tilpasninger (skreddersøm) på hvert eneste system som skal kommunisere med andre. De delene av to systemer som kommuniserer med hverandre kalles grensesnitt. Ledende aktører i IT-bransjen har utviklet en ny måte å lage disse grensesnittene på, Web Services. Web Services er skrevet etter en fast standard. Web Services blir promotert fra programvareindustrien som det nye lavkostalternativet for integrasjon av IT-funksjoner både i og mellom bedrifter (Butler Group, 2002). I 2. Teori om webtjenester og Web Services vil jeg presentere teknologien grundigere Problemstilling Hvor bra er Web Services? Hvilke oppgaver kan løses med Web Services? Disse spørsmålene kan nå studeres med et norsk eksempel. Det heter AltInn. AltInn bruker Web Services for å få fagsystemer i næringslivet til å snakke med datasystemene i de offentlige etatene. Jeg har brukt AltInn som case i min undersøkelse. Når to eller flere system utveksler data, og i tillegg deler hverandres funksjonalitet, kalles det funksjonsintegrasjon. Dersom de bare utveksler data, kalles dette dataintegrasjon. AltInn brukes Web Services til dataintegrasjon mellom fagsystemer og etatsystemer Jeg har ikke hatt tilgang til empiri om funksjonsintegrasjon. Derfor gjør jeg ikke noe forsøk på å drøfte Web Services i sin fulle bredde. Jeg avgrenser meg til å studere Web Services og dataintegrasjon. Jeg har studert følgende problemstilling: Hvor godt egnet er Web Services til integrasjonsløsninger som er begrenset til dataintegrasjon? Jeg har valgt å gjøre en kvalitativ undersøkelse. Den har vært tredelt: Teoristudier om Web Services, informasjonssøk på Internett og en intervjuundersøkelse av AltInn. Til sammen har dette gitt et godt grunnlag for å drøfte Web Services egnethet. Hvordan kan erfaringene fra AltInn belegge synspunkter og konklusjoner om Web Services generelt? Hvordan kan en forsker gå fra det særegne til det allmenne? Jeg har valgt en forskningstilnærming som gjør dette mulig. Her vil jeg gi en kort beskrivelse av den. Jeg har først utledet en arbeidshypotese: Web Services er godt egnet til integrasjonsløsninger som er begrenset til dataintegrasjon. Jeg forutsetter at hvis dette er riktig, vil også integrasjonsløsningene i AltInn være vellykket. Og gjennom å evaluere integrasjonsløsningene, får jeg belegg for å trekke noen konklusjoner om Web Services egnethet: Hvis de fungerer godt (bekreftelse), har jeg ikke bevist noen ting, men min undersøkelse vil styrke hovedhypotesen. Hvis de ikke fungerer godt (falsifisering), har jeg svekket hovedhypotesen, dersom jeg kan argumentere for at det ikke finnes andre forklaringer til svakhetene. 4

5 Framgangsmåten min drøftes nærmere i 3. Forskningstilnærming og metode AltInn Jeg har allerede fortalt at AltInn handler om å få til kommunikasjon mellom fagsystemer og etatsystemer. Jeg vil her kort presentere bakgrunnen for AltInn-prosjektet. Jeg vil også gi en overordnet beskrivelse av innrapporteringsprosessen, og fortelle hvilke aktører som har realisert AltInn. I handlingsplanen Et enklere Norge (NHD, 2002) lanserer regjeringen AltInn. Bakgrunnen for prosjektet er at det offentlige pålegger næringslivet for mye arbeid. Det er beregnet at næringslivet bruker nesten 7400 årsverk på å fylle ut og sende inn statlige skjemaer hvert år (ibid.). Eksempler på slike skjemaer er: omsetningsoppgave selvangivelse lønns- og trekkoppgave statistikk over sykefravær AltInn tar i bruk Web Services for å få fagsystemene og etatsystemene til å snakke sammen. På denne måten kan det etableres en automatisk innrapportering, som vil forenkle hverdagen for næringslivet. En modell for automatisk innrapportering er vist i figur 1.1: Figur Modell av AltInn En avgiver er den personen eller organisasjonen som er pålagt å sende inn et skjema til en statlig etat AltInn vises her som en blå boks. Den inneholder teknologi som muliggjør kommunikasjon mellom de to systemene 5

6 I denne undersøkelsen har jeg bare gått inn på den venstre halvdelen av modellen. Jeg har undersøkt integrasjon og samhandling mellom fagsystemene og AltInn. Jeg har valgt å ikke gå nærmere inn på hvordan etatsystemene og AltInn snakker sammen. Av statlige etater deltar foreløpig Skattedirektoratet, Brønnøysundregistrene, Statistisk Sentralbyrå og Statens lånekasse for utdanningssøkende. Det er meningen at flere skal tilslutte seg etter hvert. Etatene har etablert en prosjektorganisasjon. IT-bedriften Accenture fikk anbudet på å lage AltInn, og har gjort dette i dialog med etatenes mottaksprosjekt. Prøvedrift av AltInn ble startet høsten Ordinær drift startet 1.februar Når dette skrives er det bare et begrenset antall skjema som kan sendes inn via automatisk innrapportering Fagsystemer og bedriftssystemer Nå som jeg har presentert AltInn er det på tide å si noe om fagsystemene. Det kan være mange forskjellige typer av informasjonssystemer som lagrer de økonomiske dataene som skal innrapporteres til offentlige etater. En liten bedrift har vanligvis et enkelt økonomisystem som håndterer hovedbok, reskontro, lønn, innkjøp og faktura. Noen har i tillegg et eget årsoppgjørssystem. En stor bedrift har ofte ett stort system (for eksempel ERP Enterprise Resource Planning ) som integrerer økonomiske data med all annen styringsinformasjon. Accenture (2003) bruker betegnelsene fagsystem og bedriftssystem som sekkebetegnelser på alt dette. Accenture (2003) definerer fagsystem som system som leverer data til AltInn. Et bilde av dette markedet får vi ved å se hvilke leverandører som arbeider med integrasjon mot AltInn, se tabell 1.1: Tabell Leverandører som planlegger integrasjon mot AltInn (AltInn, 2004) Agresso Agrodata Akelius Allinfo Cantor DI Duett Finale Maestro Mamut Mokastet Data Notodden Programutvi kling Regnskapsog bedriftssyste mer Sticos Sunsoft Tieto Enator Unimicro Visma Store aktører som hittil ikke har meldt sin interesse er Hansa, Microsoft, Oracle og SAP. I andre sammenhenger brukes ordet fagsystem om et fagspesifikt informasjonssystem som ikke inneholder økonomidata overhodet. Men i AltInn-sammenheng betyr det altså system som lagrer økonomiske data. 6

7 2. Teori om webtjenester og Web Services I dette kapitlet drøfter jeg først konteksten som har ført til gjennombruddet for Web Services. Deretter beskriver jeg hva webtjenester og Web Services er. Hovedkilden for dette er Hartvigsen (2002). Deretter følger en evaluering av hvor Web Services står i dag (muligheter og begrensninger). Til slutt kommer to deler som først og fremst refererer og drøfter synspunktene som kommer fram i boka til Kaye (2003): Tanker om bruk av Web Services Sikkerhet 2.1. Kontekst Før jeg begynner å presentere teorien om webtjenester og Web Services vil jeg drøfte hva som er bakgrunnen for at det satses så tungt på denne teknologien. Hvilke forventninger er knyttet til den? Hvilken kontekst er det som presser den fram? Her vil jeg kort referere enkelte av de visjonene som har kommet på trykk de siste årene. De fleste moderne virksomheter er informasjonsintensive. Det blir regnet som en viktig fordel å kunne håndtere all denne informasjonen bedre enn konkurrentene. Den som utnytter IT mest effektivt, vil finne best løsninger på kjente utfordringer som kvalitetsledelse, kundeorientering, verdikjedeoptimalisering og strategiske allianser. At ITs rolle er anerkjent viser oppkommet av nye ord som e-handel og enorge. Pollock (2001) skriver at utviklingen av datasystemer følger to hovedretninger: Datasystemer som løser forretningsoppgaver og datasystemer som kan knytte seg til andre datasystemer. Hovedsatsingen i dag er å få forskjellige datasystemer til å snakke sammen (ibid.). Integrasjon og samhandling har blitt nøkkelord for å få en effektiv utnytting av den nye teknologien. Dette blir en utfordring for tradisjonelle måter å programmere datasystemer på. Her tenker jeg spesielt på objektorientert programmering (en programmeringsteknikk som setter sammen mange små komponenter (objekter) til ett program). Disse har vist seg godt egnet til å lage datasystemer som løser forretningsoppgaver. De er også bra til å få dataprogrammer fra samme leverandør (for eksempel Microsoft) til å snakke sammen. Begrensningene har oppstått i forsøk på å få systemer som inkluderer forskjellige plattformer og programmeringsspråk til å snakke sammen. EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) var et av de første tunge initiativene for å etablere en standard for datautveksling mellom forskjellige datasystemer. Det kom på midten av 80-tallet, og er fortsatt utbredt. EDIFACT bygger på filoverføring, og kan derfor bruke alle transportmekanismer som kan transportere filer. Filformatet er proprietært. Det vil si at dette er en lukket standard, der man må kjøpe egen EDIFACT-programvare for å kunne lage slike filer. Kaye (2003) hevder at EDIFACT er stort, komplekst og dyrt. Siden begynnelsen av 90-tallet har det blitt lansert mange teknologier for å knytte sammen komponenter fra forskjellige systemer. En av dem er CORBA, Common Object Request Broker Architecture. Utviklingen av Web Services bygger i stor grad på erfaringene med CORBA. Svakheten med CORBA er, ifølge Kaye (2003), at man må kjenne oppbyggingen av de to systemene som skal snakke sammen for å kunne skrive et grensesnitt i CORBA. 7

8 Gabriel (2002) har en visjon der framtidas systemer vil bli bygd opp av millioner av komponenter. Han ser for seg at det er lett å finne adressen til en komponent som kan gjøre en bestemt oppgave. Det gjør det mulig å sette sammen et system som er et lappeteppe av komponenter fra datamaskiner som fysisk kan befinne seg hvor som helst. Dersom Gabriel har rett, vil dette medføre store fordeler. Ingen vil oppnå politisk eller økonomisk makt gjennom å eie de viktige datasystemene. Det blir faktisk ingen som kontrollerer dem. Men dersom dette blir virkelighet, vil det også medføre nye sikkerhetsutfordringer. Kritiske komponenter må sikres mot datakriminalitet. Gabriels visjon krever et brudd med tradisjonelle måter å programmere på. Gabriel lanserer ikke noen konkret løsning, men mange av poengene hans aktualiserer Web Services. Om ikke alle tør å spå like langt fram som Richard Gabriel, er det mange som deler visjonen om et felles grensesnitt, som gjør alle system i stand til å snakke med hverandre. En forutsetning for å oppnå dette er at grensesnittet er tilgjengelig på Internett eller et annet åpent nettverk. En annen forutsetning er at grensesnittet er selvforklarende, slik at systemene kan sette opp kommunikasjonskanalen uten at brukeren behøver å gjøre noe. Dette har vært et av målene med Web Services. Booch (2003) deler også målet om å gjøre det lettere for datasystemer å snakke sammen, uavhengig av plattformvalg. Han har nye synspunkter på hvilke metoder i systemutviklingen som bringer oss nærmere målet. Han lanserer begrepet aspektorientert programmering. Det er programmering i store tverrfaglige team som arbeider med en felles hensikt. Booch tror at aspektorientert programmering er riktig metode for å bygge Web Services. Web Services vil vise sin styrke gjennom å heve abstraksjonsnivået blant utviklerne (ibid.). Oppsummering: Jeg har vist at IT-bransjen satser tungt for å utvikle løsninger som får forskjellige datasystemer til å snakke sammen. Kjente løsninger har enkelte begrensninger. Derfor er det knyttet store forventninger til utviklingen av Web Services Definisjoner Vi har sett at det knytter seg store forventninger til Web Services. Spesielt til å løse oppgaven med å få forskjellige datasystemer til å snakke sammen. Men hva er egentlig Web Services? Og hva er webtjenester? Jeg bruker begge uttrykkene i denne rapporten, og jeg legger forskjellig betydning i dem. Alle Web Services er webtjenester, men det er ikke alle webtjenester som er Web Services Min definisjon Med webtjenester mener jeg et dataprogram som tilbyr tjenester til andre dataprogrammer. Det spesielle med denne kommunikasjonen er at den kan foregå usynlig for brukeren av datamaskinen. På denne måten kan mange datamaskiner samarbeide om kompliserte oppgaver, slik at man kan unngå å bygge store systemer på hver enkelt maskin. Hva så med Web Services? For å definere Web Services trenger jeg tre forkortelser. (For en gjennomgang av XML, SOAP og, WSDL, se Protokoller og språk i Web Services.) Jeg velger å definere Web Services som webtjenester som bruker XML som språk, SOAPprotokollen til meldingstjeneste og WSDL til tjenestebeskrivelse (datatyper og meldingstyper som tjenesten godtar, og så videre). Dette ligger nær opp til definisjonen fra standardiseringsorganisasjonen W3C ( World Wide Web Consortium ). 8

9 Definisjonen til standardiseringsorganisasjonen W3C La oss nå se om min definisjon avviker fra definisjonen til W3C (2004). W3Cs definisjon av webtjeneste er: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards (W3C, op.cit.). Jeg skal dele den i fire punkter og forklare hvert punkt: A Web service is a software system designed to support interoperable machineto-machine interaction over a network Her er det to poenger. Det første er maskin-til-maskin kommunikasjon (i motsetning til maskin-til-menneske kommunikasjon). Det andre poenget er at denne kommunikasjonen kan foregå på alle nettverk, og ikke bare på Internett. It has an interface described in a machine-processable format (specifically WSDL) Beskrivelsen av grensesnittet (hvordan man kan kommunisere med webtjenesten) er tilgjengelig i et format som kan leses og tolkes av andre dataprogrammer. Other systems interact with the Web service in a manner prescribed by its description using SOAP messages Meldingene som går fram og tilbake mellom Web Services skal formateres etter reglene i SOAP-protokollen. typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards Vanligvis brukes transportprotokollen HTTP (den samme som man bruker ved surfing på Internett). Data representeres i XML i kombinasjon med andre internettstandarder. Denne gjennomgangen viser at min definisjon av Web Services i all hovedsak samsvarer med definisjonen fra W3C. Den største forskjellen på definisjonene er at definisjonen fra W3C er mer formell og inneholder flere tekniske detaljer enn min Web Services som grensesnitt En modell for kommunikasjon mellom to Web Services er vist i figur 2.1: Figur Oppgavene til protokollene i Web Services Figur 2.1 viser hvordan Web Service 2 kaller (kontakter) Web Service 1, og binder seg til denne. I denne prosessen brukes WSDL. Når dette er gjort, kan de to dataprogrammene begynne å utveksle meldinger. Meldingene er skrevet i språket XML og sendes over protokollen SOAP. 9

10 Så lenge denne standarden blir fulgt, kan Web Services applikasjonene bli implementert på hvilken som helst plattform og med hvilket som helst programmeringsspråk. SOAPprotokollen er i seg selv uavhengig av andre lag i protokollstakken. Den sendes vanligvis over HTTP. Det er likevel mulig å sende SOAP over mange andre protokoller i transportlaget, blant annet FTP (Lim og Wen, 2003) Funksjonalitet og tjenestekvalitet Så langt har jeg sagt at Web Services er dataprogrammer som tilbyr internettbaserte tjenester. Innenfor dette er det store variasjoner. Lublinsky og Farrell jr. (2002) innfører en tredeling av Web Services implementasjonene, se figur 2.2: Figur Web Services implementasjoner (Lublinsky og Farrell jr., 2002) Denne modellen understreker at mange forskjellige implementasjoner kan bygges med Web Services. Det er store variasjoner i hva tjenesten tilbyr. Alt fra å returnere enkel informasjon (som temperaturen på Gardermoen) til kompliserte tjenester (som automatisk oppgradering av lister over lagerbeholdning og priser fra en leverandør). Det kan også være store variasjoner i tjenestekvalitet ( Quality of Service ). Web Services kan for eksempel ha forskjellig kapasitet. Fra å være et eksklusivt tilbud til noen få samarbeidspartnere til å være et åpent tilbud som er i stand til å betjene henvendelser fra et offentlig og internasjonalt publikum. Påliteligheten til Web Services kan også variere. Enkle Web Services kan feile uten at brukeren som venter på tjenesten merker noe annet enn at det ikke kommer informasjon på skjermen. Mer avanserte Web Services har en liste med alternative handlinger som utføres når den forespurte tjenesten feiler. Det sendes en forståelig feilmelding til brukeren som venter på tjenesten. Kapasitet, pålitelighet, logging og sikkerhet kalles med et felles navn for tjenestekvalitet. 10

11 Språk og protokoller i Web Services Jeg har ventet med en grundig forklaring av XML, SOAP og WSDL. Dette følger her. XML - extensible Mark-up Language XML er et dataspråk som har blitt standard for å sende data mellom applikasjoner. Alle grunnleggende data i Web Services utveksles i XML. Hartvigsen (2002) påpeker at XML har mange likheter med HTML. Men der HTML stort sett beskriver formatering av data, kan XML også brukes til å beskrive andre semantiske egenskaper ved dataene (hva dataene betyr). Hartvigsen (2002) bruker som eksempel <b>tekst</b>. I HTML er <b> fast definert til å bety at teksten skal formatteres i fete typer. XML, derimot, er mer fleksibelt, eller extensible, slik at programmereren selv kan definere hva en tag skal bety (tekst mellom haker kalles en tag). Her kan <b> bety alt fra bruksnummer til badetemperatur. Bare fantasien setter grenser. I XML brukes tag ene blant annet til å definere elementer og attributter. Når to datasystemer skal snakke sammen ved hjelp av XML-dokumenter, må dokumentenes oppbygging følge definerte regler. Disse reglene ligger ofte i dokumenter som kalles XML Schemas. XML Schemas kan leses og tolkes av dataprogrammer. Eksempler på XML Schemas følger rapporten som vedlegg B: XSD for bunke fra fagsystem til AltInn og vedlegg C: XSD for Søknad om kompensasjon av merverdiavgift. SOAP Simple Object Access Protocol SOAP er en XML-basert protokoll for å sende meldinger og for å gjøre Remote Procedure Calls i et distribuert miljø (Hartvigsen, 2002). Den definerer meldingsformatet som kan utveksles mellom Web Services. XML-dokumenter pakkes i SOAP-konvolutter. SOAP kan sendes over mange transportprotokoller, men det er mest vanlig å sende SOAP-meldinger over HTTP. En av fordelene med å sende meldinger til eksterne Web Services over HTTP er at trafikken over HTTP vanligvis slipper gjennom brannmurer i mottakerens IT-infrastruktur. En brannmur er programvare som hindrer uønskede programmer å komme inn og lese data i systemene. 11

12 En SOAP-konvolutt med en forespørsel og en SOAP-konvolutt med tilhørende svar er vist i figur 2.3: Figur Eksempler på SOAP-meldinger (Lim og Wen, 2003) Figuren viser en forespørsel til en tjeneste som gir informasjon om Microsoft-aksjer, og et svar som opplyser at prisen er $58. WSDL - Web Service Description Language WSDL er en XML-basert standard for å beskrive Web Services. Det er denne beskrivelsen som gjør det mulig for andre applikasjoner å få tilgang til tjenesten. For å kalle (benytte) en spesifikk webtjeneste må applikasjonen vite hvordan den skal formatere meldinger til tjenesten og hva slags svarmeldinger den kan forvente. Disse opplysningene leser applikasjonen ut av en Web Services beskrivelse som er skrevet etter standarden i WSDL 12

13 (Hartvigsen, 2002). Web Services beskrivelsen for webtjenesten i AltInn følger rapporten som Vedlegg A: Web Services beskrivelse for webtjenesten DataExchange. Strukturen i en Web Services beskrivelse er vist i figur 2.4: Figur Strukturen i en Web Services beskrivelse (Hartvigsen, 2002) Beskrivelsen definerer en eller flere porter som tjenesten tilbys over. En port er en kombinasjon av en tjeneste, en transportprotokoll og en URI som er adressen denne protokollen har tilgang over. Ved å definere flere mulige porter blir det mulig å tilby tilgang til tjenesten fra forskjellige protokoller, og dermed fra forskjellige media (for eksempel PC og mobiltelefon) Bruk av disse begrepene i rapporten Jeg gir min definisjon av webtjenester og Web Services i Min definisjon. Denne ligger til grunn for bruk av disse ordene i den konkrete undersøkelsen av webtjenesten i AltInn. Ettersom denne webtjenesten også oppfyller definisjonen for Web Services kommer jeg vekselvis til å omtale den som webtjeneste og Web Services. En stor del av rapporten handler om funksjonalitet og tjenestekvalitet i AltInn. Begrepene er introdusert i Funksjonalitet og tjenestekvalitet. Navn på protokoller og språk forekommer ofte i rapporten, men de forklares bare en gang, i Språk og protokoller i Web Services Muligheter og begrensninger Så langt har jeg beskrevet hva Web Services er og hva som er bakgrunnen for at det blir satset på ny teknologi for kommunikasjon mellom dataprogrammer. Her vil jeg drøfte teknologiens muligheter. Kan Web Services brukes til å løse aktuelle oppgaver i organisasjoner? Vil prisen bli akseptabel? I tillegg til en drøfting av mulighetene vil jeg også ta opp begrensninger. Web Services er en ny teknologi, og på enkelte områder har den fortsatt ikke tilstrekkelig modenhet. 13

14 Muligheter Jeg skal her referere hva seriøse analytikere skriver om Web Services muligheter. Når det gjelder hvilke oppgaver som denne teknologien kan løse i organisasjoner, legger de størst vekt på at det blir lettere å få datasystemer til å snakke sammen. Kaye (2003) skriver positivt om Web Services og lister opp hvilke utfordringer som kan løses. Web Services: Tillater alle typer datasystemer å kommunisere over nettverk Er skrevet etter åpne standarder Støtter linking opp mot samarbeidspartnere Fremmer e-handel fordi det blir lettere å etablere nye forbindelser Bruker løse koblinger, som gjør det lett å endre en applikasjon som kommuniserer med andre, og lett å koble på nye (se Løse koblinger) Kaye (2003) legger også vekt på at Web Services har nesten ubegrenset skalerbarhet. Det betyr at man alltid kan øke kapasiteten uten å utløse store kostnader. Dette er et viktig framskritt i e-handel. Tradisjonelle Web-applikasjoner som brukes i e-handel er bygget med en fast definert kapasitet. Dette har ført til at stor pågang av nye kunder har vært et problem. Når det blir for stor trafikk på hjemmesidene, virker ikke Web-applikasjonene som de skal. Stor økning i kapasiteten er et prosjekt som krever både tid og penger. En problemstilling som drøftes av Lim og Wen (2003) er at økt datasikkerhet har gjort det vanskeligere å få datasystemer i forskjellige virksomheter til å snakke sammen. Man har ofte behov for at egne datasystemer skal kunne kommunisere med kunder og leverandører. Dette stoppes ofte av brannmurer. En brannmur er programvare som hindrer uønskede programmer å komme inn og lese data i systemene. Den blokkerer samtidig en del vanlige kommunikasjonskanaler mellom vennligsinnede datasystemer. Datakommunikasjon mellom samarbeidspartnere blir nå henvist til noen få protokoller og porter, slik at det blir lettere å stoppe kriminell datakommunikasjon. Den mest aktuelle protokollen er HTTP. Nesten alle brannmurer tillater trafikk over HTTP. En viktig egenskap med Web Services er at de kan overføre data ved bruk av HTTP (ibid.). Lim og Wen (2003) tar også opp de store linjene i programvareindustrien. De diskuterer muligheten for at et gjennombrudd for Web Services kan føre til et brudd med tradisjonell programmeringsteknikk. De legger vekt på at et sånt brudd snart må komme. Tradisjonell (objektorientert) programmering gir ikke støtte til en åpen standard. Dette fører til at en leverandørs system vanskelig kan utveksle data med en annen leverandørs system. Her vil bruk av XML og Web Services kunne gi helt nye muligheter Begrensninger I hvor stor grad kan vi stole på lovordene om Web Services? Her er det mange profeter som taler med store ord, og det er nødvendig med en god porsjon skepsis. Det er viktig å være klar over programvareindustriens rolle. Bransjen vokste kraftig i forbindelse med Y2K (år 2000) utfordringene. Charles Philips, gjengitt i Kaye (2003) anslår en overinvestering på 130 milliarder dollar. De store aktørene i bransjen er nå helt avhengige av å selge nye produkter og framskynde overgang til nye arkitekturer og nye plattformer. Web Services står sentralt i 14

15 markedsføringen til blant andre IBM, Sun og Microsoft. Fristelsen til å love for mye på teknologiens vegne er sterk. Web Services modenhet blir flittig debattert. Pollock (2001, 2002) knytter sin skepsis til ordene semantikk og syntaks. Semantikk betyr læren om betydning. Innen programmering har dette relevans for navngiving av objekter, attributter, felt og andre dataelementer. Spørsmålet er hvordan et system skal kunne tolke navnene på objekter og så videre, som brukes av et annet system. Syntaks betyr læren om setningsbygging. Innenfor IT brukes ordet om oppbyggingen av dokumenter og filer. Pollock (2002) hevder at det må gjøres et stort arbeid med en standardisert semantikk før det er noe poeng å få datasystemer til å snakke sammen ved hjelp av Web Services. Web Services er en god integrasjonsteknologi, men det som er forutsetningen for samhandling mellom datasystemer er at systemene er i stand til å tolke og forstå de meldingene de utveksler (ibid.). Lim og Wen (2003) mener de viktigste uløste problemene rundt Web Services er knyttet til sikkerheten. Det mangler standarder for flere sentrale sikkerhetsoppgaver. Dette er blant annet: Autentisering, som betyr at webtjenesten krever legitimasjon av brukeren for å gi tilgang Autorisering, som betyr at webtjenesten tildeler brukeren de rettighetene som har blitt avtalt Kryptering, som betyr at dataene som utveksles sendes i kode Ikke-benekting ( Non-repudiation ), som betyr at webtjenesten har mekanismer som nekter brukeren å angre tidligere innsendt melding (for eksempel en ordre) De trekker også fram kontraktspørsmål som et annet eksempel på manglende modenhet. Videre holder de fram flere områder hvor det er usikkert om Web Services løsninger vil bli for dyre. Dette gjelder katalogtjenester og integrasjon av datakilder i databaser. Web Services kan også løse disse oppgavene, men prisen blir ikke akseptabel. Flere analytikerne tar forbehold når det gjelder Web Services modenhet. Kaye (2003) hevder at 12 biter ennå ikke har kommet på plass. De viktigste er: Semantikk for forretningstransaksjoner. Web Services kommuniserer ved hjelp av XML, men det er gjort lite arbeid for å komme fram til ordlister som kan gi denne kommunikasjonen mening. Sikkerhet. Det er stor framgang på området, men fortsatt mangler det standarder for en del oppgaver innenfor autentisering, kryptering og ikke-benekting ( nonrepudiation ). Transaksjonsintegritet. Komplekse transaksjoner vil ofte involvere mange forskjellige systemer. Det mangler standarder for å håndtere gjensidig avhengighet mellom deltransaksjoner. 15

16 Oppsummering Web Services er et godt verktøy for få datasystemer til å snakke sammen. Løsningen for å kommunisere på tvers av virksomheter (og brannmurer) er god. Men midt i all markedsføringsstøy og opphausing fra leverandørene er det viktig å hold hodet kaldt. Løsninger for integrasjon og samhandling er dyre. Det finnes ingen billige løsninger. All avansert integrasjon forutsetter at det gjøres en ressurskrevende jobb med å utvikle en avtalt og standardisert semantikk. Web Services er heller ikke en moden teknologi. Skal man ta den i bruk nå, må man være forberedt på å lage midlertidige løsninger i påvente av at viktige standarder kommer på plass Tanker om bruk av Web Services Målet er altså et felles grensesnitt som gjør alle system i stand til å snakke med hverandre. Kaye (2003) har tro på Web Services potensial. Kraften i Web Services er ifølge Kaye (2003) knyttet til: Omstilling til en tjenesteorientert arkitektur Valg av Document Style messaging Asynkron meldingstjeneste til erstatning for synkron Delayed Binding Integrasjon basert på løse koblinger Jeg vil her forklare og drøfte disse fenomenene Tjenesteorientert arkitektur Arkitektur påtvinger systematikk, standarder og orden. Her vil jeg drøfte forskjellen mellom tjenesteorientert og objektorientert arkitektur. Vil innføring av en tjenesteorientert arkitektur gjøre det lettere for ulike systemer å utveksle informasjon og arbeide sammen? Barry (2002) definerer tjenesteorientert arkitektur som en samling av tjenester som kommuniserer med hverandre. Kommunikasjonen kan være alt fra enkel dataintegrasjon til at flere tjenester utfører koordinerte handlinger (ibid). Fordelen med en tjenesteorientert arkitektur er at den fremmer samarbeid og gjenbruk. Dersom en samarbeidspartner har utviklet velfungerende tjenester, kan man bruke den, i stedet for å utvikle all funksjonalitet i eget hus. Både tjenesteorientert arkitektur og objektorientert arkitektur hevdes å støtte samhandling mellom datasystemer. Lublinsky og Farrell jr. (2002) drøfter forskjellen. I en objektorientert arkitektur består kommunikasjonen i at datasystemene utveksler objekter. Et objekt er en komponent i et dataprogram som inneholder dataelementer og attributter. Datasystemer som utveksler objekter er avhengige av å motta riktige objekter. De blir derfor avhengige av hverandre. En tjenesteorientert arkitektur bygger derimot på et nettverk av uavhengige tjenester. En av styrkene til en tjenesteorientert arkitektur er at den krever langt mindre nettverkstrafikk enn en tradisjonell objektorientert arkitektur (ibid). Grunnen til det er data og 16

17 prosedyrekall, som utveksles i en tjenesteorientert arkitektur krever mye mindre plass enn utveksling av objekter. Web Services representerer et gjennombrudd for tjenesteorientert arkitektur. De gode egenskapene illustreres i samhandlingsmodellen, som er vist i figur 2.5: Figur Samhandlingsmodellen i Web Services Tjenestetilbyder er systemet der webtjenesten er lokalisert Opplysningskontoret er en tjeneste med en kjent adresse. Den tilbyr en katalog med informasjon om andre webtjenester. Tjenestesøker er systemet som har behov for å oppdage og utnytte en eller flere webtjenester 17

18 Hvordan er så samhandlingen mellom tjenestetilbyderen og tjenestesøkeren? Kaye (2003) skriver at samhandlingen skjer gjennom utveksling av meldinger. Web Services kan kombinere utveksling av meldinger på svært mange måter. De mest kjente kombinasjonene kalles Message Exchange Patterns (MEPs) (ibid.). Eksempler på MEPs er: Forespørsel/svar ( Request/Response ). Dette er det enkleste mønsteret. Tjenestesøkeren sender en forespørsel, og får svar på denne. Svaret kan komme med en gang, synkront, eller det kan være nødvendig for tjenestetilbyderen å bruke tid på å prosessere svaret. I så fall utføres mønsteret asynkront, slik at tjenestesøkeren konfigureres til å ta imot svaret, uansett når det måtte komme. Abonnement. Tjenestesøkeren sender en forespørsel med bestilling av abonnement. Tjenestetilbyderen publiserer informasjon til abonnentene hver gang det er noe nytt å melde. Kringkasting. Tjenestetilbyderen sender uoppfordret en melding til alle enheter på et definert nettverk. Konklusjon: Her har jeg vist at det er gunstig å bygge en tjenesteorientert arkitektur fordi den gjør det mulig for uavhengige tjenester å samarbeide. Det fører også til en reduksjon i trafikken på nettverkene. Ved å bruke Web Services og MEPs kan man bygge en effektiv tjenesteorientert arkitektur Meldingsstiler Her vil jeg gi en kort presentasjon av de to meldingsstilene som brukes i Web Services. Jeg refererer også argumentene for å velge Document Style Kaye (2003) forklarer utviklingen fra RPC Style til Document Style som en naturlig evolusjon. RPC ( Remote Procedure Calls ) vant utbredelse når Web Services var nytt, fordi man først oppdaget at Web Services var egnet til å kalle prosedyrer og metoder på andre system. Etter hvert som bruksområdet øker, blir det naturlig å gå over til Document Style. En melding i Document Style inneholder ett eller flere XML-dokumenter, eventuelt i tillegg til prosedyrekall. Fordelene med dette er støtte til mer komplisert kommunikasjon mellom system, støtte for mer grovkornet struktur i meldingene og at denne stilen innbyr til å innfri andre krav til løse koblinger (ibid). Spørsmålet om meldingsstiler tangerer også konflikten Microsoft versus Sun. En gjennomgang av publiserte webtjenester på hjemmesida til xmethods viser et klart mønster. De som er skrevet i Microsoft.NET bruker Document Style og de som er implementert i andre plattformer bruker RPC (Kaye, 2003). Jeg tolker Kayes argumentasjon på dette området til å være identisk med Microsoft sin. Jeg har ikke funnet nyere artikler som drøfter meldingsstiler fra den motsatte synsvinkelen Asynkron meldingstjeneste Her vil jeg vise at de første Web Services bare kunne støtte kortvarig utveksling av data eller kommandoer over en aktiv forbindelse. Dette ga etter hvert en begrensning i bruksområdene. Man kunne ikke kommunisere med komplekse tjenester, fordi det ville ført til at store deler av systemets ressurser ble blokkert mens man ventet på svar. Det har derfor blitt nødvendig å 18

19 utvikle kommunikasjonsformer der to systemer jobber hver for seg og tar kontakt med hverandre når de har ferdige data å tilby den andre. Dette kalles asynkron meldingstjeneste. De første implementasjonene av Web Services utvekslet meldinger synkront. Kaye (2003) forklarer at kjennetegnet ved synkron meldingstjeneste er at tjenesten som sender en forespørsel forventer et svar, og venter på svaret. Tjenesten som venter på svaret kan ikke gjøre noe annet i mellomtida. Så hvis svaret ikke kommer fram, låser tjenesten seg. Derfor er forutsetningen for god tjenestekvalitet på synkron meldingstjeneste at alle berørte nettverk kan levere 100 % tjenestekvalitet 24/7 (24 timer 7 dager i uka). Dette er uoppnåelig, spesielt fordi det er umulig å forutse hvor mange applikasjoner som vil kalle en webtjeneste i korte trafikktopper. Derfor kan ikke synkron meldingstjeneste oppfylle de mest vidtgående visjonene for en tjenesteorientert arkitektur, som presenteres av Gabriel (2002), Jones (2002) og Kaye (2003). Løsningen på dette kan være å benytte asynkron meldingstjeneste. Adams (2002) beskriver et typisk asynkront scenario: En tjenestesøker produserer og sender en forespørsel En tjenestetilbyder leser og tolker forespørselen Forbindelsen brytes Tjenestetilbyderen produserer et svar når den får ledig kapasitet Tjenestetilbyderen åpner en ny forbindelse og sender svaret Tjenestesøkeren leser og tolker svaret Figur 2.6 viser det spesielle i et asynkront scenario: Figur Web Services med asynkron kommunikasjon I asynkron meldingstjeneste forventer tjenestesøkeren et svar, men uten å vente på det. Tjenestesøkeren er ledig til å løse andre oppgaver i mellomtida. Den er forberedt på å lese og tolke svaret på et hvilket som helst seinere tidspunkt (Kaye, 2003). Dette forutsetter at tjenestesøkeren er tilgjengelig på nettverket når svaret kommer, så bruk av asynkrone meldingstjenester er mest aktuelt på systemer som kjører hele døgnet. Ved å utvikle løsninger med asynkron meldingstjeneste blir det mulig med en nesten ubegrenset skalerbarhet i en webtjeneste. En sterkt trafikkert tjeneste kan utnytte hele driftsdøgnet, og betjene alle forespørsler når den ikke er avhengig av å gi umiddelbare svar. Asynkron meldingstjeneste kan også gjøre det mulig å etablere komplekse samhandlinger 19

20 mellom mange webtjenester. Dersom en nødvendig tjeneste faller ut for en periode, kan forespørselen bli repetert helt til tjenesten er oppe og går igjen. Bare dersom man passerer en definert tidsfrist, sendes det en feilmelding tilbake til systemet som sendte den opprinnelige forespørselen. Jeg velger å ta noen forbehold med hensyn til hva som er mulig å få til av asynkron meldingstjeneste. Når dette skrives støtter ikke standarder og spesifikasjoner for Web Services asynkron meldingstjeneste direkte (Adams, 2002). Men de inneholder mekanismer og infrastruktur som gjør det mulig å lage en asynkron meldingstjeneste. Adams (2002) understreker at bruk av asynkron meldingstjeneste reiser mange nye spørsmål i forhold til synkron meldingstjeneste. Dette er blant annet: Å definere en korrelator og en mekanisme for å utveksle den. En korrelator er et verktøy for kobling av meldinger med gjensidig avhengighet Å definere en adresse som tjenestetilbyderen skal sende svaret til, og forsikre seg om at tilbyderen kjenner denne adressen. Å generere et frittstående svar i tjenestetilbyderen Mottaket av et asynkront svar hos tjenestesøkeren Å finne en mekanisme som kobler svaret til forespørselen hos både tjenestesøkeren og tjenestetilbyderen I Web Services er det ifølge Kaye (2003) følgende alternativer for korrelasjon: Uavhengige meldinger, som hver for seg inneholder all informasjon som er nødvendig for å forstå den Kobling ved hjelp av transportlaget. Et eksempel er bruk av HTTP-protokollens støtte for å linke en request-melding med en response-melding. Kobling ved hjelp av innholdet i meldingene. Brukes i komplekse MEPs, der mange meldinger inngår i en avhengighetskjede. Message routing er at annet viktig skille mellom synkron og asynkron meldingstjeneste. Ved synkrone operasjoner som involverer mange webtjenester må hver og en sende et svar til klienten, som så må generere en ny forespørsel til neste webtjeneste, se figur 2.7: 20