Trykket i Nettverk & Kommunikasjon nr.8/2002
(c) Anders Fongen 2002
Anders Fongen er høgskolelektor og fagsjef ved Norges Informasjonsteknologiske Høgskole og skriver sin doktoravhandling innenfor feltet distribuerte systemer. Web-stedet hans er på www.fongen.no
Web Services høres tilforlatelig enkelt ut: Web-applikasjoner for maskiner, ikke mennesker. Det betyr at det er to maskiner som snakker sammen, én klient og én tjener. Klienten erstatter den menneskelige brukeren som betjener en nettleser. Klienten kan heller være et innkjøpssystem i en kundebedrift som på denne måten henvender seg til mange leverandører for å sammenligne priser, og deretter bestille varen der den er billigst.
HTML-koder
har ingen interesse i en slik sammenheng, fordi HTML beskriver utseendet av en webside, men beskriver
ikke hva slags informasjon den
inneholder. Informasjonen som overføres må derfor kodes med et annet system, og
XML er valgt for bruk i Web Services. XML ligner på HTML i sin bruk av tagger,
men beskriver innhold og struktur av informasjonen, ikke
utseendet.
Tjeneren som tilbyr Web Services kan være en helt alminnelig web-tjener, og de vanlige programmeringsverktøyene for å lage web-applikasjoner (Active Server Pages, PHP, Servlets m.m.) kan brukes for å lage Web Services. Fordelene med en slik tilnærming er at ressursene som trengs for å lage Web Services allerede er tilgjengelige i en web-tjener, f.eks. forbindelser til de nødvendige databaser. Dersom forretningslogikken for f.eks. varekjøp er etablert og utprøvet i forbindelse med web-applikasjoner, kan en Web Service for varekjøp være snakk om bare å lage et nytt "skall" rundt denne logikken.
Om vi på
denne måten ser Web Services som en maskin-maskin variant av
menneske-maskin-orienterte web-applikasjoner, så blir det ikke veldig
vanskelig. Forskjellene er i hovedsak at formatet på de utvekslede meldingene
må bruke et egnet kodesystem (XML). Slike applikasjoner er preget av egenskaper
som:
Det er derimot mange anvendelser som krever noe mer enn de tre punktene ovenfor. I en vanlig web-applikasjon i forbindelse med varekjøp er det f.eks. vanlig at du starter besøket med å identifisere deg med brukernavn og passord, og deretter går rundt i butikken med en handlekurv. Begge disse forholdene er eksempler på applikasjoner med behov for objekter inne i tjeneren som representerer dette bestemte kundebesøket. En annen kunde skal selvfølgelig ha sin egen handlekurv, og i morgen må samme kunde skrive sitt brukernavn og passord på nytt.
Tilsvarende vil Web Services måtte tilby at en "økt" (eng. session) er representert ved en samling objekter inne i tjeneren, og i likhet med web-applikasjoner oppstår det da tre nye behov:
Når kan tjeneren fjerne objektene? Når klienten uttykkelig sier "slutt" eller "logg av", men også i de tilfellene der klienten ikke har latt høre fra seg på lenge og trolig har avsluttet programmet uriktig (f.eks. krasjet). En vanlig web-applikasjon vil sørge for objektreferanser gjennom cookies, og fjerning av objekter basert på en tidsgrense for inaktivitet.
Denne problemstillingen antyder at Web Services handler om mer enn å sende XML-dokumenter mellom klient og tjener. Som vist i dette eksemplet handler det også om å administrere livssyklusen til tjenerobjektene. I eksisterende arkitekturer for fjernobjekter (CORBA, RMI) er nettverksprotokollene utformet med tanke på å tilby livssykluskontroll i tillegg til metodekall. I WebServices derimot, som benytter HTTP-protokoll egentlig utviklet for et helt annet formål, er livssykluskontroll enten tungvint eller ressurkrevende avhengig av hvilke strategier man velger. Overraskende er det at protokollen som beskriver meldingsformatet (SOAP) ikke har noen innretninger for livssykluskontroll, og har relativt vage regler for hvordan objektreferanser skal overføres mellom partene.
I sin enkle form er Web Services (i likhet med andre tjenester med fjernobjekter) basert på en overenskomst mellom partene: De er på forhånd blitt enige om hva tjenesten skal hete, hvilke objekter som skal brukes, og hvilke metoder som skal brukes på objektene for å få benyttet tjenestene. Og dessuten er de enige om betingelsene for denne kontakten, dvs. hvilke juridiske og forretningsmessige vilkår som knytter seg til den.
Dette er betryggende, men tungvint dersom man skifter partnere ofte. Derfor kan det være interessant å la Web Services registrere seg i en katalog. En katalogtjeneste for Web Services kalles UDDI (Universal Description, Discovery and Integration). I en UDDI-katalog kan en bedrift registrere seg som tjenesteyter, og dessuten registrere seg med opplysninger om hver enkelt tjeneste som tilbys.
UDDI blir som både gule og hvite sider: En klient kan slå opp på identifikatoren til tjenestetilbyderen og få vite hvor og hvordan tjenesten kan brukes (hvite sider), ellers kan klienten søke på bransjer eller geografiske områder etter en egnet tilbyder som man ikke kjenner navnet på (gule sider).
UDDI kan muligens også gi opplysninger om de syntaktiske kravene knyttet til en tjeneste, dvs. hvilke parametre som skal brukes og hvilke datatyper de skal da. Det som derimot er vanskelig med en katalogtjeneste er å beskrive hva tjenesten egnetlig tilbyr og hvordan den skal brukes. Om du ber om en pris, er det inkludert frakt og moms? Er et lån oppgitt med effektiv eller nominell rente?
Til tross for UDDI, tror vi fast på at det forsatt vil være behov for en kontrakt mellom partene i bruk av Web Services, og det skjer i form av grensesnittbeskrivelser skrevet i et IDL (Interface Definition Language). Dette er vi vant til å gjøre fra andre systemer for fjernobjekter, f.eks. CORBA. I tilfellet med Web Services skjer grensesnittbeskrivelsen med spesifikasjonsspråk som kalles WSDL (Web Services Definition Language).
Ved å beskrive en tjeneste i et dokument skrevet i WDSL-format kan klienten (enten i utviklingsfasen eller i kjørefasen) tilpasse sine metodekall slik at de passer til tjenerens opplegg, dvs. bruke riktig metodenavn og riktige parametertyper. Det er altså på basis av WSDL-deklarasjonene at mappingen mellom metode-/prosedyrekall i det brukte programmeringsspråket og SOAP-meldingene finner sted. Det bør være mulig at klient og tjener er programmert i forskjellige programmeringsspråk og kan bruke ulik mellomvare.
Problemstillingene knyttet til UDDI og WSDL er dessuten i hovedsak kjent fra tidligere systemer, hvor vi kaller denne tjenesten for en "Trader". I en trader registreres tjenestene i henhold til et klassehierarki, og klienten tillates å søke etter tilbydere av en ønsket tjeneste.
Programmet vårt kunne gjerne skrevet og lest XML-filene selv og sendt den mellom partene i en transaksjon. Når vi ønsker å unngå dette er det pga. et prinsipp om usynlighet, distribuert programmering skal være mest mulig lik lokal programmering. Et metodekall på et tjenerobjekt skal se ut som et metodekall på et lokalt objekt.
Den programvaren som tilbyr en slik abstraksjon kalles mellomvaren. En av oppgavene til mellomvaren vil være å lese en WSDL-beskrivelse og lage en bindeledd (kalt "stub") mellom SOAP-protokollen (som overfører XML-meldinger) og programmeringsspråkets metodekall.
Oppgaven med å lage et bindeledd er ikke entydig, slik at et metodekall kan beskrives på forskjellige måter i XML-formatet. Og her har vi et mulig problem: Dersom klient og tjener har ulik "forståelse" av hvordan XML-formatet skal se ut, så klarer de ikke å snakke sammen. Mer om det i neste avsnitt.
Og det er i mellomvaren at en leverandør kan legge egenskaper som gjør at det er vanskelig å skifte fra en leverandør til en annen, eller å bruke mer enn én leverandør. Leverandører har et tvetydlig forhold til standarder, på den ene side trekker de ikke til seg nye kunder uten åpenhet og forpliktelser overfor standarder, men ønsker også å konkurrere ved å ha flere finesser enn andre.
Hvordan ulike mellomvareprodukter forholder seg til hverandre finner vi best ut gjennom et eksperiment. Det eksperimentet som vi nå referer til (http://www.xml.com/pub/a/2002/01/30/soap.html) forsøker på enklest mulig måte å lage en tjener og en klient som kun utveksler to tegnstrenger (et "HelloWorld"-eksempel). Tre versjoner av programmene ble laget, i .NET, i Java og i Perl. Alle kombinasjoner av tjener- og klientprogram ble testet.
Ikke overraskende kan en tjener skrevet i Java snakke med en Java-klient. Det samme gjelder for de to andre programmeringsspråkene. Det er når vi bruker forskjellige programmeringsspråk (som også bruker ulik mellomvare) at det oppstår problemer. Perl-klienten kunne ikke snakke til .NET-tjeneren, fordi de var uenige om noen detaljer i XML-syntaksen (ikke knyttet til parameteroverføringen).
Web Services baserer seg på enklere og mer "gjennomsiktig" teknologi enn sine forgjengere. For enklere applikasjoner, dem som ligner på tradisjonelle web-applikasjoner, er dette trolig en fordel. For applikasjoner som ligner på tradisjonelle CORBA-applikasjoner og som ser på tjeneren som en samling objekter, vil Web Services derimot være for vagt definert og kunne skape problemer på tvers av leverandørgrenser.
www.webservices.org - Ressurssenter for spesifikasjoner og nyheter
www.w3c.org - Standardorganet for SOAP-protokollen, WSDL m.m.
UDDI blir som både gule og hvite sider
SOAP mangler livssykluskontroll
Web Services er maskin-maskin tjenester