Distribuerede objekter

Vi har et gældende arkitekturprincip: ”Alle data er uafhængige af systemet, hvor de opbevares”. Det er altså ikke systemet, der ejer data eller et bestemt forretningsobjekt. Systemer har kun objekter (eller forekomster af det) til ”låns” – og mange systemer kan have brug for det samme objekt på samme tid. Tænk bare på SAPA, der eksempelvis har brug for Sags-objektet fra mange forskellige andre systemer og brugerne af SAPA skal opfatte Sagerne som Sager og ikke tænke på hvor de ellers ”bor”.

• Et distribueret objekt er et objekt, der ”lever” flere steder på en gang og som, af anvenderen, opfattes som det ”rigtige” objekt, uanset om man læser på den ene eller det anden udgave af samme objekt.

I Rammearkitekturen er objekter (via byggeblokke) kun beskrevet én gang og den fælles definition af et forretningsobjekt er forudsætningen for, at et objekt kan være distribueret. Google Drive, SkyDrive, DropBox etc. er alle eksempler på mekanismer, som gør at objekter bliver lokationsuafhængige. Hvor er ”originalen”? Den er alle steder og ingen steder på en gang. Hvem der må tilgå objektet (oprette, læse, opdatere etc.) er et rettighedsspørgsmål og IKKE et lokationsspørgsmål.

Eksempel: Objektet SAG har vi, som udgangspunkt, i et fagsystem eller et ESDH-system. I en ikke-monopol-verden, kan systemer, der har brug for sagsinformation driftes helt andre steder end der, hvor sagen, som udgangspunkt er. Det kan løses ved at kalde på tværs af driftleverandører med den udfordring, at alle skal vide hvor en bestemt sag findes (der kan være mange driftsteder) og det tager tid at kalde på tværs af leverandører.

Det kan også løses ved at oprette Sag som et distribueret objekt, hvor sagsobjektet nu ”lever” flere steder på én gang. Det oprettes i eget driftmiljø og det er let at tilgå det fra sine systemer. Ydermere har det den fordel, at man kan oprette nye sager, som så ”automatisk” falder på plads i de andre udgaver af det distribuerede objekt. Betragtningen af, hvad der er original og hvad der er kopi bliver udflydende i en distribueret verden, med mindre der opsættes forretningsmæssige regler om, at der KUN må opdateres i den ene forekomst af objektet, som det f.eks. er tilfældet for PERSON, som kun må vedligeholdes af CPR.

Synkronisering af objekterne

For at distribution fungerer, skal der skabes en synkroniseringsmekanisme mellem de forskellige implementeringer af samme objekt. Umiddelbart skulle man tro, at de forskellige forekomster af samme objekt skal kende hinanden godt og at der skal solide aftaler og snitflader til, for at de kan opdatere hinanden, men det er ikke tilfældet. I en løst koblet arkitektur er det vores ønske, at de IKKE nødvendigvis skal kende hinanden.

Forudsætningen for at det kan lade sig gøre er, at de begge har samme opfattelse af objektet, som de kan opnå ved at anvende samme standard. I dette eksempel SAG-standarden.

Den anden forudsætning er, at der udsendes en besked til omverdenen, når objektet ændres (der oprettes en ny instans eller en instans ændres), indeholdende hele objektet. Der sættes et abonnement op de steder, hvor objektet ”bor” og dermed får alle besked, hvis et objekt af samme type ændres et eller andet sted i verden. Med indholdet af beskeden kan ens egen udgave af objektet opdateres.