Hva er en Webservice(WS)?
En Webservice (WS) er en del av en tjeneste eller system som tilbyr lese- og/eller skrivetilgang til tjenesten eller systemet vha. webbasert teknologi. En WS kan v?re en integrert del av tjenesten (heretter vil "tjeneste" dekke b?de system og tjeneste), en modul til tjenesten eller en l?srevet komponent som har et eget livsl?p. Felles for alle variasjoner er at de gir et standardisert grensesnitt til ? lese og/eller skrive data som ligger i tjenesten.
En WS tilbyr ett eller flere API-er som tilbyr funksjoner opp mot tjenesten. Funksjonene kan v?re n?rmest hva som helst, men som regel er de av typen "hent data fra kilden".
Hva er hensikten?
Dagens situasjon
Hensikten med ? g? over p? en WS-basert integrasjonsarkitektur er prim?rt ? kvitte seg med flaskehalser i organisasjonen, samt forhindre dobbeltarbeid. Mange av UiOs integrasjoner er basert p? en s?kalt "hub&spoke"-modell der datakilden er ansvarlig for ? levere fra seg de data som en konsument trenger. ?rsakene til at dette har blitt en s? vanlig modell for integrasjon er mange, der de viktigste er:
- sikkerhet - kun de ansvarlige for kilden skal f? tilgang til dataene i kilden
- kompleksitet - kun de ansvarlige for kilden forst?r datamodellen i kilden
- sentralisering - som en f?lge av sentralisering av data s? blir integrasjonene ogs? sentraliserte
- tradisjon - slik at man "alltid" gjort integrasjon
Det er store utfordringer knyttet til en slik "hub&spoke"-modell. Sentralisering av data er et veldig fornuftig valg for ? bekjempe d?rlig datakvalitet og sikre en autoritativ kilde som konsumenter kan forholde seg til. Sentralisering av integrasjonene nyter ikke de samme godene:
- De tekniske ressursene tilknyttet kilden blir bundet opp i enkeltprosjekter, andre prosjekter m? vente.
- En endring ute i en konsument medf?rer at ressurser m? endre p? kilden.
- Kilden m? alltid ha mange tekniske ressurser tilknyttet for ? klare arbeidsmengden.
- Prosjekter f?r store skjulte kostnader fordi ressurser i kilden m? gj?re integrasjonen.
- Prosjekter blir forsinket da det sjelden er nok tekniske ressurser tilknyttet kilden og ingen andre enn disse ressursene kan gj?re integrasjonen.
En WS-basert modell
To av problemene som har medf?rt at "hub&spoke"-modellen har blitt s? utbredt er sikkerhet og kompleksitet. Uten grensesnitt som adresserer disse problemene s? vil det v?re vanskelig ? gj?re en omfattende endring i hvordan UiO gj?r integrasjon. Sikkerhetsproblemet best?r i hovedsak at systemeiere ikke vil tillate andre tilganger rett i databaser eller til API-er inne i tjenesten. Det er lite eller ingen tilgangskontroll s? skal noen ha tilgang til noe s? f?r de det til alt - gjerne ogs? muligheten til ? endre data.
Kompleksitetsproblemene er ofte at internt i en tjeneste s? er data strukturert p? en slik m?te at de gir mening for systemeiere og ressurser tilknyttet tjenesten, men ikke utenforst?ende. S? selv om man gir tilgang til en kilde s? betyr ikke det at konsumenten skj?nner hva kilden tilbyr eller f?r gale data.
Dette kan l?ses som en del av WS-modellen:
Hvordan API-et utformes i WS-en vil adressere kompleksitetsproblemene som nevnt. Hvis konsumenter trenger ? finne alle kontoer p? UiO s? kan API-et tilby en vasket liste der alle aktive konti som oppfyller kravene vises. Interne data, som ikke er interessante for andre enn systemeier, vises ikke.
Systemeier for kilden og de tekniske ressursene tilknyttet kilden vil v?re ansvarlige for ? tilby et API som gir konsumenter de data som konsumentene trenger. I oppstart av WS-basert integrasjon vil kostnaden knyttet til integrasjon v?re likt med tidligere m?ter ? integrere p?. Det er n?r WS-en allerede tilbyr et rikt API at systemeier vil se gevinsten i mindre behov for ? bruke ressurser p? integrasjon – prosjektene vil selv kunne skaffe data gjennom WS-en. Prosjektene kan budsjettere med tid og ressurser for integrasjon uten at kilden er en flaskehals.
API manager
En API manager, ogs? kalt API gateway, er en tjeneste for ? kontrollere og styre tilganger til API-er. Tjenesten sikrer at konsumenter er de de utgir seg for ? v?re (autentisering) og holder rede p? de tilganger konsumentene skal ha (autorisasjon).
Ved ? sentralisere tilgangsstyringen av API-er s? h?ster vi en rekke fordeler:
- Ett sentralt punkt for tilgangsstyring
- bestilling av flere tilganger i flere API-er kun ett sted
- forvaltning av tilganger i flere kilder kun ett sted
- Sentral oversikt over dataflyt
- bedre sikkerhet
- oversikt over hele virksomheten
- Ett punkt for integrasjon
- konsumenter m? ikke lete etter ulike API-er
- konsumenter kan integrere en gang, ulike kilder gir tilgang
Meldingsk? (MQ)
En meldingsk? (MQ) er en tjeneste som gir kilder mulighet til ? sende beskjed om at data er endret. I gamle hub & spoke-integrasjoner baserer man seg i stor grad p? fulldumper – alts? filer med alle data en konsument trenger. Dette er kostbart, s?rbart og tregt. Med en meldingsk? er tanken at en kilde sender ut en notifikasjon n?r data har endret seg, som er av interesse for konsumenter. Notifikasjonen er ikke n?dvendigvis informasjonsb?rende nok til at konsumenten kan foreta en endring, men forteller konsumenten at den m? hente data p? nytt for ? sjekke egne data mot den autoritative kilden. Dette gj?res med en URL til den ber?rte enheten.
Notifikasjoner skal ikke inneholde utfyllende informasjon fordi man ?nsker liberale regler rundt abonnement p? notifikasjoner. Flyter f?dselsnummer eller sensitiv informasjon i notifikasjoner s? m? tilgangskontrollen p? notifikasjoner v?re strengt regulert. Er notifikasjonene kun en indikator p? at noe har skjedd med en enhet s? vil tilgangskontrollen kunne gj?res ene og alene mot WS-en.
MQ, som beskrevet i arkitekturen og i dette dokumentet, er en sentral tjeneste. Andre meldingsk?er kan eksistere i virksomheten uten at de faller inn under arkitekturen. Sammenhengen mellom API manager, WS og MQ forklares lenger ned i dokumentet.
Hvem m? ha en WS?
Det er ikke slik at alle tjenester m? ha en WS i den nye integrasjonsarkitekturen. Kravet om WS inntreffer hovedsaklig n?r en kilde sitter p? data som andre tjenester vil lese og eller skrive. Har kilden sv?rt f? integrasjoner og dette ikke vil ?ke i fremtiden s? vil integrasjonsarkitekturprinsippene heller ikke kreve en WS foran kilden. Det gir for lite avkastning p? investeringen.
WS vil v?re enten p?krev eller sv?rt nyttig der tjenesten er en autoritativ kilde for data som andre trenger innsyn i, eller der tjenesten fungerer som en del av en annen tjeneste.
Autoritativ kilde
Mange av integrasjonene p? UiO kommer av at tjenester trenger noe data fra en autoritativ kilde. Eksempler er lister av alle personer, konti eller grupper. Hva disse dataene brukes til videre er forskjellig, men likhetstrekkene for selve integrasjonen er s? markant at man f?r store fordeler av ? modernisere og standardisere prosessen.
En tenkt flyt i modellen over er:
- Kilde sender notifikasjon med innhold "person 123 er endret" til MQ som f?lge av at et telefonnummer er endret.
- MQ videresender notifikasjonen til de konsumenter som abonnerer p? denne typen notifikasjoner fra kilden.
- Konsumenten f?r beskjed om at person 123 har en ukjent endring.
- Konsumenten kontakter API manager, som styrer tilgangen til WS-en til kilden, for ? sp?rre om personobjektet 123.
- Alle kall til API manager, og som er forh?ndsgodkjent, videresendes til WS-en.
- WS-en returnerer personobjektet 123, med det oppdaterte telefonnummeret.
- Konsumenten sammenligner nye og gamle data og oppdaterer telefonnummeret.
Datalager
Integrasjoner er ikke alltid det ? flytte data fra A til B, alts? replisering av data. Sammensatte tjenester der man utnytter en tjenesteorientert arkitektur vil kunne bygge p? andre tjenester. Et eksempel p? dette kan v?re at en tjeneste velger ? integrere med en kilde med den hensikt ? benytte kilden som en del av sitt datalager. Tjenesten kunne integrert som over og replisert data om f.eks. personer, grupper eller kalenderdata, men man kan ogs? g? direkte til kilden (bokstavelig talt) og jobbe direkte p? kildedataene.
I et slikt scenario s? kan det v?re krav til WS-en i kilden om ? tilby skrivemuligheter. Man kan se for seg at personpresentasjonen p? UiOs nettsider vil v?re redigerbare for personer som er innlogget og disse dataene b?de hentes fra UiOs HR-system, samt blir skrevet tilbake hvis personen redigerer dem i presentasjonssidene. Dette gir strengere krav til oppetid og skalerbarhet i kilden og dens WS, men gevinsten er at selve tjenesten blir mindre og mindre kostbar – man oppdaterer kildedata direkte uten mellomlagring og ekstra kompleksitet dette medf?rer.
Hvordan skal et API i en WS se ut?
RESTful
REST er en metodikk for ? sikre l?se koblinger mellom to tjenester i en integrasjon. Begrepet misbrukes ofte om integrasjoner som benytter HTTP som den underliggende protokollen for integrasjonen, men REST er ikke begrenset til HTTP og m? ikke bygges over HTTP. For ? sikre at man ikke videref?rer gamle, tett koblede integrasjoner i den nye integrasjonsarkitekturen, b?r tjenesteeiere og -utviklere etterstrebe ? lage grensesnitt som er s? RESTful som mulig.
S? hva er RESTful? Det kan deles inn i fire niv?er, der det er opp til tjenesteeier og -utvikler ? bestemme hvor RESTful API-et skal v?re. Anbefalt minimumsniv? er niv? 2.
Niv? 0: RPC over HTTP
P? dette niv?et ligger REST API-er som ikke egentlig er REST. Man har implementert typiske RPC-kall over HTTP og kaller dette REST. Det resulterende API-et blir spesialisert og lite gjenbrukbart. Typisk fors?ker man ? tilby funksjonalitet i API-et tatt helt bokstavlig fra en bestilling. ?nsker konsument en ? hente fornavn p? en person s? lager man en funksjon for dette. Konsument to ?nsker hele navnet s? da lager man en ny funksjon. Konsument tre ?nsker en liste med alle navnetyper, samt muligheten til ? oppdatere navn s? da lages det flere funksjoner for alt dette. Man ender opp med tette koblinger og lite til ingen gjenbruk.
Niv? 1: Ressurser
P? niv? 1 begynner man ? omfavne RESTful. Isteden for spesialiserte kall for enhver handling som omhandler en ressurs eller entitet s? samler man disse i en felles ressurs. I eksemplet med navn p? en person fra niv? 0 s? samler man navn under persons/mathiasm/names. Under dette omr?det samler man de funksjoner som omhandler navn. Dette er en bedre l?sning enn i niv? 0, men fortsatt utsatt for spesialiserte funksjoner og manglende gjenbruk. Det oppfordrer dog til en ressursdrevet (datadrevet) modell der ressurser i form av data bestemmer mer av strukturen p? API-et heller enn en mer tilfeldig modell basert p? hvem som spurte om hva n?r.
Niv? 2: HTTP verb
P? dette niv?et har API-et modnet betraktelig. Om man implementerer et niv? 2 API s? er ikke API-et fullt ut RESTful, men det er likevel av en slik kvalitet at det oppfyller kravene fra integrasjonsarkitekturen. Det vil v?re modul?rt, datadrevet og gjenbrukbart. Som de tidligere eksemplene med personnavn s? vil HTTP-verbet bestemme operasjonen man gj?r p? navn. GET persons/mathiasm/names vil gi en liste URL-er med de navn som er registrert for personen 'mathiasm'. GET p? en av disse vil gi denne typen navn. En endring eller sletting gj?res med HTTP-verbene DELETE, POST eller PUT. Behovet for spesialiserte funksjoner blir minimalt da dataene selv representeres som ressurser og man kan lese og skrive til disse ressursene.
Niv? 3: Hypermedia Controls/HATEOAS
For et ekte RESTful API s? skal API-et i WS-en v?re den kontrollerende akt?ren i integrasjonen. Dette vil si at i eksemplet med navn s? vil utseendet p? API-et endre seg i forhold til kontekst. For konsument 1, som kun skal hente fornavn p? personer, s? viser API-et kun dette. For konsument 3, som ?nsker alle navnetyper, samt mulighet til ? oppdatere navn, s? vil kallet som returnerer listen ogs? inkludere lenker til hvordan konsumenten kan oppdatere navn. For de navn som ikke finnes vil det bli sendt med lenker til hvor konsumenten kan opprette disse navnene. API-et gir fra seg informasjon om tilstanden p? data og tilgangene konsumenten har til data. Dette gir navn til det velklingende akronymet HATEOAS (Hypertext As The Engine Of Application State).
? implementere et ekte RESTful API er ressurskrevende. Det er uklart om steget fra niv? 2 til 3 er verdt den ekstra innsatsen.
Entitetsbasert API
Entitet- eller ressursbasert, som nevnt under niv? 1 under RESTful, handler om ? bevege seg bort fra operasjonen man skal gj?re og heller se p? data man skal gj?re noe med. Mange uttrekk og funksjoner i dag er resultatet av at man skal gj?re noe bestemt. Konsumenter trenger sammensatte uttrekk fra konsumenter og skal ikke ha for mye eller for lite data. Dataene skal formateres p? bestemte m?ter og sv?rt sjeldent kan to ulike konsumenter benytte de samme uttrekkene.
? si at API-er skal v?re entitetsbaserte (evt. ressursbaserte) vil si at man heller eksponerer typiske entiteter fra kilden heller enn ferdige uttrekk. Om en konsument trenger informasjon om ansatte og deres organisasjonstilh?righet s? kan dette realiseres med entitetene employees og organisational units. Relasjonen mellom den ansatte og organisasjon realiseres som attributter i en eller begge entiteter. Det er opp til eiere, forvaltere og utviklere for en kilde om hva som er en entitet eller ressurs. Eksempelvis kan man si at en brukerkonto er en entitet, mens et brukernavn kun er et attributt ved denne brukerkontoen. En gruppe er en entitet, mens gruppenavnet og medlemskap er attributter til gruppen.
Slike kolleksjoner av entiteter eller ressurser vil ikke gi den skredders?mmen som vi til vanlig har tilbudt. Det er n? opp til konsumenten ? selv filtrere og sl? sammen data, men kilden tilbyr n? verkt?yene for at konsumenter kan f? data.
For funksjoner som aldri kan v?re datadrevne – som start/stopp-funksjonalitet – er det opp til tjenesteeier for hvordan man realiserer dette.
Funksjonelt API
Et funksjonelt API, til forskjell fra funksjonell programmering, omhandler at designet av API-et skal v?re forst?elig og brukbart for utenforst?ende. Utviklere av konsumenter sitter ikke med den domenekunnskapen som de som jobber med en kilde gj?r. Dette betyr at API-er inn mot kilder b?r forenkles slik at de gir mening for utenforst?ende, men ikke mer enn at informasjon som er n?dvendig for konsumenter g?r tapt.
Et eksempel kan v?re den aktive studentmassen p? UiO. Ulike konsumenter kan v?re interessert i ulike mengder studenter slik at API-et m? gi et rikt utplukk studenter, men konsumentene vet ikke reglene som omhandler betalt semesteravgift, oppmeldt studieprogram eller enkeltemne, samt andre regler som bestemmer om studenter regnes som "aktive" studenter. API-et kunne realiseres som enten ? ha et attributt som sier "aktiv" p? ressursen student, eller eksponere alle tilh?rende databasestrukturer som avgj?r om studenten er aktiv i andre enden av skalaen. Sannsynligvis ligger den beste l?sningen et sted i midten, der man b?r eksponere mye av de tilh?rende data, men p? en slik m?te at konsumenten kan forst? informasjonen heller enn ? l?re seg de interne strukturene i kilden.