Tjenesteorientering og distribuerte systemer

1

Tjenesteorientering -Distribuerte systemer

SITS – IS - UTVTormod Varhaugvik, 27 Mai 2010

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 PattersObligatorisk ! Etablert og anerkjentOgså programmeringsstandard for ”skalering inn i skyen”

3

Innhold

• Bakgrunn• Tjenesteorientering• Komponenter• Tjenester• Samhandling• Informasjonsutveksling• Integrasjon• Oppsummering

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

5

Bakgrunn – eksisterende situasjon (nesten)

DSFDet Sentrale Folkeregister

Sentraleregistre

LEPLikning,

EtterskuddsPliktige

LFPLikning,

ForkuddsPliktige

FOSFOrskudd. Sentralt

MVAMerVerdiAvgift

SLNSystem for Likning

av Næringsdrivende

ARAksjonær-Registeret

DSBDatastøttet

Selvangivelses-Behandling

FOIForskudd, Internett

WEBPSA

FOLFOrskudd, Lokalt

FLForhåndsLikning

LNALokalt Navn og Adresseregister

Enhets-registeret

Kommuneregisteret

Adresse-registeret

Arveavgift(gamle)

Manntall

PSAPreutfylt

SelvAngivelse

OS390/Cobol/DB2

IBM AS/400

Unix/Sybase

Unix/Pro-IV

Unix/Oracle

Eiendomsregisteret

SOFIESkatte-

regnskapet

Altinn

Datavarehus

IBM AS/400

SFUSentral-

skattekontoret For

Utenlandssaker

MVA-Mainframe

sentral MVA

Transparent Gateway (TG)

Ftp-overføring

Databaselink

MQseries

EksternIntern

Fonsa

GLDGrunnLagsData

Arveavgift(nye)

Er en del av MVA-løsningen

Internett/Web

Både TG og MQseries

View-oppslag mot tabeller

InterConnect

Oppslag på fil

Intern

Ekstern

Kommunikasjons-grensesnitt

Plattform

Systemkart

Tinglyste hjemmels-overganger

Ftp-overføring og TG

* samme grensesnitt

*

Ftp-overføring og DVD

Slik er det mange steder.Grunnen er mange; hver forvaltningsområde sitt systemprosjekter har et fokusert mandat, vi må ha noe kjapt og enkelt, eller rett og slett ingen overordnet prioritering eller styring innenfor IT-arkitektur

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æringslivArbeide for å bygge fellesløsninger for offentlig sektor og være pådrivere for å effektivisere arbeidsprosessene på tvers av offentlig sektorOpprettholde høy fokus på tilgjengelighet, sikkerhet, kvalitet (testing) og etikkSikre 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

7

SKD Strategiprinsipper for IT

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

Livsløp

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

Gjenbruk

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

Endringskapasitet

Funksjonalitet skal tilbys på en slik måte at det er enkelt åsamhandle innen og med etaten

Samhandling

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

Integritet

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

Brukervennlighet

Funksjonalitet skal være lett tilgjengelig for brukerne der og når de trenger det

Tilgjengelighet

Tilgjengelighet Funksjonalitet skal være lett tilgjengelig for brukerne der og når de trenger detBrukervennlighet 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øresIntegritet 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/innbyggereSamhandling Funksjonalitet skal tilbys på en slik måte at det er enkelt å samhandle innen og med etatenEndringskapasitet 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 prisrammeGjenbruk Gjenbruk skal prioriteres, både ved å velge allerede gjenbrukbar funksjonalitet fremfor ny utvikling/anskaffelse og ved å investere i gjenbrukbarhet ved utvikling/anskaffelse av ny funksjonalitetLivslø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?

8

Innhold


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.

10

Lager

Tjenesteorientering – Samarbeid

Butikk

Egenskaper

Systemene har forskjellige oppgaver, men er avhengige av hverandre og trenger å samarbeide

Livssyklus

Prosess

gjennomgående må man kjenne til tilstanden på entiteter som man bruker og som tilhører annet systemLivssyklus 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.

11

TO - Nedbrytning

•I stort og smått dreier mye seg om god modularisering

Protokoll for bruk av tjenestene. Kulturen i det distribuerte systemet

Samhandling

Kommunikasjon mellom tjenester. Limet mellom komponentene i det distribuerte systemet

Integrasjon

Informasjon som tilbys av tjenesten. I form av meldinger, attributter i API’er eller skjermbilder

Informasjon

Komponentens hensikt. Beskriver de funksjoner som komponenten kan oppfylle

Tjenester

Splitt og hersk! Funksjoner og data som hører sammen. ”Domain Driven Design”

Komponenter

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 kompleksitetDe to nederste er mer spesifikke for uavhengige systemerHvordan kan vi lage

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 )

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 = PatternsSelv 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 relevantPostjournalen til Plan og bygg er nok nattlig kopiering av data. Man spør ikke saksbehandlingssytemeteller yr.no portalen er ikke værregnemaskinen!

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…

15

Innhold


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.

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 utfordringeneVi sitter tross alt på vår egen portefølje og kan gjøre noe med komponetene og tjenesene.

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

19

Innhold


20

Tjeneste 1 – Egenskaper

Ikke-funksjonelle egenskaperQoSEks. sikkerhet, administrasjon og overvåkningTekniske

Å kunne delta i en større sammenheng, kanskje spesielt for brukergrensesnitt

Sammensettbar

Robusthet bedres hvis det ikke betyr noe om noe kalles en eller flere ganger

GjentagbarTjenesten skal ikke være i dialog med forbrukerTilstandsløsKan ikke gjenbruke noe ingen finner!Oppdagbar

Må ha rett abstraksjonsnivå, avveining mellom ytelse og vedlikeholdbarhet

Grovkornet

Tjenester skal kunne kjøre slik den er eksponert, den skal ikke måte forutsette for mye

Selvberget

I motsatt fall trenger komponenten ikke åeksponere den

Gjenbrukbar

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 kundenummSammensettbar: Man trenger ikke bruke Webservices eller BPEL inne i dette.

21

Tjenestetyper 1 - Målbilde

• Integrasjonsklassifisering sier noe om hva de kan brukes til

Tjeneste for menneskerDisse kan sømløst knyttes sammenBrukeren skal ikke merke hvilket komponent han jobber mot

Brukerdialog-

Tjeneste utføres basert på en hendelseSignaliserer til andre om endringen

Hendelses-

Tjeneste som tilbyr data (behov for data annet sted)Data-

Tjeneste som tilbyr en funksjon eller beregningHar ikke nødvendigvis tilstand eller varig datalager selv

Funksjons-

FunksjonsintegrasjonIntegrasjonsformen er basert på integrasjon hvor systemer kaller hverandres tjenester for å få utført en op

HendelsesintegrasjonDenne 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 hensiktsmesssystemet kan bruke funksjonsintegrasjon eller dataintegrasjon for å få flere detaljer angående hendels

DataintegrasjonDenne 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 pBrukerdialogintegrasjon

Integrasjonsformen kalles ofte for GUI-integrasjon. Denne integrasjonsformen baserer seg på direkte bruURL og deretter utføre et stykke arbeid. URL kan inneholde parametre slik at den kallende applikasj

22

Tjenestetyper 2 - Legacy

Implementerer en prosess av andre tjenester Den har tilstandDen viktige designbesluttingen ligger i hvor tilstanden skal tas vare på og hvor lenge

Process

Den er satt sammen av basistjenesterTjenesten er definert fordi det er mer effektivtTilbyr en forretningsfunksjon som utføres på flere bakenforliggende systemerSannsynligvis 2-phase commit for ha ACID

Sammensatt

Både business og IT skjønner hva tjenesten gjørACID (Atomic, Consistent, Isolated, Durable)

Basis

23

Systemeksempel – Eventdrevet arkitektur

Meldings-lager og formidler

Butikk Assortement

Ekstern

AutorisasjonPris Arbeidsflyt

B3B2

B1

Innkjøp

AHA1

A2

N1

S1B1

B2B3

S1

AHA1

A2

AH

Egenskaper:Forklar flyten i systemet, Events data og reaksjoner i systemer som mottar en meldingGjenbruk av brukergrensesnittWorkflow som generell saksbehandlingskomponent Authorization og rolle i sikkerhet

Utfordringer:Meldingsegenskaper, sekvenshåndtering, global transaksjonsmekanisme.Feil mellom systemene. Køer som stopper

24

Innhold


25

Samhandling 1

• Sterk og svak kobling mellom komponenters tjenester

Eksplisitt – implisittVersjonshåndtering

Simultan – trinnvisI driftsetting

2-fase – kompensasjonTransaksjonshåndtering

Like – ulikePlattform

Statisk – dynamiskBinding

Sentral – distribuertProsesstyring

Sammensetting – komplettSamkvemsmåter

Sterk – svakTyping

Komplekse – enkleDatamodell

Synkron – asynkronKommunikasjonPunkt-punkt – formidlerForbindelse

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, soTyping: Attributter kontra key-value. Avhengige meldinger (bruke tjenester eller sette sammen med andre medlinger)sentral = Orkestrert, desentral = Koreografibinding; 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.

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 = Koreografibinding; kontroll ved kompilering eller ved kjøring?Deployment; tjenesteorientering er å kunne slippe sporadisk Men hv med cross-cutting changes? De kaVersjon: eksplisitt -> bygge på nytt. impisitt sikrer bakoverkompabilitet (nummer regime+++)Kan utmerket godt integrere uten bruk av BUSS…Endringer bør ikke treffe transporten.

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 datamodellenProtokoll gir fleksibilitet, men ikke så tydelige brukAPI gir tydelig bruk og er god programmeringsskikk, men slår når de skal deployesKanonisk format må eies av en Modul, gir en betydelig organisatorisk effekt

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-conditionsProsesstyring; sentral = BPEL, eller styrt fra ett system. Distribuert = EDA hvor komponentene raagere

29

Innhold


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

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

32

Meldingsutforming 1

• Utforming av melding er viktig for samhandling• Meldingsutforming kan grovt deles opp i:

Eiende komponent skal informere om hendelser på sine data. Beskriver en domenehendelse og kan inneholde data tilhørende denne

Eventsentrisk

Fordel: Meldingen inneholder et forretningsobjekt (eks. Person) og har en tydelig avgrensningUlempe: Hvis mange endres seg i samme transaksjon, må forbruker sette dette sammen

Datasentrisk

Fordel: Meldingen inneholder informasjon fra en komplett transaksjon. Eksempelvis et skjemaUlempe: Store transaksjoner gir store meldinger og kan være vanskelig å tolke av forbruker

Transaksjons-sentrisk

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

34

API og informasjonseksempel

35

Innhold


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”

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

38

Innhold


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”

Technology

Tjenesteorientering og distribuerte systemer