Visjonsnotat ESB

​Hva er en ESB?

En ESB er en funksjon som skal sikre god kommunikasjon mellom andre tjenester, i ordnede former. Det er mange teknikker for å realisere dette, noen har vist seg å være nyttige og kostnadsbesparende, andre kompliserte og fordyrende. Fundamentalt for en ESB er at den skjuler de faktiske endepunktene i kommunikasjonen mellom tjenester - det vil si at en konsumerende tjeneste kommuniserer med ESB-en heller enn å forholde seg til flere kildesystemer.

Tradisjonelt har ESB-en vært sentral i en SOA-arkitektur. Behovet har oppstått som en følge av et uoversiktlig og kaotisk systemlandskap der konsumenter har måttet forholde seg til mange ulike kilder over ulike protokoller. En ESB dekker mange av disse behovene, og er i noen grad fortsatt anbefalt. Dog har det vist seg at tradisjonelle ESB-er skalerer dårlig over tid da mer og mer funksjonalitet øker kompleksiteten i tjenesten. ESB-en blir selv en silo det blir vanskelig å skifte ut og en flaskehals i integrasjonsarbeidet.

I utredningen for ny intergrasjonsarkitektur så foreslås en konseptuell ESB for UiO. Denne ansees å være konseptuell i den forstand at man snakket ikke om en enkelt tjeneste eller programvarepakke, men en samling funksjonalitet.

Hensikten med å skille på ESB som en tjeneste og en funksjon er å distansere seg fra komplette pakker som ESB tradisjonelt er. I en tjenesteorientert arkitektur vil det være kontraproduktivt å samle så mye ulik funksjonalitet i en tjeneste med tanke på fremtidige endringer i behov. Grunnen for i hele tatt å bruke sekkebegrepet "ESB" i denne sammenhengen er at dette er funksjonalitet som er ønskelig å sentralisere og funksjonaliteten de ulike komponentene tilbyr er del av et større bilde.

Hva er hensikten med en ESB?

1. Hub-and-spoke - En database inneholder data sammenstilt fra flere andre kilder
2. Tradisjonell ESB - En sentral tjeneste som all integrasjon skal gå gjennom
3. UiOs Integrasjonsmodell - Samlingen tjenester som tilsvarer ESB-en er valgfri og kildene er tilgjengelige for tjenestene

I en overgang fra en "hub-and-spoke"-arkitektur, der navet i dag tilbyr sammensatte uttrekk og ett punkt for integrasjon, til en WS-modell der produsentene selv skal stå for for å tilby data vil mange konsumenter vil måtte forholde seg til flere kilder og mer fragmenterte data. I dagens "hub-and-spoke" modell så er ett integrasjonspunkt og sammensatte uttrekk funksjonalitet som ønskes videreført i en ny arkitektur. I dagens arkitektur så fungerer Cerebrum tidvis som denne funksjonen. ESB-en har derfor som mål å adressere disse to manglene i den nye arkitekturen. Forprosjektet har utarbeidet et Visjonsnotat Cerebrum, som omhandler tanker rundt Cerebrums rolle i dette.

• ESB-en vil kunne slå sammen data fra flere kilder for å tilby sammensatte uttrekk til konsumenter.
• ESB-en vil kunne fungere som integrasjonspunktet for konsumenter som kun skal forholde seg til en datatilbyder. Også kjent som SIngle Point of Integration.

Til forskjell fra den tradisjonelle ESB-en så sikter ikke UiOs nye integrasjonsarkitektur på at all kommunikasjon skal foregå gjennom ESB-en. Hensikten med valgfri bruk av ESB-en er handlingsrom og valgfrihet for tjenesteutviklere. Marginale eller eksterne kilder er kanskje ikke integrerte med ESB-en og prioriteten for disse integrasjonene er lav. I stedet for å måtte vente på først integrasjon mellom ESB og kilde, for så å kunne integrere med ESB, så integrerer tjenesten direkte med kilden. Integrasjonsarkitekturen setter føringer på teknologi man skal benytte ved integrasjon som medfører at man enkelt kan flytte integrasjonen fra kildesystem direkte til ESB, samt vice versa. Det er altså ikke en hensikt med ESB-en at all integrasjon skal foregå gjennom den. 

Funksjoner i ny integrasjonsarkitektur

ESB-en vil måtte forholde seg til en rekke tjenester, utover de vanlige konsumentene og produsentene. Det er ikke et klart skille mellom hva som er innenfor og utenfor ESB slik det nå er løst definert. Om man definerer en tjeneste i eller utenfor ESB så er dette av mindre viktig da hovedsaken er å tjenesteorientere. Om man velger å se Access Manager (AM) som en del av ESB eller ikke, er strengt tatt et organisatorisk grep, ikke et teknisk. Det samme kan sies om meldingskøen, som nå er definert som en del av ESB, men som like gjerne kunne blitt ansett som en egen, selvstendig tjeneste. 

Tilgangskontroll

I en tradisjonell ESB vil tilgangskontroll være en viktig funksjonalitet ESB-en tilbyr. Denne funksjonaliteten er skilt ut som en egen tjeneste i integrasjonsarkitekturen. Hovedårsaken for dette er at man vil trenge etterrettelighet også i tilfeller der ESB-en ikke er en del av en integrasjon. 

Tjenesteautorisasjon med OAuth2:

Meldingsbasert kommunikasjon

På UiO ser vi også et behov for meldingsbasert kommunikasjon mellom tjenester. Dette vil si at hendelser i et kildesystem sendes ut som en melding til tjenester som trenger å vite om disse hendelsene. Et eksempel på dette er at en bruker har byttet passord, eller at en person har endret arbeidssted. Disse meldingene vil gi konsumentene mulighet til hurtig å reagere på hendelsene etterhvert som de skjer. Konsekvensen er økt sikkerhet og forbedret brukeropplevelse. Meldingsbasert kommunikasjon mellom tjenester er en alternativ og mer moderne tilnærming til det å sende informasjon mellom tjenester. Utfordringen med en slik modell er hvordan man overkommer den økte kompleksiteten denne teknologien medfører. Til dette er en meldingskø i ESB-en tiltenkt. Meldingskøen vil ha som ansvar å ta imot meldinger fra flere kilder og påse at de riktige tjenestene får denne meldingen. Det er teknisk utfordrende å lage en robust løsning for dette i hver enkelt kildesystem og da er det kostnads- og ressursbesparende å løse dette kun et sted. 

Ikke-tekniske konsekvenser

En sentral tjeneste som ESB må forankres i organisasjonen. Velger man å tilby et sammensatt uttrekk fra for eksempel SAP og FS i ESB-en så må det gis myndighet til USIT på vegne av tjenesteeierne. Integrasjonsarkitekturen forutsetter sterk etterrettelighet da det vil bli langt enklere å integrere. Uten god kontroll øker sjansen for datalekkasjer.

I figuren over tilbyr ESB-en data som andre er ansvarlige for. I henhold til den nye arkitekturen så skal det forekomme en databehandleravtale for hver integrasjon. Det som er spesielt i dette tilfellet er at for ESB-en vil man ønske å gjenbruke dette sammensatte uttrekket til andre tjenester. ESB-en må derfor ha utvidede privilegier, som ikke normalt gis andre tjenester, og det er fullmakt til å utstede nye databehandleravtaler på vegne av andre systemeiere.

ESB-en vil også kreve en forankring i forhold til ressursbruk. I de tilfeller der man velger å benytte ESB-en som eneste integrasjonspunkt (Single Point of Integration) så vil USIT bære store deler av kostnaden rundt integrasjon. Hvordan dette skal finansieres må utredes. 

Tekniske valg

Det er for tidlig å konkludere om hvilke tekniske løsninger en ESB bør basere seg på, og si med sikkerhet nøyaktig hvilken funksjonalitet den bør inneholde. Organisasjonen mangler erfaring med denne typen tjeneste, og valgene må derfor utredes i mer detalj. Behovene som vi vet må dekkes med en ESB, bør være utgangspunktet for videre arbeid med å kartlegge de tekniske detaljene. Det er fornuftig å la usikker funksjonalitet utvikle seg organisk etter at tjenesten er etablert og etterhvert som man samler seg erfaring. ESB-en eksisterer i hovedsak for å effektivisere, og det gjøres best i iterasjoner. 

ESB-programvarepakker tilbyr ofte integrasjonspakker for visse systemer. Slike integrasjonspakker vil være fristende å benytte i UiOs ESB, da man enkelt kan integrere store, tunge systemer og på den måten får tilgang på data fra systemene på en enkel måte. Ulempen med en slik løsning er at ESB-en blir tett knyttet til nevnte system. Endringer i ESB-en eller systemet vil få konsekvenser for den andre parten. 

1. Som en del av ESB-en så benytter man en integrasjonspakke for å integrere en kilde. Integrasjonen blir en del av den sentrale ESB-en. 
2. Man benytter ESB-programvare for å integrere med en kilde, uavhengig av den sentrale ESB-en. 

Det er vanskelig å konkludere på en av disse modellene, men mye taler for at forslag 2 i figuren over er å foretrekke. Med denne modellen så vil ESB-programvaren opptre som en WS, på lik linje med alle andre aktører og den sentral ESB-en er fortsatt valgfri med hensyn til integrasjoner mot kildesystemet. Den sentrale ESB-en "forurenses" ikke med systemnære koblinger og eieransvaret for alle komponenter er klare.

Det er en klar trend i bransjen, mot en oppfatning om at store suiter som skal løse "alt" i en stor totalpakke er en dårlig investering. Virksomheter som tidlig investerte i denne formen for ESB sliter nå med en svært komplisert buss som har store vedlikeholdskostnader. Løst sammensatte tjenester som utfyller hverandre er enklere å endre og komplementere.

Veien videre

Det er mange aspekter det er for tidlig å konkludere med i forprosjektet: organisasjonen ikke nok erfaring til å konkludere på godt grunnlag. Det er derfor vår anbefaling at første iterasjon av UiO ESB fokuserer på de kjente funksjonene vi vet med sikkerhet at vi har et behov for:

• Meldingskø
• Sammenstille de vanligste, komplekse uttrekkene
• Singe Point of Integration

Vi vet fra trender i IT-industrien at andre funksjoner kommer i kjølvannet av ESB:

• API gateway
• "Self-service" integrasjon

Disse trendene bør man undersøke enten etter at de initielle funksjonene er på plass, eller overvåke for å vurdere om de bør få prioritet som initielle funksjoner ved UiO.