Your SlideShare is downloading. ×
Tjenesteorientering og distribuerte systemer
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tjenesteorientering og distribuerte systemer

968

Published on

Presentasjonen inneholder en oppsummering av erfaringer fra SOA (tjenesteorientering), eventdrevne systemer, distribuerte systemer og det å drive slike systemer i praksis. Presentasjonen viser …

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
968
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 altOg 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- regnskapetSlik 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 ingenoverordnet prioriteringeller 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 sektorUtvikle flere og bedre elektroniske tjenester for innbyggere og næringslivArbeide for å bygge fellesløsninger for offentlig sektor og være pådrivere for å effektiviserearbeidsprosessene 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å nyemå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 kraveneTilgjengelighet Funksjonalitet skal være lett tilgjengelig for brukerne der og når detrenger detBrukervennlighet Elektroniske brukertjenester skal være tilpasset brukeren og dennesbruksmønster, legge til rette for effektiv bruk, samt sikre god kvalitet på oppgaven somutføresIntegritet Funksjonalitet skal tilbys i henhold til lover og regler, sikkert ogkonfidensielt, 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 innenog med etatenEndringskapasitet Alle løsningers funksjonalitet skal være fleksible nok til å kunne følgeforventede endringer i samfunnet og i etatens tjenester innen rimelig tid og prisrammeGjenbruk Gjenbruk skal prioriteres, både ved å velge allerede gjenbrukbarfunksjonalitet fremfor ny utvikling/anskaffelse og ved å investere i gjenbrukbarhet vedutvikling/anskaffelse av ny funksjonalitetLivsløp Ved utvikling og anskaffelser skal gevinst- og kostnadsbildet ta høyde forhelheten 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 arkitekturDette 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 å samarbeidegjennomgående må man kjenne til tilstanden på entiteter som man bruker og som tilhørerannet systemLivssyklus til de entiter som systemene behandler. Eier er forpliktet til å fortelle andre omnå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. bestillingsprosessenBegge tilbyr web bilder som brukerene har i sin browser, men brukeren skjønner ikkehvilket 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 modulariseringVil 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 harhvert sitt perspektiv).De tre øverste er vandlige i alle systemer også de som er lukket, men har ytterligerekompleksitetDe to nederste er mer spesifikke for uavhengige systemerHvordan 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 avhengigeLø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 arkitekturMø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! 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 prosjekterKontroll, 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 slikeEierskap 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å veienKonkret har eDialog disse utfordringeneVi 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ærerePoenget 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åkningDette er egenskaper for tjenester mellom distribuerte systemerGjenbrukbar; funksjonen er kanskje gjenbrukbar, men de ikke-funksjonelle kravene river den i filler. DDatatyper 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. 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 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 hensiktsmess systemet 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 p BrukerdialogintegrasjonIntegrasjonsformen 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 - LegacyBasis 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 ACIDProcess 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 ArbeidsflytEgenskaper:Forklar flyten i systemet, Events data og reaksjoner i systemer som mottar en meldingGjenbruk av brukergrensesnittWorkflow som generell saksbehandlingskomponentAuthorization og rolle i sikkerhetUtfordringer: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 – implisittEller 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 kanVersjon: 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 herreWebService 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. 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 tjenesterKompensasjon; 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 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 ensentrisk komplett transaksjon. Eksempelvis et skjema Ulempe: Store transaksjoner gir store meldinger og kan være vanskelig å tolke av forbrukerDatasentrisk Fordel: Meldingen inneholder et forretningsobjekt (eks. Person) og har en tydelig avgrensning Ulempe: Hvis mange endres seg i samme transaksjon, må forbruker sette dette sammenEventsentrisk 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

×