OIOREST nyhedsbrev
Onsdag d. 3 september 2009
Hvem sidder på førersædet?
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 (http://en.wikipedia.org/wiki/XML),
den gamle kending, samt JSON (JavaScript Object Notation) (http://en.wikipedia.org/wiki/JSON),
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 (http://en.wikipedia.org/wiki/JSONP#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 (http://www.ibm.com/developerworks/library/wa-aj-jsonp1/).
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 (http://oiorest.dk/danmark),
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(http://digitaliser.dk/user/328166)
ville bruge Danmarkservicens stoppestedsdata til sin mashup
http://busplaner.ilios.dk/. I dette
arbejdet opdagede Christian nogle uhensigtsmæssigheder ved Danmarkservicen, som
han var så venlig at kommentere på Digitaliser.dk (http://digitaliser.dk/forum/328167).
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 (http://oiorest.dk/danmark/search.htm),
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
(http://en.wikipedia.org/wiki/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