Tjenesteorientering og distribuerte systemer
•
1 like•862 views
Presentasjonen inneholder en oppsummering av erfaringer fra SOA (tjenesteorientering), eventdrevne systemer, distribuerte systemer og det å drive slike systemer i praksis. Presentasjonen viser utfordringer og mulighetsrom, sammen med beskrivelse av hvordan Skatteetatens målarkitektur skal virke.
Recommended
Recommended
More Related Content
More from Tormod Varhaugvik
More from Tormod Varhaugvik (9)
Tjenesteorientering og distribuerte systemer
- 1. Tjenesteorientering - Distribuerte systemer SITS – IS - UTV Tormod Varhaugvik, 27 Mai 2010 1
- 2. Presentasjonen • Presentasjonen vil fokusere på tjenesteorientering og distribuerte systemer • God tjenesteorientering er oppskriften på at distribuerte systemer og SOA skal lykkes • Tre bøker spiller inn: • SOA in Practice – The Art of Distributed System Design • Domain Driven Design • Enterprice Integration Patterns • Presentasjonen bruker eksempler fra egne erfaringer med tjenesteorienterte og eventdrevne arkitekturer Enterprice Integration Patters Obligatorisk ! Etablert og anerkjent Også programmeringsstandard for ”skalering inn i skyen” 2
- 3. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 3
- 4. Bakgrunn – Hva kjennetegner store systemer? • Arv eller alderdom (==legacy; man må leve med aldrende systemer) • Heterogene (teknologien utvikler seg) • Komplekse (definisjonen i Patterns of Enterprise Application Architecture ) • Forskjellige eiere • Ufullkommen (==imperfection; det er alltid noe som ikke virker, mangler eller ikke passer sammen) (sitat Winston Churchill: Perfectionism spells P-A-R-A-L-Y-S-I-S) • Duplikat / overflod (==redundant; både data og funksjonelt) • Flaskehalser er døden (ikke bare IT runtime, men også organisasjon og endringsmulighet…) • Det er ingen som forstår alt Og slik kommer det alltid til å være. Målet er å redusere dette og å legge opp til en arkitektur som håndterer dette 4
- 5. Bakgrunn – eksisterende situasjon (nesten) Systemkart FOI WEB Altinn Forskudd, Internett PSA Ekstern Kommunikasjons IBM AS/400 Intern -grensesnitt SFU MQseries Sentral- skattekontoret For Oppslag på fil Utenlandssaker LNA Sentrale Lokalt Navn og Adresseregister InterConnect registre FOS DSF FOrskudd. Sentralt Det Sentrale Transparent Gateway (TG) Folkeregister View-oppslag mot tabeller FOL LFP FOrskudd, Lokalt Likning, Ftp-overføring og TG ForkuddsPliktige Både TG og MQseries Manntall Databaselink * PSA Datavarehus Ftp-overføring Preutfylt SelvAngivelse DSB Ftp-overføring og DVD Adresse- Datastøttet registeret SLN Selvangivelses- System for Likning Behandling av LEP Næringsdrivende Likning, * samme grensesnitt EtterskuddsPliktige Kommune registeret AR Plattform Aksjonær- Registeret GLD OS390/ GrunnLagsData Eiendoms Cobol/DB2 registeret Enhets- Unix/Oracle registeret Fonsa MVA- Mainframe FL sentral MVA ForhåndsLikning Unix/Pro-IV MVA MerVerdiAvgift Unix/Sybase Tinglyste Arveavgift hjemmels- (nye) Er en del av overganger MVA-løsningen Arveavgift IBM AS/400 (gamle) Intern Internett/ Web SOFIE Ekstern Skatte- regnskapet Slik er det mange steder. Grunnen er mange; hver forvaltningsområde sitt system prosjekter har et fokusert mandat, vi må ha noe kjapt og enkelt, eller rett og slett ingen overordnet prioritering eller styring innenfor IT-arkitektur 5
- 6. Bakgrunn – IT strategien •Selvbetjening - Utvikle flere og bedre elektroniske tjenester •Endringsfleksibilitet – Nye oppgaver og kontroller •Fokus på sikkerhet, kvalitet og etikk •Bærekraftig og miljøvennlig IT-utvikling •Få ned forvaltningskostnadene •Automatiser produksjonsprosessene •Styre ut fra et samlet mål for virksomheten •Fra separate systemer til sammenhengende verdikjeder •Tjenesteorientert arkitektur, komponentbasert utvikling, anvendelse av åpne standarder og gjenbruk •Bruke av fungerende tjenestemarked og unngå monopol •Arbeide for å bygge fellesløsninger for offentlig sektor Utvikle flere og bedre elektroniske tjenester for innbyggere og næringsliv Arbeide for å bygge fellesløsninger for offentlig sektor og være pådrivere for å effektivisere arbeidsprosessene på tvers av offentlig sektor Opprettholde høy fokus på tilgjengelighet, sikkerhet, kvalitet (testing) og etikk Sikre en bærekraftig, miljøvennlig IT-utvikling • Endre systemporteføljen fra separate systemer til sammenhengende verdikjeder • Styre videreutvikling og ny funksjonalitet ut fra et samlet mål for virksomheten • Prioritere investeringer som effektiviserer produksjonsprosessene og gjør det mulig å sette sammen data på nye måter på tvers av produksjons¬prosessene • Følge prinsippene om tjenesteorientert arkitektur, komponentbasert utvikling, anvendelse av åpne standarder og gjenbruk • Prioritere bruk av fungerende tjenestemarked og unngå monopol¬situasjoner 6
- 7. SKD Strategiprinsipper for IT Tilgjengelighet Funksjonalitet skal være lett tilgjengelig for brukerne der og når de trenger det Brukervennlighet Elektroniske brukertjenester skal være tilpasset brukeren og dennes bruksmønster, legge til rette for effektiv bruk, samt sikre god kvalitet på oppgaven som utføres Integritet Funksjonalitet skal tilbys i henhold til lover og regler, sikkert og konfidensielt, og med en høy kvalitet slik at den sikrer integritet for både Skatteetaten, partnere og skattytere/innbyggere Samhandling Funksjonalitet skal tilbys på en slik måte at det er enkelt å samhandle innen og med etaten Endringskapasitet Alle løsningers funksjonalitet skal være fleksible nok til å kunne følge forventede endringer i samfunnet og i etatens tjenester innen rimelig tid og prisramme Gjenbruk Gjenbruk skal prioriteres, både ved å velge allerede gjenbrukbar funksjonalitet fremfor ny utvikling/anskaffelse og ved å investere i gjenbrukbarhet ved utvikling/anskaffelse av ny funksjonalitet Livsløp Ved utvikling og anskaffelser skal gevinst- og kostnadsbildet ta høyde for helheten i SKEs systemportefølje, hele livsløpsbildet for løsningen, samt de ikke-funksjonelle kravene Tilgjengelighet Funksjonalitet skal være lett tilgjengelig for brukerne der og når de trenger det Brukervennlighet Elektroniske brukertjenester skal være tilpasset brukeren og dennes bruksmønster, legge til rette for effektiv bruk, samt sikre god kvalitet på oppgaven som utføres Integritet Funksjonalitet skal tilbys i henhold til lover og regler, sikkert og konfidensielt, og med en høy kvalitet slik at den sikrer integritet for både Skatteetaten, partnere og skattytere/innbyggere Samhandling Funksjonalitet skal tilbys på en slik måte at det er enkelt å samhandle innen og med etaten Endringskapasitet Alle løsningers funksjonalitet skal være fleksible nok til å kunne følge forventede endringer i samfunnet og i etatens tjenester innen rimelig tid og prisramme Gjenbruk Gjenbruk skal prioriteres, både ved å velge allerede gjenbrukbar funksjonalitet fremfor ny utvikling/anskaffelse og ved å investere i gjenbrukbarhet ved utvikling/anskaffelse av ny funksjonalitet Livsløp Ved utvikling og anskaffelser skal gevinst- og kostnadsbildet ta høyde for helheten i SKEs systemportefølje, hele livsløpsbildet for løsningen, samt de ikke- funksjonelle kravene. Og dette skal gjøre det billigere? 7
- 8. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 8
- 9. Tjenesteorientering 1 • Tjenesteorientering er bare et paradigme eller begrep • TO er noe som leder til en konkret arkitektur • TO er en måte å tilnærmer seg ett problem på • TO ønsker å forbedre fleksibilitet • For å oppnå fleksibilitet må man involvere organisasjonen med klare roller, retningslinjer, prosesser osv… • TO pådrivere • Forskjellige eiere medfører mye politikk og kompromiss, derfor er TO mye mer enn teknologi • SOA’s håndtering av disharmoni (heterogene systemer) • TOs forskjellig tilnærming: • Bygge nye systemer på toppen av eksisterende systemer • Rydde opp og forenkle • Virksomhetsarkitektur er prosessen og målbildet for hvordan å oppnå en god arkitektur Dette er strategien for å håndtere dette. 9
- 10. Tjenesteorientering – Samarbeid Lager Butikk Livssyklus Egenskaper Prosess Systemene har forskjellige oppgaver, men er avhengige av hverandre og trenger å samarbeide gjennomgående må man kjenne til tilstanden på entiteter som man bruker og som tilhører annet system Livssyklus til de entiter som systemene behandler. Eier er forpliktet til å fortelle andre om når noe oppstår og forsvinner. Livssyklus er hva man kan snakke om. Egenskaper utveksling om informasjon om en entitet. Prosess er nødvendig for å håndtere flyt på entiteter man samarbeider om eller kjenner til. Eks. bestillingsprosessen Begge tilbyr web bilder som brukerene har i sin browser, men brukeren skjønner ikke hvilket system man benytter. 10
- 11. TO - Nedbrytning Komponenter Splitt og hersk! Funksjoner og data som hører sammen. ”Domain Driven Design” Tjenester Komponentens hensikt. Beskriver de funksjoner som komponenten kan oppfylle Samhandling Protokoll for bruk av tjenestene. Kulturen i det distribuerte systemet Informasjon Informasjon som tilbys av tjenesten. I form av meldinger, attributter i API’er eller skjermbilder Integrasjon Kommunikasjon mellom tjenester. Limet mellom komponentene i det distribuerte systemet •I stort og smått dreier mye seg om god modularisering Vil snakke om tjenesteorientering fordi det da er tydeligere hva som må gjøres. man kan åpenbart ikke kjøpe tjenesteorientering, men man kan kjøpe en SOA plattform… Disse er til dels overlappende, men det gir mening i å snakke om disse hver for seg (de har hvert sitt perspektiv). De tre øverste er vandlige i alle systemer også de som er lukket, men har ytterligere kompleksitet De to nederste er mer spesifikke for uavhengige systemer Hvordan kan vi lage 11
- 12. TO Funksjonelt • Riktig modularisering skal øke fleksibiliteten • Målet er å minske avhengigheter i systemet, slik at endringer lar seg gjennomføre uten for stor risiko • Det skal være lettere å kunne forstå store systemer • Ha kravbeskrivelser og integrasjonsgrensesnitt som er beskrivende nok både syntaktisk men også semantisk. • Løs kobling • Fleksibilitet og robusthet • Tversgående virksomhetsprosesser • Fremdeles funksjonelt avhengige Løs kobling er bra der man kan ha sterk gruppering av data og funksjonalitet (cohesion=mye felles) og tydelige grensesnitt (coupling ) 12
- 13. TO Teknisk • Tekniske og ikke-funksjonelle krav • Oppetid, svartider og sikkerhet • Tilrettelagt integrasjon • Det skal være lett å integrere systemer • Forutsetter en grad av felles arkitektur • Arkitekturen må struktureres med • mønster, instrukser og regler • versjonshåndtering • roller og ansvar • referansearkitektur • virksomhetsarkitektur - målbilde • Tversgående endringer slår hard også her • Endring på felles arkitektur Mønster = Patterns Selv om vi deler opp i tjenester så er det ikke gitt at de er funksjonelt uavhengige. man må altså dele opp slik at systemet gir de svartider / oppetid som er relevant Postjournalen til Plan og bygg er nok nattlig kopiering av data. Man spør ikke saksbehandlingssytemet eller yr.no portalen er ikke værregnemaskinen! 13
- 14. TO Organisatorisk • Uten finansiering og samkjørte prosjekter, ingen tjenesteorientering • Sentralt må man ha kontroll, men må fordele oppgaver og ansvar (da skalerer prosjektene…) • Alle har sitt eget perspektiv og ingen som forstår hele systemet • Lettere å koordinere innad i prosjekter enn i mellom • ”Krav paralyse” hvis for mye avklaringer mellom prosjekter Kontroll, eller i det minste styring… 14
- 15. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 15
- 16. Komponent 1 - Målbilde • Oppdeling i komponenter skal gjøre det distribuerte systemet lettere å forstå og lettere å forvalte • Konfigurerbar, svikttollerang og skalerbar • Fokuser på et funksjonsområde som er gjenbrukbart; forretningsfunksjon, forvaltningsområde, teknisk art • Den er selvstendig med data som hører sammen, og tilstand og funksjoner på dataene • En komponent eier de data den produserer • Den bør ha mer enn én forbruker av tjenestene • Den bør ha selvstendig forvaltning • Veldefinert; funksjonelle og ikke-funksjonelle krav • Domain Driven Design gir mange gode råd i å finne slike Eierskap medfører også at den har myndighet over egne data o funksjoner på de. Følg dataene! Målbildet utarbeides av virksomhetsarkitekturprosjektet og vil revideres nå og da. Vi vil alltid være på Målbildet representerer et strategisk mål, og vil sannsynligvis aldri bli oppfylt. 16
- 17. Komponent 2 - Legacy • Klassisk SOA tilnærming er nye tjenester på eksisterende- eller anskaffede systemer • Man har gjerne en annen tilnærming • Identifiser hvilke nye tjenester som skal tilbys • Avvei om disse skal løses utenfor komponenten, eller om man skal utvide komponenten • Innfallsvinkelen er hvor lenge komponenten skal vare • Hva er den beste varige løsningen? • På veien mot målbildet er det mye legacy på veien Konkret har eDialog disse utfordringene Vi sitter tross alt på vår egen portefølje og kan gjøre noe med komponetene og tjenesene. 17
- 18. Komponent 3 - SKD • Noen tanker rundt komponenter for oss • Forvaltningsområdene gir ganske tydelig oppdelig • Forvaltningsområdene behandler dog informasjon som er felles • Dages siloer er ofte resultat av ensidig fokusering på forvaltningsområde og ikke på fellestrekk • Tjenesteorientering dreier seg om å gjenbruke felles informasjon og regelverk • Tjenesteorientert juss? lover står iblant i motsetning, burde det kanskje vært ryddet fra toppen. • Det er ikke rart IT systemer blir sammensatt når den siste 10% egentlig ikke henger sammen og IT må ”finne ut av det” Felles periodisering… Felles informasjonsforståelse… Gi eksempel fra KompAns. Kompetanse og ansiennitet for lærere Poenget er at det er mye å hente på å forenkle regelverk 18
- 19. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 19
- 20. Tjeneste 1 – Egenskaper Gjenbrukbar I motsatt fall trenger komponenten ikke å eksponere den Selvberget Tjenester skal kunne kjøre slik den er eksponert, den skal ikke måte forutsette for mye Grovkornet Må ha rett abstraksjonsnivå, avveining mellom ytelse og vedlikeholdbarhet Oppdagbar Kan ikke gjenbruke noe ingen finner! Tilstandsløs Tjenesten skal ikke være i dialog med forbruker Gjentagbar Robusthet bedres hvis det ikke betyr noe om noe kalles en eller flere ganger Sammensettbar Å kunne delta i en større sammenheng, kanskje spesielt for brukergrensesnitt QoS Ikke-funksjonelle egenskaper Tekniske Eks. sikkerhet, administrasjon og overvåkning Dette er egenskaper for tjenester mellom distribuerte systemer Gjenbrukbar; funksjonen er kanskje gjenbrukbar, men de ikke-funksjonelle kravene river den i filler. D Datatyper i denne sammenheng er datatyper i modellen; slike som nøkkelforståelse (eg. Ett kundenumm Sammensettbar: Man trenger ikke bruke Webservices eller BPEL inne i dette. 20
- 21. Tjenestetyper 1 - Målbilde • Integrasjonsklassifisering sier noe om hva de kan brukes til Funksjons- Tjeneste som tilbyr en funksjon eller beregning Har ikke nødvendigvis tilstand eller varig datalager selv Data- Tjeneste som tilbyr data (behov for data annet sted) Hendelses- Tjeneste utføres basert på en hendelse Signaliserer til andre om endringen Brukerdialog- Tjeneste for mennesker Disse kan sømløst knyttes sammen Brukeren skal ikke merke hvilket komponent han jobber mot Funksjonsintegrasjon Integrasjonsformen er basert på integrasjon hvor systemer kaller hverandres tjenester for å få utført en op Hendelsesintegrasjon Denne integrasjonsformen baserer seg på å at et system sender events når det oppstår en hendelse som de Andre system kan lytte på slike events og reagere slik som det lyttende systemet finner hensiktsmess systemet kan bruke funksjonsintegrasjon eller dataintegrasjon for å få flere detaljer angående hendels Dataintegrasjon Denne integrasjonsformen baserer seg på å overføre data fra en applikasjon til en annen. Dette er blant a forespørsel, en hendelse eller som del av en batch. Integrasjonsformen kan være punkt-til-punkt og p Brukerdialogintegrasjon Integrasjonsformen kalles ofte for GUI-integrasjon. Denne integrasjonsformen baserer seg på direkte bru URL og deretter utføre et stykke arbeid. URL kan inneholde parametre slik at den kallende applikasj 21
- 22. Tjenestetyper 2 - Legacy Basis Både business og IT skjønner hva tjenesten gjør ACID (Atomic, Consistent, Isolated, Durable) Sammensatt Den er satt sammen av basistjenester Tjenesten er definert fordi det er mer effektivt Tilbyr en forretningsfunksjon som utføres på flere bakenforliggende systemer Sannsynligvis 2-phase commit for ha ACID Process Implementerer en prosess av andre tjenester Den har tilstand Den viktige designbesluttingen ligger i hvor tilstanden skal tas vare på og hvor lenge 22
- 23. Systemeksempel – Eventdrevet arkitektur Innkjøp Butikk Assortement B1 S1 B2 B3 B3 A2 B2 A1 B1 AH Ekstern Meldings- lager og formidler S1 A2 A1 N1 AH AH Pris Autorisasjon Arbeidsflyt Egenskaper: Forklar flyten i systemet, Events data og reaksjoner i systemer som mottar en melding Gjenbruk av brukergrensesnitt Workflow som generell saksbehandlingskomponent Authorization og rolle i sikkerhet Utfordringer: Meldingsegenskaper, sekvenshåndtering, global transaksjonsmekanisme. Feil mellom systemene. Køer som stopper 23
- 24. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 24
- 25. Samhandling 1 • Sterk og svak kobling mellom komponenters tjenester Forbindelse Punkt-punkt – formidler Kommunikasjon Synkron – asynkron Datamodell Komplekse – enkle Typing Sterk – svak Samkvemsmåter Sammensetting – komplett Prosesstyring Sentral – distribuert Binding Statisk – dynamisk Plattform Like – ulike Transaksjonshåndtering 2-fase – kompensasjon I driftsetting Simultan – trinnvis Versjonshåndtering Eksplisitt – implisitt Eller motsatt: er alle disse sterke er det sansynligvis en komponent og ikke 2. WebService er punkt-til-punkt. Ytelse kan også føre til at mediator ikke er nødvendig. Komplekse typer vil si at man legger opp til at de som integrerer skal kjenne til spesifikke datamodell, so Typing: Attributter kontra key-value. Avhengige meldinger (bruke tjenester eller sette sammen med andre medlinger) sentral = Orkestrert, desentral = Koreografi binding; kontroll ved kompilering eller ved kjøring? Deployment; tjenesteorientering er å kunne slippe sporadisk Men hv med cross-cutting changes? De kan Versjon: eksplisitt -> bygge på nytt. impisitt sikrer bakoverkompabilitet (nummer regime+++) Kan utmerket godt integrere uten bruk av BUSS… Endringer bør ikke treffe transporten. 25
- 26. Samhandling 2 • Megler / formidler • Motvirk punkt til punkt ved generiske adresser • Formidler: før forespørsel sendes eller etter at forespørsel er sent • Synkron kommunikasjon • er enklere å implementere, men mer sårbar og mindre robust • Asynkron kommunikasjon • Fint for å øke gjennomstrømning og minske avhengigheter • Forutsetning for skalerbare systemer • Men det introduserer problemer med: • Kvitteringshåndtering og ”når kommer svaret?” • Sekvens på meldinger • Mer kompleks logikk for å håndtere køer • I produksjon vil systemer bli vanskeligere å ha oversikt over • En god tjener men en dyr herre WebService er punkt-til-punkt. Ytelse kan også føre til at mediator ikke er nødvendig. Komplekse typer vil si at man legger opp til at de som integrerer skal kjenne til spesifikke datamodell, Typing: Attributter kontra key-value. Avhengige meldinger (bruke tjenester eller sette sammen med andre medlinger) sentral = Orkestrert, desentral = Koreografi binding; kontroll ved kompilering eller ved kjøring? Deployment; tjenesteorientering er å kunne slippe sporadisk Men hv med cross-cutting changes? De ka Versjon: eksplisitt -> bygge på nytt. impisitt sikrer bakoverkompabilitet (nummer regime+++) Kan utmerket godt integrere uten bruk av BUSS… Endringer bør ikke treffe transporten. 26
- 27. Samhandling 3 • Datamodell • Umulig å forstå en ”universell datamodell” (Perfection == paralysis) • Hvert domene har sitt perspektiv (DDD) • Introduser kanonisk modell med harmonisering og eierskap • Grad av typesjekking • API kontra protokoll Sterk typesjekking for å fange feil tidlig, men i store systemer slår dette hardt • Mer fleksibelt at typesjekking gjøres i tjenestegrensesnittet • Datastrukturer i meldinger • Bruk basistyper; string, int, long, date, boolean og arrays • Valg mellom objekt = melding eller transaksjon = melding Modellforståelse = Nevn eksempel fra Paga med godkjenning av datamodellen Protokoll gir fleksibilitet, men ikke så tydelige bruk API gir tydelig bruk og er god programmeringsskikk, men slår når de skal deployes Kanonisk format må eies av en Modul, gir en betydelig organisatorisk effekt 27
- 28. Samhandling 4 • Kompensasjon • 2-phase commit skalerer ikke spesielt bra • Kompensasjon er en måte å kunne rulle tilbake på • Prosesstyring • Orkestrering. En komponent dikterer og kjører prosessen(e). Bedre kontroll, men mindre endringsdyktig, robust og skalerbar • Koreografi. En komponent reagerer på hendelser og utfører sin oppgave. Typisk eventdrevet og distribuert. Mer endringsdyktig, robust og skalerbar, men mindre sentral oversikt og kontroll • Deployment • Trinnvis oppgradering eller utrulling av tjenester medfører behov for migrering som igjen fører til behov for versjonering • Versjonering • Ny funksjonalitet gir ny versjon. Saner gamle tjenester Kompensasjon; må være en tydelig forretningsbruk. Feil lar seg ofte ikke forutse; race-conditions Prosesstyring; sentral = BPEL, eller styrt fra ett system. Distribuert = EDA hvor komponentene raagere 28
- 29. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 29
- 30. Informasjonsutveksling 1 • En komponent ivaretar en mengde informasjon • En komponent har eierskap og myndighet over egen informasjon, og er kilden til den • Andre kan bare bruke eller påvirke informasjonen via komponentens tjenester • Det er viktig at informasjon mellom komponenter ikke overlapper (Master data: Det skal bare finnes en kilde for en gitt type informasjon) • Informasjonen skal publiseres på et tydelig og transportabelt format (xml) • En komponent som er kilde til informasjon er forpliktet til å fortelle om endringer på sine data 30
- 31. Informasjonsutveksling 2 • En komponent kan kopiere informasjon fra en annen (i det minste nøkler), men de kan ikke endres uten at kilden har bestemt det • Informasjon utveksles i form av meldinger, eksempelvis som følge av: • Et API kall • En asynkron melding • En event i kildekomponenten • Meldinger skal i størst mulig grad gjenbrukes selv om de ble utvekslet av forskjellig grunn eller på forskjellig måte 31
- 32. Meldingsutforming 1 • Utforming av melding er viktig for samhandling • Meldingsutforming kan grovt deles opp i: Transaksjons- Fordel: Meldingen inneholder informasjon fra en sentrisk komplett transaksjon. Eksempelvis et skjema Ulempe: Store transaksjoner gir store meldinger og kan være vanskelig å tolke av forbruker Datasentrisk Fordel: Meldingen inneholder et forretningsobjekt (eks. Person) og har en tydelig avgrensning Ulempe: Hvis mange endres seg i samme transaksjon, må forbruker sette dette sammen Eventsentrisk Eiende komponent skal informere om hendelser på sine data. Beskriver en domenehendelse og kan inneholde data tilhørende denne 32
- 33. Meldingsutforming 2 • Sekvensutfordringer oppstår når en forbruker har behov for å håndtere meldinger i en gitt rekkefølge • Utfordringen kan løses igjennom sekvensiell håndtering av meldinger, men dette skalerer ikke • Re-sekvens er mulig, men vanskelig / dyrt • Beste medisin for robust meldingsutveksling er klok utforming av meldinger (og samhandling) • Feil vil oppstå mellom komponenter og det er viktig at informasjonsutvekslingen kan gjentas • Feil vil oppstå og det er viktig at de oppstår der hvor det er kompetanse til å håndtere feilen 33
- 34. API og informasjonseksempel 34
- 35. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 35
- 36. Integrasjon 1 •Tjenestene må kunne kommunisere •Tjenestene må kunne kommunisere på et uniformt format •Tjenestene er ofte implementert på forskjellig teknologi •Integrasjonskomponenten danner isolasjon mellom forskjellige tjenester og gjør de mer uavhengige •Integrasjonskomponenten bør ikke påvirke tjenestenes hensikt og væremåte •Tjenester skal kunne samhandle effektivt, og integrasjonskomponenten bør være så tynn som mulig •En tjenestes hensikt skal være varig, mens integrasjonskomponenten skjermer teknologi og plattform •Tjenesten er bare toppen av ”isfjellet” 36
- 37. Integrasjon 2 •En ESB (Enterprice Service Bus) er en integrasjonsplattform •En ESB er ikke en tjenesteorientert arkitektur •ESB har typisk disse egenskapene • Tilkoblingsbar, Validering og transformasjon, Ruting, Sikkerhet, Pålitelighet, Forvaltning av tjenester, Overvåkning, logging og feilhåndtering •ESB’en blir hjertet og det er viktig å kunne overvåke • Svartider for distribuert ytelsestuning • Tjenesters bruk av tjenester, noe som er nødvendig for å analysere konsekvenser av handlinger på ESB’en • Mulighet for å gå inn for å rette opp i situasjoner: ad-hoc meldinger, manuell kompensering • På forretningsnivå for å kunne gjøre prosesser bedre eller å vite hva som foregår 37
- 38. Innhold • Bakgrunn • Tjenesteorientering • Komponenter • Tjenester • Samhandling • Informasjonsutveksling • Integrasjon • Oppsummering 38
- 39. Oppsummering •Store systemer er så vanskelige at ingen forstår alt •Løsningen og utfordringen ligger i å dele opp problemet •Uansett løs kobling så er det funksjonelle avhengigheter •Prisen å betale er en mer kompleks arkitektur •Gevinster å høste er endringskapasitet, tilgjengelighet, samhandling, gjenbruk, og bedret livsløp •Uten finansiering og samkjørte prosjekter, ingen tjenesteorientering •Fugl føniks ? •IOA – Informasjon Orientert Arkitektur? Det er på en måte som slanking; det ligger ikke bare hva du kan kjøpe (piller eller årskort på sats), men i ”toppetasjen” 39