Open source-løsning skal spare kommuner for CPR-opslag hos KMD

It-udfordringen: En ny, gratis løsning skal gøre det nemmere for kommuner at spare på opslag hos leverandører som KMD. Men konceptet med open source krævede lidt forklaring.

Hvorfor lade mange forskellige it-systemer hente samme oplysninger flere gange, fra forskellige eksterne datakilder, og betale for det hver gang, når man kan samle alle opslag og spare penge?

Det er kort sagt ideen bag den såkaldte CPR Broker, som skal hjælpe kommunerne med at få styr på alle de mange opslag, de kommunale it-systemer hver dag har i registre hos CPR-kontoret, KMD og andre datakilder om borgerne.

Ved at sætte en ekstra database ind mellem kommunernes it-systemer og de eksterne registre, kan man få samlet alle data ét sted, så nogle opslag bliver overflødige og kan klares internt.

Her fortæller Leif Lodahl fra Magenta om projektet, som blev udført for Gentofte Kommune og IT- og Telestyrelsen.

Hvad går projektet ud på?

»Kommuner har en hel masse systemer, som henter persondata fra en række forskellige kilder. Vi har identificeret mindst 18 it-systemer hos kommunerne, som henter data med CPR-nummer som nøgle, og hvert af systemerne har en proprietær integration med datakilden. Nogle bruger også flere datakilder samtidigt.

Vi skubber CPR Broker ind imellem datakilderne og it-systemerne, så kommunerne kan få et overblik over, hvilke datakilder de bruger til persondata. Samtidigt bliver alle data så stillet til rådighed på en standardiseret måde, efter IT- og Telestyrelsens standard PART.

De rå persondata kommer fra CPR-kontoret, men så beriger leverandørerne dem med ekstra information, så det passer til deres systemer. Og kommunerne betaler for alle disse opslag.

Først udviklede vi løsningen til Gentofte Kommune, og i version 2 har vi i samarbejde med IT- og Telestyrelsen opgraderet CPR Broker til at følge den nye standard på området, PART, som ikke var klar, da vi udviklede version 1. Nu bliver CPR Broker også testet i Ballerup og Odense.«

Hvad er målet med projektet?

»Ved at samle og flette alle de data, som kommunerne henter, beriger vi dem. Det kunne man ikke før. Det var kun i hvert enkelt it-system, man samlede data, og det sker proprietært.

CPR Broker giver også mere konsistente datakilder, fordi det hele bliver samlet. Der er forskellig opdateringsfrekvens på de forskellige datakilder, og derfor kan man ikke helt stole på, at de er opdaterede, når man får dem enkeltvis.

Mange oplysninger er også de samme, så med tiden kan kommunerne spare penge ved at reducere antallet af datakilder, man skal abonnere på.«

Hvilken teknologi indgår i projektet?

»Vi bruger en Microsoft SQL-database og .Net-programmering. Det ligger på en Microsoft IIS-server. Det var et pragmatisk valg, da Gentofte Kommune, som i første omgang drev projektet, kun bruger Microsoft-servere og ikke har Linux-servere. Og mange kommuner har på samme kun Microsoft-servere i kælderen.

Men vi er i øjeblikket i gang med at gøre det muligt at bruge MySQL eller en anden generisk database, så man selv kan bestemme. Vi forventer, at vi kan gøre det helt uafhængigt, så man ikke er tvunget til at have software fra en bestemt leverandør.«

Hvad var tidsplanen for projektet?

»Vi udviklede version 1 tilbage i 2009, hvor vi var to programmører på opgaven i tre måneder. Dengang var der jo ingen standard for de data, så vi opfandt bare selv et interface.

Så kom PART-standarden for persondata i 2010, og IT- og Telestyrelsen spurgte, om vi ville implementere den i CPR Broker. Det gjorde vi med med version 2, som var klar i februar 2011. Her var vi også to programmører på, siden november, men fik også assistance fra IT- og Telestyrelsen.«

Hvilke udfordringer stødte I på undervejs?

»Rent teknisk er OIOXML-skemaerne ret voldsomme og meget komplekse. Vi vidste, at der var meget høje kvalitetskrav, og at vi måtte være ekstremt præcise i vores implementering af standarderne. Vi udviklede CPR Brokeren parallelt med, at standarden var i høring, så der kom kommentarer og mindre ændringer undervejs. Men det var et vilkår, der var.

Ellers har udfordringen mest været at forklare konceptet ude hos kommunerne. Det er en applikation uden brugergrænseflade, så vi kunne ikke fremvise skærmbilleder. Den udveksler data mellem to andre applikationer, og det er svært at forklare.

Det var også svært at forklare business casen for at lave det som et open source-projekt. Vi ejer ikke koden, og kommuner kan downloade den gratis og installere den. Men det betød, at vi skulle skaffe sponsorer, og der har vi skullet forklare vigtigheden af, at leverandøren ikke ejer koden.

Hvis KMD eller CSC havde lavet den, skulle kommunerne betale et løbende abonnement, når produktet var klar, men her skulle sponsorerne have penge op af lommen på et tidligt tidspunkt, ligesom hvis man køber et hus som et projekt, der ikke er bygget endnu. Den forretningsmodel er forholdsvis ny for kommunerne.

Til gengæld ejer KMD eller CSC ikke koden, og kommunerne kan selv bestemme, hvad der skal ske fremover, og hvem der skal udvikle næste version. Det kan godt være nogle andre end os.«

Hvilke gode råd kan du give videre?

»I sådan et projekt som dette, der er så standardspecifikt, er det vigtigt at få IT- og Telestyrelsen med. Det har været så skønt at have deres arkitekter med, for de har en grundviden, som har sparet os for rigtig meget arbejde.

For open source-modellen gælder det om, at man skal have et community på plads, og man skal aftale hele modellen. Hvem har ansvaret for CPR Broker? Hvem bestemmer hvilke features, der skal med i den næste version? Og hvilken teknologi skal der bruges? Løsningen kan være at stifte en forening for CPR Broker med en bestyrelse, der så bestemmer over udviklingen.

Vi har fået mange gode råd fra IT- og Telestyrelsen om, hvordan man gør det levedygtigt. Der er flere open source-projekter i Danmark, der ikke når længere end version 1.0, fordi man glemmer at sikre sig, at der også i fremtiden er en governance-model for projektet. Man skal sikre sig et community, der forpligter.«

Kommentarer (35)

Erlo Haugen

Som jeg læser artiklen,virker brokeren som en slags proxy,der minimerer opslag i de eksterne databaser.For at det skal kunne spare opslag,må brokeren nødvendigvis gemme data fra disse databaser
lokalt.
et begynder at minde om registersamkøring,så man kan undre sig over om det er i tråd med gældende lovgivning?

Morten Andersen

Det er absurd at kommunerne betaler så store summer til CSC/KMD, at det kan betale sig med en sådan løsning. Et opslag i et CPR-register er IKKE rocket science og kræver ikke et enormt maskineri.

Tænk på hvor simpelt CPR-registret er. Alle kan gå ind og se deres personlige oplysninger. Jeg vil tro der er ca. 5 kilobyte oplysninger i gennemsnit, når man medtager adresseændringer osv. som sikkert er relativt sjældent forespurgte oplysninger. Kerne oplysningerne er under 1 K. Men lad os bare sige 5K. Med 6 millioner borgere bliver det altså 30 GB. Disse kan med lethed ligge i RAM på en ganske billig maskine - en commodity maskine med 4 kerne og den mængde RAM kan vel erhverves for en 10.000. Maskinen udstyres med noget så simpelt som en hashtabel* og vil kunne håndtere et enormt antal forespørgsler, da alt kører via RAM og med meget simple algoritmer. Det er ikke maskinen men højst netværket der er problemet. Men ikke desto mindre er jeg overbevist om at 4-5 af den slags maskiner kan klare hele landets behov, og der vil sikkert endda være stor overkapacitet. Et sådant system (inkl. opdatering af oplysninger, backup m.m.) vil inkl. lønninger til 2 personer (som får en del fritid) drives for 1,1 mio. kr. om året, en brøkdel af hvad KMG og CSC tjener - det dækker ikke engang blot en enkelt projektleder eller tilbudsarbejdet. Sørgeligt er det, men økonomisk tænkning har aldrig været det offentliges stærke side.

Jeg har ikke regnet på en cloud løsning (via f.eks. Amazon's cloud) men der er tilgengæld privacy problemer at tænke på.

  • Hvis man er rigtig smart, så udnytter man det virtuelle adresserum således at man kan bruge dette som en slag hashtabel - man omdanner simpelthen CPR-nummeret til adresse på hukommelsessiden/rne der indeholder oplysningerne. Opslagstiden er derved reduceret til en transaktion på hukommelsesbussen, d.s. nogle ns.
Finn Christensen

ja og lagring (mængde i periode) kan nok ikke afvises, da de nævnte baser jo er egnet til det formål.

Det der er mere mærkværdigt synes jeg er, at nogen kan finde på at reklamerer åbenlyst med ny angrebsflade på vores CPR, samt at anvende Windows IIS-server.

Vores CPR + tilknyttede data er efterhånden ikke særligt følsomme.. trist at naivitet bliver en generel holdning.

@Morten
Du forsimpler brugen af CPR-register, dine antagelser og beregninger holder ikke mere end de første 10-15 sekunder i byretten :)

CPR har en mere kompleks opbygning + anvendelse, end du overhovedet kan forestille dig (udefra).

Finn Christensen

Jeg opfatter, at du fortrinsvis tænker CPR som et online-register Morten, der servicerer forespørgsler udefra, men CPR anvendes også ifm. interne produktioner..

Prøv at lave en liste over alle du mener anvender/trækker på CPR-data - intern/ekstern
Opdel dem i krav til tidstro eller batch
Opdel dem i krav til at benytte subsæt af data
....
....

Jesper S. Møller

Nu skal man måske lige passe på at opdele et system i hvad der er egentlige krav til det, og hvad der er gået hen og blevet dets udformning fordi det er udviklet over en lang periode ("accidental complexity", om man vil).

CPR systemet var helt sikkert en bemærkelsesmæssig teknisk, politisk og organisatorisk bedrift da det blev stablet på benene i 1968, hvor et helt lands personstamdata blev gjort tilgængelig og der blev etableret integration på kryds og tværs. Men i år 2011 er datamængden ikke skræmmende, og det er kompleksiteten sådan set heller ikke -- redskaberne til at opbygge systemer, der kan håndtere begge områder er usammenligneligt meget bedre i dag.

Uha, ja, der er måske 15-20 entiteter i systemet -- man skal foruden personer og adresser jo lige huske værgemål, familierelationer, forældremyndighed, civilstand, og lad os bare tage distrikter, myndigheder og vejregisteret med selvom det helt afgjort er "accidental complexity" (disse data findes autoritativt andetstads og giver integrationsbøvl med inkonsistente data).
Datamodellen skal have selvfølgelig have register- og virkelighedshistorik, inkl. sporbarhed på hver enkelt ændring, og til dels også søgning (iht. Persondataloven).

På servicesiden er der både ajourføring og opslag (herunder eksterne), registerindsigt (den borgerrettede side), diverse "semantiske" system-til-system integrationer, f.eks. personstatusændring (f.eks. fødsel og død) og endelig abonnementsordning/dataeksport til administrativt og statistisk brug.

Ikke trivielt, men det er ikke rocket science.

Dér hvor det bliver grimt er nok snarere at alle nuværende krav og integrationspunkter som er opsamlet over så lang tid over i et nyt system, hvis altså alle snitflader skal bibeholdes, og der ikke kan ryddes op i f.eks. knopskudte forretningsregler, som kunne formuleres mere tydeligt ved et redesign, ja, så er det helt sikkert en ordentlig mundfuld...

Man kan læse en masse om CPR systemet, inklusiv de hjemmestrikkede kommunikationsprotokoller, dataformater, m.v., på http://cpr.dk

Jesper S. Møller

YMMV, men det er trods alt ikke uden udfordringer, hvis det skal blive godt. Det er i min erfaring aldrig hverdagsagtigt eller banalt at få f.eks. en brugergrænseflade med både virksomhedshistorik og registerhistorik til at virke overskuelig for brugeren. Men jeg er selvfølgelig begrænset af egne evner.

Morten Andersen

Jeg tror ikke vi er så uenige. Min første pointe er/var, at det er urimeligt at tage så store beløb for opslag i et så simpelt register (som det må være tilfældet når det ligefrem kan betale sig at lave nye systemer for at nedbringe antal opslag!). Den kompleksitet der ligger i at håndtere en Google søgning er størrelsesordener større end hvad CPR-systemet tilbyder, og er endda ganske gratis (pånær man skal se på en reklame, men det er ikke mange basseører Google får for det).

Mht. implementeringen af et komplet system er der selvfølgelig noget mere i det (og jeg siger ikke dette kan/skal gøres for 100.000), men som Nikolaj er inde på, skal man heller ikke overdrive hvor meget det er. CPR-systemet er ikke mere kompliceret end systemer som mange har implementeret i deres fritid 'for sjov', og til hobbybrug osv. Der er selvfølgelig nogle specielle krav ang. logning/sporbarhed/registrering osv. men disse ting er også trivielle sammenlignet med så meget andet. Og ofte har jeg endda gennem mine mange år set megen sjusk og "hurtige løsninger" netop på de punkter, selv i de 'dyre' systemer.

Sandheden er (og lad det blive mellem os, Version2-læserne!), at langt de fleste ting jo er lette at implementere... men at dette ingen hindring er for at det kan koste 3-cifrede millionbeløb, især i offentlige projekter. Problemet er, at de eneste der har en interesse i at holde prisen nede er skatteborgerne, og de har næsten ingen indflydelse. Politikerne tør sjældent blande sig, for hvis de sparer og lortet ikke virker, så vil de få skylden. Desuden aner de ikke et klap om hvad systemer skal koste. Leverandører, konsulentfirmaer, projektledere, usability eksperter, tester, programmører m.m. har en stor interesse i at blæse det hele en størrelsesorden eller to op... både hvad angår krav, specifikationer, implementering osv. Så snart de ser et stort opslået offentligt system, så er det med at hæfte sig på, og suge så længe man kan.

Al den megen tilsyneladende 'grundighed' fører kun til et dårligere og dyrere system, som med garanti bliver forsinket, hvis det overhovedet kommer. Og i så fald vil det med usvigelighed sikkerhed, på trods af den megen "grundighed" og fine udviklingsmetodikker, være ustabilt og have masser af mangler. Alt det megen "udenoms" fjerner fokus fra at implementere kernefunktionaliteten, som sikkert var ganske triviel.

Men hvor er det godt for IT-folkene - hvad skulle de dog lave hvis systemerne blev lavet effektivt?!

Nikolaj Brinch Jørgensen

Hej Morten,

Der er et ord for det du beskriver: Agile softwareudvikling. Med mantraer som The Simplest Thing That Can Possibly Work og YAGNI (You Ain't Gonna Need It). Eller mere almindeligt KISS.

Det er sjældent at disse bliver brugt i moderne IT systemimplementering. At diverse store leverandører af teknologi samtidigt får solgt kunderne en hær af ubrugbare produkter som de bare skal have (og som ikke fungere sammen, så en hel anden hær af konsulenter får fast arbejde med at forsøge at integrere dem), hjælper ikke på pris og situation.

Det ville være rart om der snart kunne komme andre boller på suppen. Til gengæld kender jeg nogle enkelte kunder som har set værdien i at starte med kernefunktionalitet, og ikke er bange for ikke at benytte vandfaldsmodeller mm.

Jesper Lund Stocholm

Hej Morten,

Sandheden er (og lad det blive mellem os, Version2-læserne!), at langt de fleste ting jo er lette at implementere

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været. På et tidspunkt var vi nok 100 personer på opgaven fra både indland og udland incl. organisationens egen medarbejdere.

På det tidspunkt snakkede min kone med en kollega, der var IT-supporter i deres organisation. Han konstaterede overfor hende over frokostbordet, at "det kan sgu da ikke være så svært. Jeg er sikker på, at hvis jeg og 5-6 af mine venner fik mulighed for det, så kunne vi lave systemet på tre måneder".

Med andre ord: dine ytringer er det mest uigennemtænkte jeg længe har hørt. Jeg læste selv udbuddet igennem fra ITST med henblik på et muligt bud på opgaven, men af forskellige årsager vurderede vi ikke, at det var noget for os. Men mit indtryk dengang var helt klart, at den udbudte pris for CPRBroker bestemt ikke var himmelhøj - snarere tværtimod. Alene "PART"-implementeringen var en udfordring - som Leif kommer ind på, så var den ikke færdiggjort da opgaven røg i udbud.

Du skriver, at det er absurd, at det kan betale sig med sådan en løsning - men er du overhovedet klar over, hvad CPRBroker kostede?

Find udbuddet frem og kom igen, når du har læst og forstået opgaven.

Morten Andersen

Jesper,

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været. På et tidspunkt var vi nok 100 personer på opgaven fra både indland og udland incl. organisationens egen medarbejdere.

På det tidspunkt snakkede min kone med en kollega, der var IT-supporter i deres organisation. Han konstaterede overfor hende over frokostbordet, at "det kan sgu da ikke være så svært. Jeg er sikker på, at hvis jeg og 5-6 af mine venner fik mulighed for det, så kunne vi lave systemet på tre måneder".

Med andre ord: dine ytringer er det mest uigennemtænkte jeg længe har hørt.

Jeg forstår ikke dit argument? Du har ikke godtgjort, at IT-supporten ikke kunne have ret. Tværtimod har du indrømmet at projektet endte i en kæmpeskandale, på trods af de >100 medarbejdere -- så den model var åbenbart heller ikke svaret? Men du mener måske det er åbenlyst, at når 100+ eksperter ikke kunne løse det, så kan 5-6 venner absolut heller ikke? For mig er dette bestemt ikke en åbenlys slutning.

Og hvis du læser mine indlæg igen, vil du se at jeg ikke kritisere prisen på CPR broker, som jeg ikke ved hvad har kostet. Jeg kritiserer, at det alm. CPR er så dyrt, at kommunerne skal bruge tid og penge på at udvikle og installere et system som CPR broker (som hver kommune iøvrigt selv skal sætte op). CPR burde være enten flat rate for det offentlige, som i forvejen har bekostet enorme summer herpå, eller også burde det koste mindre end en Google-søgning.

Nikolaj Brinch Jørgensen

Hej Jesper,

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været.

Hvis vi snakker største skandale, er der jo rigtigt mange andre grunde til at dette gik i vasken (bla. OS/2 som platform mm.).

De rigtigt store projekter der bliver til skandaler (og jeg har været involveret i en del opretninger af sådan nogle), sker af mange årsager. Men fælles for dem er (som jeg ser det):
* Overallokering af medarbejdere (det skal godtgøres at det er så dyrt).
* Vild overallokering af ledelse.
* Ledelse der ikke arbejder i samme retning (flere leverandører på det samme projekt går oftest helt i hegnet).
* Kompetencemangel (diverse SI'er hælder bare folk ud af skuffen ind i projektet).
* Mangel på folk med erfaring ud i at realisere systemer (både ledelsesmæssigt og udviklingsmæssigt).
* Kommunikationsvanskeligheder.

Ovenstående har ikke noget med teknikken bag ved at gøre, for selv de mest såre simple systemer kan bringes i knæ, når først der går over-management og inkompentece, samt bureaukrati i den.

jeg acceptere at det er et hårdt slag for nogen der har arbejdet r.... ud af bukserne og ikke lykkedes, når nogen så siger at de med 5-6 mand kan løse opgaven på utrolig kort tid. Men nogen gange er det sandheden. mindre teams arbejde ofte meget mere effektivt, specielt hvis deres kompetencesæt komplimenterer hinanden.

Det er ikke så forkert hvad Morten siger, selvom jeg læser det som værende ret langt ude på skalaen (måske for at få luft for frustrationer, måske for at understrege pointen).

...dine ytringer er det mest uigennemtænkte jeg længe har hørt.

Det tror jeg ikke på. Jeg tror simpelthen ikke at Mortens ytringer er det mest uigennemtænkte du længe har hørt :-)

Claus Junker

Men vi er i øjeblikket i gang med at gøre det muligt at bruge MySQL eller en anden generisk database, så man selv kan bestemme. Vi forventer, at vi kan gøre det helt uafhængigt, så man ikke er tvunget til at have software fra en bestemt leverandør

Lige nu bruger LINQ2SQL som kun virker med Microsoft SQL Server.

Jeg ville anbefale at bruge nHibernate hvis det skal være database uafhængigt. Men forhelvede, IKKE MYSQL.

postgreSQL hvis det endelig skal være. MySQL er den mest elendige, hamrende langsomme, skod database.

Nikolaj Brinch Jørgensen

Jeg ville anbefale at bruge nHibernate hvis det skal være database uafhængigt. Men forhelvede, IKKE MYSQL.

postgreSQL hvis det endelig skal være. MySQL er den mest elendige, hamrende langsomme, skod database.

Hmmm... Kan du ikke lige smide nogle links der bekræfter din (i mine øjne meget subjektive) påstand? Facebook bruge MySQL, og det går da vist fint for dem med hastigheden.

Jesper Lund Stocholm

Hej Morten,

Du har ikke godtgjort, at IT-supporten ikke kunne have ret. Tværtimod har du indrømmet at projektet endte i en kæmpeskandale, på trods af de >100 medarbejdere -- så den model var åbenbart heller ikke svaret? Men du mener måske det er åbenlyst, at når 100+ eksperter ikke kunne løse det, så kan 5-6 venner absolut heller ikke? For mig er dette bestemt ikke en åbenlys slutning.

Det er for mig en åbenlys konklusion, at man skal afholde sig fra at udtale sig kategorisk om noget, hvis man ikke kender en sag nok/indefra.

Hej Nikolaj,

Hvis vi snakker største skandale, er der jo rigtigt mange andre grunde til at dette gik i vasken (bla. OS/2 som platform mm.).

Vi taler nok om forskellige projekter. Nøgletal for mit:

55000 arbejdere i organisationen (40% fuldtid, tjenstemænd)
200 overenskomster
1800 underoverenskomster
Ny backend
Ny frontend
Nye organisationsprocesser
Forandringsledelse
Nye ansvarsområder
Central -> decentral styring

Det drejer sig ikke om, at jeg føler min ære trådt under fode af hans kommentar - den er så langt ude, at den mister al værdi. Men kommentaren er karakterisk for debatter også herinde - man tager en sag, river én sætning ud af den og konkluderer på baggrund af denne ene sætning.

Der er nøjagtig lige så meget kød på Mortens kommentar som kommentarer som "Jeg bruger MacOSX og er glad for det, så jeg ville ønske at politikerne havde nosser nok til at kræve, at hele staten og alle kommuner gik over til MacOSX.

Det tror jeg ikke på. Jeg tror simpelthen ikke at Mortens ytringer er det mest uigennemtænkte du længe har hørt :-)

Du har ret :o)

Claus Junker

Forresten Jesper

2-3 kompetente C#/ASP.NET udviklere, og 3 måneder ville være en helt passende mængde tid til at udvikle CPRBroker.

Koden i den nuværende version er fin, men den lugter lidt meget af traditionel ASP.NET WebForms udviklere.

Det er sådan set bare en frontend for en række webservices, med en database cache. Intet specielt komplekst her.

Henrik Mikael Kristensen

Rent teknisk er OIOXML-skemaerne ret voldsomme og meget komplekse. Vi vidste, at der var meget høje kvalitetskrav, og at vi måtte være ekstremt præcise i vores implementering af standarderne.

Jeg overvejer, hvad det er der gør at en omfattende standard kan kategoriseres som et "højt kvalitetskrav"? Skal man følge standarder der er værd at følge, skal de efter min mening være simple, så man lettere kan teste. Kan man få et indblik i, hvad det er der gør sådanne standarder så komplekse?

Jesper S. Møller

Jeg overvejer, hvad det er der gør at en omfattende standard kan kategoriseres som et "højt kvalitetskrav"? Skal man følge standarder der er værd at følge, skal de efter min mening være simple, så man lettere kan teste. Kan man få et indblik i, hvad det er der gør sådanne standarder så komplekse?

OIOXML standarderne er ikke specielt komplekse, men de er indviklede ("bøvlede") at bruge i praksis.

0) Jo, det er fint nok at der med OIOXML er tænkt over tingene, og der ønskes genbrugelighed, men...
1) Strukturerne bliver meget dybe og ordflommede på grund af reglerne. Subtypning og udvidbarhed er non-eksisterende, så man ender med at skrive en masse copy-paste-kode. Og versionering er et mareridt.
2) Schemaerne er spredt ud i enkeltfiler, hvilket i praksis er noget bøvl.
3) På grund af dette bruges en ikke-standardiseret måde at inkludere flere schemafiler i samme namespace. Det har diverse validatorer og tilhørende tools typisk haft svært ved. Så i praksis skal man ind og (skrive et program der kan ) massere filerne fra rep.oio.dk for at kunne bruge dem. Og programmer der masserer schemafiler er ikke trivielle.
4) Der er tre-fire forskellige OIOXML versioner i spil, med vidt forskellige navngivningsregler (namespaces, sprog, etc.), så der er forvirring nok at tage af.
5) Måden schemaerne distribueres på nu er dybt godnat, med enkeltfiler man skal hente fra en art diskussionsforum, i stedet for logiske URL'er. Svært at automatisere!
6) De godkendte schemaer er af meget svingende kvalitet. Min favorit er det gamle CVR schema hvor stort set alle felter var strenge, og uden genbrug af strammere feltdefinitioner, der fandtes alligevel. Domænestandard min bare. Det virker som om godkendelsesprocesserne (i visse tilfælde) var en art politisk skueproces.
7) På grund af den svingende kvalitet er der mange gengangere, hvor et eller andet felt der blev glemt lige er kommet med. Men dette skal ske i et nyt namespace, og uden subtypning. Så mere copy-paste hvis man skal behandle begge typer.

OIOXML kunne have været så smart og godt, men i praksis er der nu så mange skeletter i det skab at man bør tage sine forbehold, som CPRBroker-folkene klogeligt gør. Toolingen er blevet bedre (f.eks. kan man nu (v.h.a. XML Catalogs) sætte Eclipse op til at validere sine schemafiler og validere instanser også).

Nikolaj Brinch Jørgensen

Hej Jesper,

Er det ikke igen mangel på erfaring ud i at realisere systemer som spiller ind på udformningen af OIOXML.
Altså dem der specificerer OIOXML, hvor meget praktisk erfaring har de med at realisere systemer der benytter sig af kommunikation baseret på XML og XML Schema (i.e. SOAP over HTTP)?

Claus Junker

Toolingen er blevet bedre (f.eks. kan man nu (v.h.a. XML Catalogs) sætte Eclipse op til at validere sine schemafiler og validere instanser også).

Visual Studio (som CPRBroker benytter til deres løsning) har kunne validere schema i evigheder.

Det er ret nemt når man først har alle sine schema filer, så kan man autogenerere mapping-code, med input/type validation.

Nikolaj Brinch Jørgensen

Det er ret nemt når man først har alle sine schema filer, så kan man autogenerere mapping-code, med input/type validation.

Og så har man skabt så hårde bindinger som kræver gen-deployering og alt muligt andet ved rettelser i skemaerne.

XPath og XQuery er nu en gang den "rigtige" måde at arbejde med XML på. Dette statiske bindingshelvede er næsten en direkte violation af Postel's Law (http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law)

Jesper S. Møller

@Nikolaj

Det kan man måske sige, men det er ikke helt fair. Jeg mener f.eks. ikke der er noget galt med "schema first" tankegangen, eller det at have stramme schemaer.

OIOXML blev til (2002-2003) på en tid hvor det (endelig) virkede fornuftigt at kunne formulere præcise snitflader til interoperabilitet, hvor både forretning og IT i praksis kunne bruge samme medie (XML schemaer) til at drøfte udformningen. Der var, samlet set, ikke særlig meget know-how om hvordan man bruger XML Schema mest effektivt og undgår de faldgruber, jeg nævner ovenfor.
Så lavede de en meget restriktiv standard, som de har blødt lidt op for sidenhen. Det er egentlig OK.
Det var jo også på et tidspunkt hvor alle (OK, næsten alle) var i WS-* tilbedelse som det var et babelstårn. Og... OIOXML var kun én del af hele hvidbog-stakken, hvor man jo også skullle have egentlige domænemodeller til at udrede semantikken og stille krav til schemaerne - men det var XML'en folket kastede sig over, frådende.

Jeg mener derimod det var en klar fejl at kastede sig ud i ikke-standardiseret anvendelse af xsd:import. Der for for pokker en god grund til at man laver standarder, og når der står "implementation defined" skal man bare styre udenom, hvis man opbygger en national standard. Det virker som en lille teknisk ting, men det har altså væltet en del læs rundtomkring. Det burde ikke være nødvendigt at terpe W3C specs for at kunne udfylde XML strukturer, vel?
Der er andre småfejl i OIOXML som gør at der f.eks. er forskel på et dokument og dets PSVI, hvilket ernoget bøvl ved signering, men det er undskyldeligt med tanker på teknologiens umodenhed på den tid.

Problemet med de dårlige schemaer er nok snarere politisk end teknisk. Nogen har måske haft behov for at sikre projektets success ved at få nogle resultater igennem, men det er gætværk.

Claus Junker

Og så har man skabt så hårde bindinger som kræver gen-deployering og alt muligt andet ved rettelser i skemaerne.

Du skal jo alligevel re-deploy når der er ændringer i skemaerne.

Og at redeploy en ASP.NET solution som CPRBroker, er noget der tager få minutter, og er relativt problemfrit. Faktisk vil jeg tro, de kan nøjes med at re-deploy deres OIO modul (.dll).

I .NET verdenen virker tooling faktisk :o

Nikolaj Brinch Jørgensen

Du skal jo alligevel re-deploy når der er ændringer i skemaerne.

Nej det skal jeg da ikke nødvendigvis, jeg kan da komme på adskillige eksempler på at jeg kan lave ændringer til skemaer som intet bør betyde for en klient. Der er også forskel på om jeg skal redeployere på server eller alle klienter. Og om jeg skal redeployere overhovedet.

Og at redeploy en ASP.NET solution som CPRBroker, er noget der tager få minutter, og er relativt problemfrit. Faktisk vil jeg tro, de kan nøjes med at re-deploy deres OIO modul (.dll).

Ja helt sikkert. Men hvad med klienterne (og dem er der nok en del af). Det er ikke udviklingstiden der nødvendigvis skal gøres så kort som muligt, og der hvor man skal spare en masse penge. Det er p den lange bane, altså vedligehold hvor der skal tænkes på besparelser. For det er her der ligger rigtigt mange penge.

I .NET verdenen virker tooling faktisk :o

Hehe ja hvis man køber 3. parts produkter som resharper osv.
Eclipse har haft alt dette her meget længere end Visual Studio, men det er da rart at se at det er ved at komme på omgangshøjde (.NET nu med ASP.NET MVC - hvor lang tid var det lige det tog!!!)

Jesper S. Møller

Visual Studio (som CPRBroker benytter til deres løsning) har kunne validere schema i evigheder.

Mumle om den forkælede ungdom nutildags :-)

Jeg kan forsikre dig for at man i 2004 ikke bare kunne hente OIOXML schemaer og så virkede det bare, uden en del massage af schemafilerne. Så ja, NU kan tools følge med, men det har ikke altid været tilfældet, og er det stadig ikke hvis man f.eks. udvikler nye schemaer som skal valideres som de er (komplet med fungerende import/include direktiver)

Jesper S. Møller

XPath og XQuery er nu en gang den "rigtige" måde at arbejde med XML på. Dette statiske bindingshelvede er næsten en direkte violation af Postel's Law.

XPath og XQuery kan (nu om dage) også bruge schemaer, så det er ikke det bedste argument:

Du kan snildt checke, at f.eks.

all $adr in //xkom:PostalAddress satisfies $adr instance of schema-element(xkom:AddressComplete)

Statisk bindingshelvede har sin plads, særligt på inddatering. Tænk hvis banken klippede nuller af fra højre hvis man sendte et for højt beløb. ;-)

Nikolaj Brinch Jørgensen

Hej Jesper,

XPath og XQuery kan (nu om dage) også bruge schemaer, så det er ikke det bedste argument:

Øhhh??? Ja da. De bruger skemaer, jeg forstår ikke din pointe?

Statisk bindingshelvede har sin plads, særligt på inddatering. Tænk hvis banken klippede nuller af fra højre hvis man sendte et for højt beløb. ;-)

Det mener du statisk binding kan afhjælpe? Det tror jeg ikke lige helt på, kan du bevise det?

Nikolaj Brinch Jørgensen

Hej Jesper,

Jeg tror vi taler lidt forbi hinanden. Jeg er ikke modstander af stramme skemaer, skema-først osv. Det jeg er modstander af, er at de statiske binding frameworks (i Java: XmlBeans, JAXB, Castor osv.) alle mapper 100% til skemaet, så selv når der laves ændringer til et skema som ikke har nogen indflydelse på logikken hos modtageren, så skal modtageren genbygges og redeployeres.

Der er flere problemstillinger, f.eks. at skemaer ofte udarbejdes forkert: fornavn, efternavn i en sequence. Hvorfor er det vigtigt at de kommer i en bestemt rækkefølge? Det er det ikke, de er i forvejen bestemt af deres namespace, og det er det man skal arbejde ud fra.

Skemaer er gode til at validere om hvert enkelt felt indeholder valide data. Dog kan de ikke fornuftigt bruges til at fortælle om dokumentet er valid for processering.
Det er samme problematik som HTML Forms har. Du kan validere hvert felt med JavaScript, men når der submittes laver du form validation i din forretningslogik, for det er der reglerne er om processering af data.

Jeg ved at du ved meget mere om XML end jeg :-) Men jeg synes nu bare snart jeg har set "forkert" brug af det, som altid koster projekterne dyrt og havner i Big Bang deployments, da alle skal enes om de mindste detaljer, detaljer som oftest er ligegyldige.

Jesper S. Møller

@Nikolaj

Jeg havde måske tolket dit ønske om Postels lov til at være en case imod striks schemavalidering, hvilket jeg blot ville påpege at man også kunne med XPath2 og XQuery.

Om jeg kan bevise at man kan begå andre fejl end at validere sine input med schemaer, næ, det kan jeg ikke. Det synes jeg også er et højt krav at sætte.
Kan du måske modbevise at der kan være gode grunde til at viderebearbejde schemaer hvilket kræver en statisk binding?
XML schemaer er snitfladebeskrivelser, de er en del af systemets afgrænsning, hvis du ændrer dem skal du forholde dig til effekten uanset om det er let eller svært. Hvis du vinder noget på at behandle schemaerne, f.eks. oversætte dem, så gør det dog - det er bedre end at kode alting i hånden. Det er m.a.o. et trade-off.

(Jeg tror det kan koges ned til statisk typet eller ej diskussion, og den behøver vi vist ikke gentage)

Nikolaj Brinch Jørgensen

Jeg havde måske tolket dit ønske om Postels lov til at være en case imod striks schemavalidering, hvilket jeg blot ville påpege at man også kunne med XPath2 og XQuery.

Jeg er slet ikke imod skemavalidering, men hvis det forhindre fremdrift er jeg da imod det, det håber jeg da også du er.

På samme måde som at statisk typede sprog er godt og en hjælp, men hvis det ender med at en løsning koster mere (TCO) fordi den er lavet i f.eks. Scala og ikke i f.eks. Groovy, så er jeg imod (der er selvfølgelig ander krav der spiller ind, men TCO er altid en ok målestok).

Om jeg kan bevise at man kan begå andre fejl end at validere sine input med schemaer, næ, det kan jeg ikke. Det synes jeg også er et højt krav at sætte.
Kan du måske modbevise at der kan være gode grunde til at viderebearbejde schemaer hvilket kræver en statisk binding?
XML schemaer er snitfladebeskrivelser, de er en del af systemets afgrænsning, hvis du ændrer dem skal du forholde dig til effekten uanset om det er let eller svært. Hvis du vinder noget på at behandle schemaerne, f.eks. oversætte dem, så gør det dog - det er bedre end at kode alting i hånden. Det er m.a.o. et trade-off.

Nej slet ikke. Jeg bad dig om at bevise dit eget eksempel, at statisk binding vil sørge for at banken ikke klipper nuller af...
Det kan vist ikke garanteres. I hvert fald kan jeg ikke se at statisk binding (eller statisk typet sprog) har nogen relevans for det eksempel?

Skemavalidering kan bruges til (som jeg ved du også ved) at verificere at et CVR nummer er 8 cifre, men at lave modulus check er et forretningscheck, som skal implementeres i et helt andet lag.

Jesper S. Møller

@Nikolaj - hov, overlappende indlæg

Ja, jeg tror vi er enige, og jeg kan godt se din pointe, og det er netop én af mine anker ved OIOXML - det fraråder åbne contentmodeller samt substitutionsgrupper, hvor man netop ville kunne tillade noget schema-evolution på en fornuftig måde, uden at bryde "hård" bagudkompatibilitet.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Excel kursus udvidet

Hvornår: 2015-09-07 Hvor: Storkøbenhavn Pris: kr. 5100.00

ITIL® Lifecycle: Service Transition (ST)

Hvornår: 2015-11-02 Hvor: Storkøbenhavn Pris: kr. 11900.00

MCP 10747 kursus: Administering System Center 2012 Configuration Manager

Hvornår: 2015-12-07 Hvor: Storkøbenhavn Pris: kr. 18750.00

Project 2013 Videregående

Hvornår: 2015-11-26 Hvor: Østjylland Pris: kr. 3500.00

CERT 70-331 Core Solutions of Microsoft SharePoint Server 2013

Hvornår: 2015-10-09 Hvor: Storkøbenhavn Pris: kr. 4950.00