En kollega till mig, Ulf Landgren, har skrivit en intressant artikel som jag gärna vill dela med mig till er. Det handlar om hur man skall hantera data i en SO-Arkitektur.
Varsågod Ulf:
Bl.a. problemet att göra join:ar vid SOA-arklitektur uppmärksammas ofta. Problemet har sin grund i att varje tjänst ska vara suverän och inte direkt (på annat sätt än genom meddelanden) tala med gemensamma databaser samtidigt som man vill ha separata SOA-tjänster för olika saker t.ex. order, artiklar och kunder.
En lösning är införandet av en typ av referensdata som är en sammanställning av data från flera källor. Sammanställningen är alltså mindre normaliserad. För att ajourhålla sammanställningen behövs någon form av replikeringsmekanism så att ändringar i källorna införs i sammanställningen.
Jag har funderat lite på olika sådana mekanismer. Vill renodla de olika alternativen så lång det går. Nedan är några förslag. Tacksam för kommentarer och tillägg!
När jag skrev det här första gången för någon veckor sedan frågade jag om det finns några vedertagna metoder eller standarder för detta. Jag tänkte då inte i form av produkter, men en bekant har sedan dess påpekat att olika integrationsprodukter gör just vad jag efterfrågar, men ofta med en centraliserad arkitektur. Antagligen är Microsoft Message Queuing (MSMQ) ett val man kan göra om man vill implementera mekanismerna. En standard inom området är tydligen WSA . Där WSE är Microsofts implementation?http://www.codeproject.com/useritems/SOA_PublisherSubscriber.asp
Scenario för nedanstående mekanismer
Man har en SOA-tjänst A som är informationsägare av data i en databas i A och ett antal B1, B2, B3 etc. som är prenumeranter och som håller egna kopior på information från databasen i A (och antagligen från andra källor.)
Endast A äger rätt att ändra databasen. B:na håller kopior på information i A:s databas.
1. Push-mekanism
A ansvarar för att B:na är uppdaterade. Vid varje ändring skickar A ut ett ändringsmeddelanden med all information nödvändig om ändringen till B:na. Ändringsmeddelandet innehåller alla ändrade rader (id på borttagna rader) och databasens versionsnummer (som stegas upp för varje ändring). B:na svara med ett kvitteringsmeddelande som innehåller versionsnumret. B:na köar internt upp inkomna ändringsmeddelanden och behandlar dem i nummerordning. (Ex. så behandlas inte meddelande 18 förrän meddelande 17 tagits emot och behandlats.) A skickar om meddelanden som inte kvitterats inom en viss tid. A håller en lista på alla utestående ändringsmeddelanden d.v.s. meddelanden som prenumeranter inte kvitterat.
Variant: A skickar inte ändringsmeddelanden med en gång utan skickar ut dem t.ex. en gång per dygn eller tidigare om tillräckligt många ändringar har ackumulerats.
Variant: Publisher Subscriber-modellen. D.v.s. B sätter själv upp sig som prenumerant på ändringar från A. Om A ska acceptera nya prenumeranter så måste a spara eller kunna återskapa gamla ändringsmeddelanden.
2. Pull-mekanism
B:na ansvarar var och en för att hålla sina databaser i synk med A:s. När varje B finner det lämpligt så frågar den A efter uppdateringar. A sparar ändringsmeddelanden som B:na kan hämta. B skickar meddelande till A när B:t lyckats uppdatera till en ny version. A behöver inte spara ändringsmeddelanden efter det att alla prenumeranter har uppdaterat. (Förutsatt att man inte ska stödja att nya B:n kommer till.)
3. Cache-mekanism (form av Pull)
B:na cashar posterna i sin databas. B hämtar posterna från A om de inte finns i B:s egen databas. Om de finns där så frågar B A om det finns en nyare variant (versionsnummer för databasposten). A svara antingen nej eller ja + ny data. Svarar A nej så använder B data från sin egen databas, Svara A ja så används data från A och så läggs det in i B:s cache (databas).
4. Blandade modeller
Förutom de mer renodlade modellerna där A eller B:na ansvarar för att B:na är uppdaterad kan man tänka sig att de delar ansvaret. T.ex. kan B ansvara för att varje gång som B går online meddela A detta och sedan är det A som push ar ut ändringarna till B.
/Ulf
Comments