
Ideen til dette nyhedsbrev fik jeg, da jeg og familien var på Vatikanmuseet. Her forsøgte jeg at forklare min yngste søn, hvorfor Platon peger op i himlen og Aristoteles ned mod den konkrete verden på Raphaels maleri Skolen i Athen. (Jo, han lyttede faktisk lidt efter. Han har - til sin fars store glæde - valgt filosofilinjen på gymnasiet) I den forbindelse kom jeg til at tænke på, hvor meget vores fag/branche er præget af en form for platonisme, hvor empiri ikke spiller den store rolle. Jeg undrer mig ofte over, hvorfor mange metoder, arkitekturer, standarder og værktøjer i vores fag udtænkes uden, at der er meget empirisk belæg for om de gavner målet for vores bestræbelser: den endelige løsning og dens nytte værdi. Findes der andre fag/brancher, hvor det forholder sig på samme måde? Laver vi lægemidler på samme måde? Bygger broer? Jeg kan ikke komme i tanke om nogen fag/branche/erhverv, der gør det på samme måde som os. Kan du?
Jeg forsøger at undgå at falde i denne fælde, men er desværre faldet i den igen. Ladet principper, metoder, præmatur standardisering, æstetiske forkvabbelser eller anden empiri forladt tankekonstruktioner styre valget af en teknologisk løsning. Det uden at sætte mig grundigt ind i problemstillingen og lade de kræfter, der påvirker problemstillingen være udslagsgivende for dens løsning.
Da jeg i OIOREST-projektet skulle vurdere hvilke formater, som OIOREST skulle opmuntre til at anvende i kommunikationen mellem klient og service, var de naturlige valg XML, den gamle kending, samt JSON (JavaScript Object Notation), som er ved at være de facto standard for REST kommunikation. JSON er specielt blevet populær i den REST kommunikation, hvor klienten er en browser. Det skyldes, at programmeringssproget til browserprogrammering er JavaScript og JSON er et serialiseringsformat til JavaScript objekter, som betyder at koden, der skal til at parse formatet næsten er lig nul.
Under vurderingen af JSON faldt jeg over et beslægtet format, nemlig JSONP. JSONP er et mekanisme til at omgå cross-domain kommunikationsproblemet i en browser: Hvis du fra JavaScript kode i en browser forsøger at forespørge på data fra et andet domæne, vil du få en sikkerhedsfejl. JSONP mekanismen går i korte træk ud på at dynamisk loader et scripttag i et html dokument, hvor src attributen udpeger de ønskede data. De ønskede data returneres, formateret som et JavaScript funktionskald med data som parameter. Mekanismen er lidt svært at beskrive uden at vise en del html og JavaScript kodestumper. Det er der ikke plads til dette nyhedsbrev, men du kan læse en god beskrivelse her. Allerede det at JSONP var svært at beskrive gjorde mig lidt irriteret. Det at der skulle arbejdes med html script tag gjorde der ikke bedre. At data blev overført som et funktionskald fik mine interfacedesign nakkehår til at stritte. Det var godt nok grimt. Ingen mulighed for fortrolig kommunikation, da kommunikationen foregik ved indsættelse af scripttag. Af samme grund er der ikke mulighed for at returnere fejl fra serveren. Alle mine fine SOA og interface designprincipper fornemmelser blev godt og grundigt trådt over tæerne. Så vurderingen af JSONP endte selvfølgelig med at OIOREST ikke kunne opmuntre til anvendelse af JSONP. Duer ikke.
Danmarkservicen, hvis formål er at være motivations- og inspirationskilde til hvorledes offentlige data kan udstilles, kan levere data i både XML og JSON formatet. Du kan f.eks. få oplysninger om Københavns kommune i XML ved http://oiorest.dk/danmark/kommuner/101.xml og i JSON ved http://oiorest.dk/danmark/kommuner/101.json. Til trods for at det er en demoservice, som ikke garanterer for datakvaliteten, er den blevet positivt modtaget og brugt overraskende meget. Så der var fryd og gammen indtil Christian Melchior ville bruge Danmarkservicens stoppestedsdata til sin mashup http://busplaner.ilios.dk/. I dette arbejde opdagede Christian nogle uhensigtsmæssigheder ved Danmarkservicen, som han var så venlig at kommentere på Digitaliser.dk. Tak for det, Christian. Jeg vil opfordre alle til at give os i IT- og Telestyrelsen feedback på vores arbejder – det er en stor hjælp. Christian havde tre kommentarer til Danmarkservicen. De to sidste var jeg umiddelbart enig i og Danmarkservicen blev tilrettet derefter. Den første kommentar var værre: Christian ville gudhjælpemig have at Danmarkservicen skulle tilbyde den ugly JSONP kommunikation. Så påstod han endda, at det ville spare unødige serverkald! Den tænkte jeg lidt over. Jeg havde da ikke foretaget unødige serverkald, da jeg lavede min browser baserede adressesøgning, som er et eksempel på en browserklient til Danmarkservicen. Men der lå browserklienten jo også i samme domæne som Danmarksservicen, nemlig oiorest.dk. Hvorimod i Christians tilfælde ligger browserklienten i ilios.dk domænet, som gør det at browserklienten pga. cross-domain kommunikationsproblemet ikke kan kalde Danmarkservicen direkte, men må kalde gennem den tilhørende web server applikation til Danmarkservicen. Det er her det ekstra server kald kommer fra. Det vil være et problem for hovedparten af alle mashups, da det er sjældent at mashupen ligger i samme domæne som datakilden. Og da det typisk er flere datakilder der kombineres i en mashup, vil problemet med stor sandsynlighed være der for stort set alle mashups. JSONP er altså en mekanisme, som kan lette udviklingsarbejdet for mashupudviklere eller andre der laver deres klientapplikation i browseren, som jo er en trend, der ikke er lige til at ignorere. Så selvfølgelig har de store web api leverendadører , som Google og Twitter, også JSONP adgang til deres services. Desuden understøttes JSONP i hovedparten af de populæreste JavaScript biblioteker som f.eks. JQuery. Danmarkservicen har nu også JSONP support, så når du vil have fat i oplysninger om Københavns kommune fra din browserapplikation kan du bruge http://oiorest.dk/danmark/kommuner/101.json?callback=viskommune til at kalde viskommune funktionen i din JavaScript applikation med kommunens information formateret i JSON argument.
Nu er vi langt om længe ved at komme frem til svaret på hvem der sidder på førersædet: Det er hverken SOA, EA, metoder, principper, referencemodeller, standarder, værktøjer eller ontologier der sidder på førersædet, men det gør løsningen og dens nytteværdi.
Hvem mener du der sidder på førersædet?
Og hvem mener du, der skal sidde på bagsædet, hvem skal måske om i traileren og ud på genbrugsstationen?
Finn Jordal