Overordnet
Arkitekturen har som overordnet m?l om ? flytte ansvaret for det ? integrere p? den part som ?nsker ? integrere. Tradisjonelt har integrasjoner ofte v?rt realisert ved at de ansvarlige for en datakilde har m?ttet generere filer basert p? de data de har i kilden, f?r s? ? distribuere denne filen. P? grunn av krav fra prosjekt eller applikasjonseier som ?nsker data, samt et krav om ikke ? lekke data, s? har disse filene blitt skreddersydd for hver nye konsument. Dette er problematisk av flere ?rsaker:
- Ansvaret for ? integrere ligger da hos de ansvarlige for dataene, ikke de som ?nsker dem.
- Neglisjerbar gjenbruksmulighet av slik eksporter.
- Etterhvert som behovet for ? integrere flere applikasjoner ?ker, s? ?ker kompleksiteten i datakilden.
- Prosjekter eller applikasjonseiere kan ikke l?se integrasjon selv, de er prisgitt planer og kapasitet hos dem som er ansvarlige for datakilden.
- ? flytte filer er utdatert og ineffektiv teknologi som gir d?rlig datakvalitet og brukeropplevelse.
Deler av arkitekturen er organisatoriske grep for ? definere ansvar og sette ned regler som hele virksomheten skal f?lge. Selv de beste IT-tjenestene kan ikke p?se at arkitekturen f?lges – arkitekturen m? representeres i forretningssiden i virksomheten ogs?. Siden utenforst?ende ikke tradisjonelt har hatt tilgang til datakilden, har integrasjoner v?rt forbeholdt de ansvarlige for kilden. For ? endre p? dette definerer denne arkitekturen styringsregler som p?legger datakildeeiere/systemeiere ? tilby data via ?pne grensesnitt.
Modellen
Den overordnede tekniske modellen som ligger til grunn for UiOs integrasjonsarkitektur, er en distribuert modell. Dette betyr at data og ansvar er distribuert i organisasjonen, men liten grad av sentralisering. Det er flere ?rsaker til at dette er valgt modell, men prim?rt kommer dette av hvordan virksomheten er organisert.
Modellen er den mest form?lstjenlige – organisatoriske – for UiO, men gir ogs? noen utfordringer:
- ?kt risiko for varierende teknologi og grensesnitt foran applikasjoner
- Ingen sentral oversikt
- Ingen sentral kontroll
- Ingen gevinster gjennom sentralisering og stordrift
For ? adressere disse utfordringene er det definert noen styringsregler og st?ttestjenester.
Webservice (WS)
En webservice er et teknisk grensesnitt som f?lger bestemte bransjenormer. Gjennom UiO:IntArk har et sett med styringsregler blitt vedtatt for ? standardisere hvordan tjenester og applikasjoner tilbyr grensesnitt. Hensikten med dette er ? standardisere der det er hensiktsmessig, uten ? begrense handlingsrom og innovasjon ute blant tjeneste- og applikasjonseiere. Det foreligger ogs? en veiledning om hvordan man vurderer en eksisterende WS eller designer en.
?
En WS som tilbyr et RESTful API gir fordeler:
- Bransjestandard
- Gjenbrukbar funksjonalitet
- Fremmer heller enn hemmer innovasjon
Mer om WS st?r i veiledningen.
API manager
En API manager er en tjeneste som har til ansvar ? kontrollere tilganger til tjenesters WS-er. Det ? implementere full tilgangskontroll til API-er er en anselig ekstrakostnad for applikasjonsforvaltere som skal tilby en WS. Uten tilgangskontroll vil WS-en tilby alle data for alle.
Tilgangskontroll til hvert enkelt API er en betydelig besparelse for applikasjonsforvaltere som er ansvarlige for WS-er, men det gir ogs? en forenkling og en besparelse for konsumenter:
Fordi all trafikk mellom WS og konsument g?r gjennom API manager s? adresserer man flere av utfordringene med den valgte modellen:
- Sentral oversikt over integrasjoner
- Sentral kontroll over integrasjoner
- Stordriftsfordeler ved at tilgangskontroll av tjenester sentraliseres
Gitt retningslinjene for hvordan et API skal utformes s? vil man ogs? kunne se hvordan data flyter via integrasjonene.
API manager er tilrettelagt distribuert forvaltning av API-tilganger slik at den organisatoriske modellen etterleves selv om API manager er en sentral komponent. Dette vil si at applikasjonsforvaltere selv forvalter tilganger til API-er og data i API manager.
Meldingsk? (MQ)
Meldingsk?en – MQ – er en tjeneste for ? fortelle om endringer. WS brukes for ? hente data (evt. skrive), men dette l?ser ikke de situasjoner der en applikasjon skal fortelle at en endring har skjedd. Man kunne skissert en l?sning der applikasjonen skulle sendt endringen til alle WS-er rundt omkring, men dette er ikke generelt nok og det undergraver prinsippet om ? la de som skal integrere, gj?re integrasjonen selv.
L?sningen er ? tilby en sentral meldingsk? der produsenter sender notifikasjoner om endringer p? sine data. Produsenten vet ingenting om eventuelle konsumenter av disse notifikasjonene og forholder seg kun til MQ.
MQ vil ta ansvar for mye av logistikken rundt notifikasjoner. Hendelses-basert kommunikasjon er komplekst med flere utfordringer:
- Oversikt over alle k?er og notifikasjoner
- Tilgang til k?er og notifikasjoner
- Oppetidskrav og redundans
MQ l?ser i stor grad disse problemene og gj?r at produsenter kan forenkle notifikasjonsutveksling.
I UiO:IntArk er innholdet i notifikasjoner ogs? regulert. Notifikasjoner sendes typisk ikke ut uten innhold, men for MQ s? er notifikasjoner tenkt brukt kun som et varsko p? at konsumenter skal unders?ke WS for oppdateringer. Det er flere ?rsaker til dette, men de viktigste er:
- En notifikasjon blir aldri komplett. Data er sammensatte og en endring p? et fakultet kan f? implikasjoner for tilh?righetene til personer tilknyttet fakultetet.
- Datarike notifikasjoner vil m?tte tilgangskontrolleres. Datafattige notifikasjoner kan publiseres n?rmest fritt.
En notifikasjon gjennom MQ vil typisk si noe om at en entitet er endret. Det vil v?re opp til konsumenten ? finne ut hva som er endret. Notifikasjonen vil gi indikasjon p? hvilken entitet som har endret en type data, men vil ikke lekke informasjon som kan identifisere en person. Notifikasjonene vil heller ikke si noe om tidligere eller nytt innhold i data som er endret.
Hvordan modellen fungerer
Arkitekturen legger opp til ? sentralisere tjenester som er nyttige, som ikke begrenser handlingsrommet til applikasjonsforvaltere eller prosjekter, og som effektiviserer integrasjon p? UiO. Det er ikke n?dvendigvis slik at alle applikasjoner vil m?tte forholde seg til alle komponenter i arkitekturen, det er styrt av integrasjonsbehovet for applikasjonen.
Provisjonering – Need to Know
Provisjonering er det ? sende en mengde data fra en applikasjon til en annen. Hvorfor man ?nsker ? gj?re dette kan v?re mange, men tradisjonelt har man basert integrasjoner p? provisjonering fordi integrasjoner har v?rt tunge, filbaserte batch-oppdateringer. Man har laget store filer med komplette datasett, flyttet disse til konsumenten og der sammenligner man den store filen med konsumentens database for ? se etter endringer. Dette er ikke en effektiv m?te ? integrere p?. Isteden kan slik provisjonering v?re hendelsesdrevne:
Mange applikasjoner, som i dag er baserte p? gamle integrasjoner med provisjonering, trenger ikke ? provisjonere data i den nye arkitekturen. Likevel er det et behov for provisjonering i de tilfeller der man lager moderne applikasjoner og integrasjoner. Eksempel: N?r en ny person registreres i HR-systemet s? er ikke HR-systemet ansvarlig for ? utstede en brukerkonto til personen. Dette er IAM-kjernen (tidligere BAS, IdM) ansvarlig for. IAM-kjernen vet ikke at det er registrert en ny person i HR-systemet f?r HR-systemet gir beskjed. IAM-kjernen vil ikke kopiere alle data om personen fra HR-systemet, men den trenger data om personen for ? lage en brukerkonto til vedkommende og da vil IAM-kjernen provisjonere noe data. IAM-kjernen vil beholde oversikt over hvem som er eier for brukerkonti f.eks. Disse eierne er provisjonert fra HR-systemet.
Man kan tenke seg et annet eksempel der flyten er lik som i figuren over, men man ikke provisjonerer – integrasjonen er basert p? Need to Know. Forskjellen p? provisjonering og Need to Know ligger i om konsumenten lagrer kopier av data fra kilden i sine datalagre. Distinksjonen mellom de to er minimal, men generelt skal man fors?ke ? unng? mellomlagring av data fra et kildesystem og heller hente disse dataene fra kilden ved behov. Av ulike ?rsaker kan dette vise seg vanskelig s? provisjonering vil forekomme ogs? i den nye arkitekturen.
Forskjell fra DiFis eNotifikasjon
Selv om Need to know kan ligne veldig p? eNotifikasjon-m?nsteret fra DiFis referansearkitektur for datautveksling, er det til dels store avvik i m?nstrene:
| Need To Know | eNotifikasjon | |
|---|---|---|
| 1 |
F?r tilsendt en notifikasjon. Konsumenten kan v?re tilstandsl?s, da konsumenten ikke trenger ? ha begrep om hvilke notifikasjoner som er prosessert. |
M? hente en liste over notifikasjoner. Konsumenten m? lagre tilstand, da eNotifikasjon-m?nsteret forutsetter at konsumenter vet hvilke notifikasjoner som er prosessert. |
| 2 |
Notifikasjonen inneholder kun nok informasjon til ? identifisere hva som har endret seg. Konsumenten m? utf?re eOppslag mot kildesystem f?r det kan avgj?res om det skal utf?res en operasjon. |
Notifikasjonen inneholder informasjon om hva som har endret seg, og en identifikator til et hendelsesdokument som inneholder endrede data. eNotifikasjonen b?rer nok data til ? avgj?re om det skal utf?res en operasjon. |
| 3 | Rekkef?lgen notifikasjoner ankommer i er ikke garantert ? v?re velordnet og sekvensiell. | Rekkef?lgen notifikasjoner ankommer i er alltid velordnet og sekvensiell. |
| 4 | Ingen autorisasjon er n?dvendig da notifikasjoner kun har informasjon om hva som er endret. Produsenter har ikke begrep om hvem som er konsumenter. | Autorisasjon kan v?re n?dvendig da notifikasjoner kan inneholde data. I tilfeller der autorisasjon er n?dvendig, m? produsenter ha et begrep om hvem som skal kunne konsumere hvilke data. |
| 5 | Need To Know er en implementasjon av Fire And Forget og eOppslag m?nstrene. | eNotifikasjon er en implementasjon av Event Sourcing m?nsteret. |
Modul?re applikasjoner
Integrasjonsarkitekturen legger ogs? opp til mer modul?re tjenester som er satt sammen av ulike applikasjoner (eller deler av applikasjoner). Under Provisjonering beskrives en dataflyt mellom to applikasjoner fordi konsumenten skal agere p? endringer i produsentens data. Man kan tenke seg scenarier der man ikke anser tjenester eller applikasjoner som s? separate, men heller at applikasjoner sammen utgj?r en tjeneste.
Et eksempel p? en produsent som vil v?re attraktiv for mange tjenester er e-posttjenesten. Ved ? integrere e-posttjensten i f.eks. l?ringsplatformen f?r studenter en bedre og mer innholdsrik arbeidsflate. LMS-et kan benytte e-post- og kalendertjenesten for meldinger mellom studenter og forelesere, eller kollokvie- og undervisningsgrupper. Mer tradisjonell integrasjon ved ? kopiere data vil gi d?rligere brukeropplevelse og kompleksitetsproblemer ved en eventuell synkronisering mellom LMS-et og e-posttjenesten.
Sammendrag
UiOs integrasjonsarkitektur er en standardisering av prosess og teknikk for ? effektivisere integrasjoner. Standardisering er, som kjent, et tveegget sverd. Det str?mlinjeformer slik at aktiviteter blir mer effektive, men str?mlinjeformingen hindrer ogs? innovasjon og handlingsrom. Tanken bak UiO:IntArk har hele tiden v?rt ? standardisere der det er form?lstjenlig og la felt som krever selvr?derett v?re opp til applikasjonsforvaltere, utviklere og prosjekter. Hva man ?nsker ? integrere er opp til den enkelte, hvordan man integrerer stilles det krav til.
Det ? basere arkitekturen p? bransjestandard teknologi og inkludere de organisatoriske utfordringene som noe arkitekturen skal adressere har resultert i en arkitektur som posisjonerer UiO i forhold til bransjen, men ikke p? bekostning av autonomi. Arkitekturen vil kunne erstatte protokoller og tjenester etterhvert som bransjen utvikler seg, men uten ? m?tte omskrive hele arkitekturen. Store systemer kan oppst? og legges ned uten at arkitekturen p?virkes nevneverdig.