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.
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
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
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
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
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
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
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
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
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