Få et gratis link til den nye mobile udgave af Version2
Swarco Technology ApS
Saxo Bank A/S
Grundfos A/S
KMD
Forfatter og projektchef hos Devoteam
Hændelser, en vigtig ingrediens i SOA!
Som lovet i "Hændelser er vigtige for forretningen" kommer her en ny blog om hændelser. Dette indlæg handler om, hvorfor jeg ser hændelser som en naturlig og vigtig ingrediens i en SOA.
SOA er en tilgang til distribueret computerbehandling, hvor softwarefunktionalitet tilbydes som services på et netværk.
En hændelsesbaseret arkitektur er en tilgang, hvor en forretningshændelse afstedkommer, at en asynkron besked sendes mellem uafhængige softwareenheder. Beskeden er envejs i forhold til service-interaktioner, hvor kommunikationen typisk er en tovejs anmod/svar-kommunikation mellem en serviceforbruger og en serviceleverandør.
Hændelsesbaseret arkitektur er ikke en separat arkitektur-tilgang, men er et væsentlig element i, hvordan en virksomhed bør implementere SOA.
Fokus på forretningshændelser
Princippet i hændelser har været kendt længe på et teknisk niveau inden for systemsoftware såsom operativsystemer, netværk- og systemhåndteringsværktøjer. Det er ikke disse hændelsestyper, som der skal fokuseres på. Fokus vil være på hændelser, der sker i relation til organisationens forretningsområde.
En hændelse er information om, at noget er sket; et servicekald er et ønske om, at noget skal ske.
En afsendelse af en indkøbsordre til en leverandør er et servicekald, udsendelse af information om, at ”indkøbsordre er afsendt” eller ”indkøbsordre er modtaget” er en hændelse.
En hændelsesafsender sender typisk beskeden gennem noget middleware (kaldet en sink), som er ansvarlig for håndtering af abonnenterne på de enkelte hændelsestyper. Sinken offentliggør beskeden til de enheder, som abonnerer på hændelsen. Abonnenterne vil derefter foretage sig nogle aktiviteter baseret på hændelsen. Disse aktiviteter er helt uvedkommende for afsenderen af hændelsen og vil være forskellige for de enkelte modtagere.
Når der diskuteres it-arkitektur, er det typisk beskeden, der sendes mellem softwareenhederne, der betragtes som hændelsen. Selve hændelsen indkapsler en specifik aktivitet og er en komplet beskrivelse af denne.
Hvornår er det en service og hvornår er det en hændelse?
Når jeg præsenterer hændelseskonceptet, er der ofte nogle, der begynder en diskussion mellem hvornår er det en hændelse og hvornår er det en service?
En ”rigtig” hændelse har følgende karakteristika:
Der vil altid være gråzoner, hvor det kan diskuteres om det er en service eller en hændelse, men det er ligegyldigt. Det vigtige er, at forretningen tænker og forstår konceptet og forretningsmulighederne omkring hændelser og selvfølgelig også services.
I elektronisk tinglysning opererer vi med både services og hændelser og nogle der ligger i en gråzone:
Central komponent
Hændelsesbaseret design vil blive en central komponent i forretningsarkitekturen og i it, fordi det giver muligheder for at understøtte dynamiske og mangesidede forretningsprocesser.
Hændelser vil komplementere, ikke udskifte, services i en serviceorienteret arkitektur, og services og hændelser bør derfor ikke betragtes som to separate koncepter. Det er gennem en kombination af serviceorientering og hændelsesbaseret design, at virksomheden vil opnå den ønskede behændighed.
SOA er en tilgang til distribueret computerbehandling, hvor softwarefunktionalitet tilbydes som services på et netværk.
En hændelsesbaseret arkitektur er en tilgang, hvor en forretningshændelse afstedkommer, at en asynkron besked sendes mellem uafhængige softwareenheder. Beskeden er envejs i forhold til service-interaktioner, hvor kommunikationen typisk er en tovejs anmod/svar-kommunikation mellem en serviceforbruger og en serviceleverandør.
Hændelsesbaseret arkitektur er ikke en separat arkitektur-tilgang, men er et væsentlig element i, hvordan en virksomhed bør implementere SOA.
Fokus på forretningshændelser
Princippet i hændelser har været kendt længe på et teknisk niveau inden for systemsoftware såsom operativsystemer, netværk- og systemhåndteringsværktøjer. Det er ikke disse hændelsestyper, som der skal fokuseres på. Fokus vil være på hændelser, der sker i relation til organisationens forretningsområde.
En hændelse er information om, at noget er sket; et servicekald er et ønske om, at noget skal ske.
En afsendelse af en indkøbsordre til en leverandør er et servicekald, udsendelse af information om, at ”indkøbsordre er afsendt” eller ”indkøbsordre er modtaget” er en hændelse.
En hændelsesafsender sender typisk beskeden gennem noget middleware (kaldet en sink), som er ansvarlig for håndtering af abonnenterne på de enkelte hændelsestyper. Sinken offentliggør beskeden til de enheder, som abonnerer på hændelsen. Abonnenterne vil derefter foretage sig nogle aktiviteter baseret på hændelsen. Disse aktiviteter er helt uvedkommende for afsenderen af hændelsen og vil være forskellige for de enkelte modtagere.
Når der diskuteres it-arkitektur, er det typisk beskeden, der sendes mellem softwareenhederne, der betragtes som hændelsen. Selve hændelsen indkapsler en specifik aktivitet og er en komplet beskrivelse af denne.
Hvornår er det en service og hvornår er det en hændelse?
Når jeg præsenterer hændelseskonceptet, er der ofte nogle, der begynder en diskussion mellem hvornår er det en hændelse og hvornår er det en service?
En ”rigtig” hændelse har følgende karakteristika:
- Afsenderen har ingen afhængighed til, hvad modtageren gør med beskeden
- Der sendes intet forretningsmæssigt svar tilbage. Dog ofte en teknisk bekræftelse på modtagelse af beskeden
- Hændelsen udsendes når den sker (dvs. ingen batch opsamling der udsendes i løbet af natten).
- Modtageren har oprettet abonnement på hændelsen
- Meddelelsen indeholder forretningsrelevant information
Der vil altid være gråzoner, hvor det kan diskuteres om det er en service eller en hændelse, men det er ligegyldigt. Det vigtige er, at forretningen tænker og forstår konceptet og forretningsmulighederne omkring hændelser og selvfølgelig også services.
I elektronisk tinglysning opererer vi med både services og hændelser og nogle der ligger i en gråzone:
- Helt klart en service: Forespørg på ejendom
- Jeg ser det som en service: Når der indsendes en anmeldelse kommer, der et øjeblikkeligt svar om, at den er modtaget. Når den er behandlet (efter f.eks. 15 sek.) kommer der et asynkront svar retur til anmelderen. Jeg betragter dette som svaret på servicekaldet
- Helt klar en hændelse: Hver gang der sker en tinglysning udsendes en hændelse til alle, der abonnerer på den pågældende ejendom
- Jeg mener også, dette er en hændelse: Når der tinglyses et skøde, sender e-TL en asynkron besked til beliggenhedskommunen og SKAT. De abonnerer ganske vist ikke selv, men jeg ser det som et lovpligtigt tvangsabonnement.
Central komponent
Hændelsesbaseret design vil blive en central komponent i forretningsarkitekturen og i it, fordi det giver muligheder for at understøtte dynamiske og mangesidede forretningsprocesser.
Hændelser vil komplementere, ikke udskifte, services i en serviceorienteret arkitektur, og services og hændelser bør derfor ikke betragtes som to separate koncepter. Det er gennem en kombination af serviceorientering og hændelsesbaseret design, at virksomheden vil opnå den ønskede behændighed.
Bliv klogere på artiklens emner i Version2's gruppeunivers:
Eclipse.dk
Enterprise Architecture
Mainframe
Når nu SOA og tinglysning er oppe at vende er jeg nygerrig på, om der er defineret noget fælles genbrug af tjenester baseret på hændelser i forbindelse med såvel tinglysning i fast ejendom og tinglysning i skibe.
Arbejdet i Skibsregistret – som hører til i Søfartsstyrelsen - kan sammenlignes med det, der udføres i Matrikelstyrelsen og på tinglysningskontorerne i relation til fast ejendom. Når et skib optages i ét af registrene, bliver det officielt et stykke dansk territorium, hvor dansk ret gælder, og hvor der er ret til at føre dansk flag.
Skibet får tildelt kendingsbogstaver (matrikelnummer). Der er herefter mulighed for at foretage rettighedsregistreringer i form af registrering af ejerret (skøder osv.), pant, brugsrettigheder. Når et lån er registreret i Skibsregistret, har det samme virkning som tinglysning af pant i fast ejendom i land. Det beskytter långiveren mod ejerens dispositioner og kreditorer.
Arbejdet i Skibsregistret – som hører til i Søfartsstyrelsen - kan sammenlignes med det, der udføres i Matrikelstyrelsen og på tinglysningskontorerne i relation til fast ejendom. Når et skib optages i ét af registrene, bliver det officielt et stykke dansk territorium, hvor dansk ret gælder, og hvor der er ret til at føre dansk flag.
Skibet får tildelt kendingsbogstaver (matrikelnummer). Der er herefter mulighed for at foretage rettighedsregistreringer i form af registrering af ejerret (skøder osv.), pant, brugsrettigheder. Når et lån er registreret i Skibsregistret, har det samme virkning som tinglysning af pant i fast ejendom i land. Det beskytter långiveren mod ejerens dispositioner og kreditorer.
Den viden jeg har omkrig skibsregisteret er, at det umiddelbart vil kunne indgå som et objekt i e-TL løsningen. Den enste forskel er, at pantet typisk er noget større i skibe
Når vi er færdige med fast ejendom kommer pant i biler, andelsboliger og løsøre. De vil indgå helt naturligt i e-TL ved at udvide objektet til at inkluderer stelnummer, andelsbolig ID osv.
Skibe vil kunne indgå på samme måde.
Så min vurdering er, at det er en mindre opgave at inkludere pant i skibe
Når vi er færdige med fast ejendom kommer pant i biler, andelsboliger og løsøre. De vil indgå helt naturligt i e-TL ved at udvide objektet til at inkluderer stelnummer, andelsbolig ID osv.
Skibe vil kunne indgå på samme måde.
Så min vurdering er, at det er en mindre opgave at inkludere pant i skibe
Glimrende diskussion, Henrik. Jeg ser helt klart et behov for at udbrede kendskabet til hændelser og ikke mindst at få hændelse indplaceret i forhold til services.
Det er også vigtigt at få kvalificeret hvad arkitektur-mønstre som SOA og hændelser kan bruges til og få det relateret til fx batch-arkitekturmønsteret. Jeg ser for mange, der forsøger at implementere SOA som overbygning på batch-systemer i stedet for at gøre op med det forretningsmæssige behov for batch.
Sidst er det essentielt for at SOA kan få succes, at det kun bruges i de situationer hvor mønsteret giver en god løsning. De situationer kan enterprise arkitektur bidrage med at identificere.
Det er også vigtigt at få kvalificeret hvad arkitektur-mønstre som SOA og hændelser kan bruges til og få det relateret til fx batch-arkitekturmønsteret. Jeg ser for mange, der forsøger at implementere SOA som overbygning på batch-systemer i stedet for at gøre op med det forretningsmæssige behov for batch.
Sidst er det essentielt for at SOA kan få succes, at det kun bruges i de situationer hvor mønsteret giver en god løsning. De situationer kan enterprise arkitektur bidrage med at identificere.
Enig omkring batch, væk med det! Det understøtter ikke forretningens konkurrencesituation i en online verden hvor dets konkurrenter kan have direkte adgang til opdateret funktionalitet, data og forretningshændelser
I e-TL har vi dog valgt en pragmatisk løsning hvor hændelser opsamles og først sendes ud når kapaciteten f.eks. er under 60%. En pragmatisk løsning som man initielt godt kan leve med, især fordi at man i opstarten har meget svært ved at vurdere hvor mange der vil oprette abonnement og derved dimensionere løsningen korrekt.
I e-TL har vi dog valgt en pragmatisk løsning hvor hændelser opsamles og først sendes ud når kapaciteten f.eks. er under 60%. En pragmatisk løsning som man initielt godt kan leve med, især fordi at man i opstarten har meget svært ved at vurdere hvor mange der vil oprette abonnement og derved dimensionere løsningen korrekt.
Jeg vil godt grave lidt mere i ”enterprise arkitektur” og elektronisk tinglysning.
Hvis vi betragter staten som ”enterprise” har staten en række ”business units” som udfører tinglysning. Ejendomme er det mest kendte område, men der er så også skibe og biler som eksempler på andre større områder.
Staten har så igangsat et projekt i forhold til tinglysning i ejendomme, hvor SOA komponenter og tankegang indgår, tilsyneladende uden at der er gennemført en samlet arkitektur øvelse omfattende hele staten (det lyder også voldsomt) eller i hvert de ”business units”, som laver tinglysning.
Specielt omkring skibe har dette område i øvrigt været digitaliseret i mange år.
Jeg har 2 points:
• Sommetider indføres SOA altså ”buttom-up”. Der laves nogle tjenester i første omgang til brug på et område, og så kan de senere (forhåbentlig) udbredes til andre områder. Sådan er livet ude i virkeligheden.
• At staten så bruger penge på at udvikle og vedligeholde 2 (eller flere) særskilte applikationer til tinglysning er måske en værre sag.
Hvis vi betragter staten som ”enterprise” har staten en række ”business units” som udfører tinglysning. Ejendomme er det mest kendte område, men der er så også skibe og biler som eksempler på andre større områder.
Staten har så igangsat et projekt i forhold til tinglysning i ejendomme, hvor SOA komponenter og tankegang indgår, tilsyneladende uden at der er gennemført en samlet arkitektur øvelse omfattende hele staten (det lyder også voldsomt) eller i hvert de ”business units”, som laver tinglysning.
Specielt omkring skibe har dette område i øvrigt været digitaliseret i mange år.
Jeg har 2 points:
• Sommetider indføres SOA altså ”buttom-up”. Der laves nogle tjenester i første omgang til brug på et område, og så kan de senere (forhåbentlig) udbredes til andre områder. Sådan er livet ude i virkeligheden.
• At staten så bruger penge på at udvikle og vedligeholde 2 (eller flere) særskilte applikationer til tinglysning er måske en værre sag.
Tinglysningssystemet er designet med genbrug for øje. Blandt andet var vi ikke blinde for at f.eks. skibsregistret kunne anvende dette og som sagt vurderer vi, at de vil passe til e-Tl som legoklodser. Det samme gælder i øvrigt fly
Vi har også designet flere af komponeterne som generelt offentlige genbrugelige services. F.eks. en generel offentlig Fuldmagtsbog
Der var i kravspecifikationen stillet krav om at Infrastrukturkompnenterne kunne bruges generelt i Domsstolsstyrelsen. Det har så senere vist sig at softwaren ikke var tilstrækkelig moden, så DSS ikke, som en "gratis" følgevirkning, fik en SOA-infrastruktur op at køre.
Så muligheden er til stede for at staten genbruger e-TL og dets komponenter og det har været tænkt ind fra starten
Vi har også designet flere af komponeterne som generelt offentlige genbrugelige services. F.eks. en generel offentlig Fuldmagtsbog
Der var i kravspecifikationen stillet krav om at Infrastrukturkompnenterne kunne bruges generelt i Domsstolsstyrelsen. Det har så senere vist sig at softwaren ikke var tilstrækkelig moden, så DSS ikke, som en "gratis" følgevirkning, fik en SOA-infrastruktur op at køre.
Så muligheden er til stede for at staten genbruger e-TL og dets komponenter og det har været tænkt ind fra starten
Du har helt ret i at en af de typiske implementeringer af SOA er at en virksoehd skal have en ny løsning og den kravspecificers og designes derfor serviceorineteret, uden at organisationen har en færdig SOA-strategi.
Det er selvfølgelig ikke den ideelle verden, men jeg ser det nu ikke som et stort problem. Da den opnåede erfaring vil få virksomehden til at forstå hvordan de serviceorienterer på deres måde. Hvis de startede med teorien først, risikere man at beskrive noget, som ikke har hold i virkeligheden (Jeg har set sådanne eksempler).
Så en velgennemtænkt kravspec af det først serviceorienterede projekt kan være en god start
Det er selvfølgelig ikke den ideelle verden, men jeg ser det nu ikke som et stort problem. Da den opnåede erfaring vil få virksomehden til at forstå hvordan de serviceorienterer på deres måde. Hvis de startede med teorien først, risikere man at beskrive noget, som ikke har hold i virkeligheden (Jeg har set sådanne eksempler).
Så en velgennemtænkt kravspec af det først serviceorienterede projekt kan være en god start
Hej Henrik,
Du skal uddybe hvad du mener med at et event sender en komplet beskrivelse af en specifik aktivitet?
Lad os tage et eksempel på hvad jeg tror du ikke mener, så er du nok mere på sporet af en forklaring.
en service GemBudget kaldes og Event BudgetOpdateret sendes ud. Jeg går ud fra at du mener at BudgetOpdateret indeholder information til at identificere hvilket budget der blev opdateret, men ikke de egentlige budgetdata?
/NEKO
Du skal uddybe hvad du mener med at et event sender en komplet beskrivelse af en specifik aktivitet?
Lad os tage et eksempel på hvad jeg tror du ikke mener, så er du nok mere på sporet af en forklaring.
en service GemBudget kaldes og Event BudgetOpdateret sendes ud. Jeg går ud fra at du mener at BudgetOpdateret indeholder information til at identificere hvilket budget der blev opdateret, men ikke de egentlige budgetdata?
/NEKO
Hændelsen skal indeholde nok information til at modtageren kan forstå hvad der er sket og kan reagere i henhold til dennes forretningskontekst.
Jeg ville derfor ikke forvente at hele budgettet blev sendt, men de væsentlige metadata omrking budgettet som du angiver. I nogle situationer kunne disse budgetmetadata godt indeholde differencen i forhold til forrige budget, hvis det kan give mening for modtageren.
I tinglysningen kan vi af afgiftsmæssige årsager kun fortælle at der f.eks. er tinglyst et skøde på en ejendom. Men uden afgiftsbegræsningen ville hændelsen sikkert også indeholde information om f.eks. køber og sælger
Jeg ville derfor ikke forvente at hele budgettet blev sendt, men de væsentlige metadata omrking budgettet som du angiver. I nogle situationer kunne disse budgetmetadata godt indeholde differencen i forhold til forrige budget, hvis det kan give mening for modtageren.
I tinglysningen kan vi af afgiftsmæssige årsager kun fortælle at der f.eks. er tinglyst et skøde på en ejendom. Men uden afgiftsbegræsningen ville hændelsen sikkert også indeholde information om f.eks. køber og sælger
Jeps, det er jeg helt enig i.
Har i udnyttet en CEP (Oracle, Drools eller lignende), eller anden middleware (ud over en ESB) til event håndtering/distribution?
Jeg mener at ESB'en er som skabt til event distribution. (JMS har jo plug'n'play publish/subscribe - med SAF og store lygter).
Herefter kan de enkelte subscribers så selv finde ud af om de kan gøre noget ved et Event.
Ydermere er fordelen at event oprettelse og afsendelsen baseret på service kald kan ske i ESB ligeså, og man kan derfor nemt får legacy systemer til at begynde at afsende events.
Har i udnyttet en CEP (Oracle, Drools eller lignende), eller anden middleware (ud over en ESB) til event håndtering/distribution?
Jeg mener at ESB'en er som skabt til event distribution. (JMS har jo plug'n'play publish/subscribe - med SAF og store lygter).
Herefter kan de enkelte subscribers så selv finde ud af om de kan gøre noget ved et Event.
Ydermere er fordelen at event oprettelse og afsendelsen baseret på service kald kan ske i ESB ligeså, og man kan derfor nemt får legacy systemer til at begynde at afsende events.
Jeg er enig med dig i at ESB virker attraktiv for hændelser, både til at afsende men også til at modtage, behandle og videredistribuere dem i organisationen
ESB'en blev fravalgt af forskellige årsager i starten af projektet, så hændelsesmotoren er designet af CSC.
ESB'en blev fravalgt af forskellige årsager i starten af projektet, så hændelsesmotoren er designet af CSC.
Kan du måske fortælle lidt om hvorfor ESB'en blev fravalgt? Eller hvorfor der ikke blev valgt et andet standardprodukt til håndtering af hændelser?
ESB har i mine øjne også den fordel at vi har overvågning af SLA og til dels QoS med i købet (vælger vi den rigtige ESB - ALSB som i nok havde valgt, grundet BEA/Oracle platform - er da et rigtig godt produkt, og fra version 3+ er den også blevet venlig at udvikle til).
ESB har i mine øjne også den fordel at vi har overvågning af SLA og til dels QoS med i købet (vælger vi den rigtige ESB - ALSB som i nok havde valgt, grundet BEA/Oracle platform - er da et rigtig godt produkt, og fra version 3+ er den også blevet venlig at udvikle til).
1- 7 timer siden - CSC sender IE6-aben videre: Sundhedsstyrelsen har fået, hvad de bad om (38)
- 11 timer siden - At rejse er at leve... (23)
- 17 timer siden - Hvem hacker min maskine? (23)
- 1 dag siden - Kommune dropper Microsoft og hopper i skyen: 'Openoffice er et unødvendigt mellemled' (116)
- 1 dag siden - Endnu en super god hjemmeside: Hvemkommer.dk (25)
- 2 dage siden - Dansk it-firma vil bruge Facebook-opskrift til at slå Google og Sharepoint (2)
- 2 dage siden - Oppositionens it-revser fylder 50 – men Parkinson tvinger hende ud af politik (1)
- 2 dage siden - Eik Bank beder kunder om pas-kopi via ukrypteret e-mail (50)
- 2 dage siden - Nyt værktøj til OOXML-arbejde (2)
- 2 dage siden - Digital tinglysning dumpede tre uger før lancering (2)
Seneste indlæg i denne blog
Redaktionen anbefaler
