XML-forstoppelse

Jeg er også et krigsbarn.

Men vi har da ikke haft en krig i nyere tid, bortset lige fra Irak krigen? Og så ung er ham fidusen med sablen vist heller ikke, tænker du måske. Men jo, det har vi. For snart 28 år siden da jeg fysisk set var et barn endnu, rasede Endiankrigen i it-branchen.

Denne bitre konflikt lånte sit navn fra Jonathan Swifts "Gullivers Rejser" hvor Lilleputterne kriges mod Blefuscuianerne over det stærkt eksistentielle spørgsmål: I hvilken ende bør man åbne et æg? Den brede ende (big endian) eller den spidse (little endian).

Indenfor it handlede krigen dog om fortolkningen af bits, der serialiseres over en transportkanal. Hvis hvert tegn f.eks. repræsenteres af 16-bit kan tallet 0x0A0B serialiseres som 0x0A,0x0B (big endian) eller 0x0B,0X0A (little endian) afhængig af hvad man er til.
 
I min erindring står bla. Motorola som de kætterske Bleufuscianere hvis big-endian byteordning var langt lettere at læse med en hexeditor, mens Intel tager pladsen som Lilleputterne.

Endiankrigen er fra en tid, hvor hukommelsen var knap, lagerpladsen lille og hvor det var en dyd at vende hver en bit før den blev brugt. Sådan er det jo i krigstider og det præger krigens børn.

I dag er konflikten slut og man er blevet tilstrækkeligt enige om standarder for serialisering - forskellene i "endian" til trods - til at det er blevet praktisk at sende data på tværs af platforme.

SOA med OIOXML

For tiden er jeg involveret i et større SOA projekt, der med webservices søger at integrere en række it-systemer på tværs af organisatoriske grænser. Projektet anvender meget fornuftigt IT- og Telestyrelsens OIOXML som grundlag for hvordan servicekontrakten udformes og kører UTF-8 som tegnformat uden endianproblemer.

OIOXML-initiativet sigter på at få skabt en række fælles datamodeller. I kernen findes de generelle XML skemaer, der potentielt kan bruges på tværs af fagdomæner, adressoplysninger, kommunekoder, etc. og udenom findes de domænespecifikke, patient, kapitalindkomst, mm. Håbet er at man med tiden får skabt et stort modelbibliotek i form af ISB'en, der er consensusskabende for hvordan information udveksles.

Et værdigt mål!

Misforstå mig derfor ikke: jeg er stor tilhænger af standarder og bakker bestemt op om OIOXML, men der er en hage ved det, der piner krigsbarnet i mig.

Det fylder helt vildt meget!

Navgivnings- og Designreglerne for OIOXML (NDR 3.0) siger nemlig bla. at det ikke er tilladt at bruge forkortelser. Det betyder f.eks. at en ellers alment anerkendt term som "CPR" bliver til "PersonCivilRegistrationIdentifier".

Snydepakker

Når XML på denne måde udelukkende optimeres ud fra navngivningskonventioner uden skelen til størrelsen bliver det lidt som med de snydepakker vi alle hader at finde under juletræet. De er voldsomt store og har fint bånd omkring, men bag alle lagene af indpakning og tape indeholder de skuffende lidt.

Hvis den slags pakker sendes med posten fylder det op i lastrummet, koster ekstra og sender flere postbiler på vejene i den proppede myldretrafik. I SOA-projektet betyder de store pakker at flere af parterne formodentlig må opgradere linjekapaciteten for med sikkerhed at kunne opfylde servicemålene.

Og selvfølgelig kan vi lukke luften ud af pakkerne med alskens komprimering, men så skal de jo pustes op igen inden de afleveres. Vi kan da også lave vores egne typer, men så ryger ideen med OIOXML på gulvet med et hult drøn.

Suk, sagde krigsbarnet, hvor kunne vi dog udveksle meget mere data over det kobber vi har, hvis alting ikke skulle repræsenteres som tekst.

Glædelig jul.

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Troels Liebe Bentsen

Jeg sidder selv i en ligende problemstilling, jeg er i gang med at lave et SOAP interface til noget kode jeg har skrevet. Og faldt også selv i fælden og gik i gang med at optimere på tags, data strukturer og om jeg skulle understøtte pipelining af HTTP request så jeg kunne spare et par TCP handshake.

Men efter et par timer kom jeg heldigvis på bedre tanker og begyndte at kigge på det på en mere pragmatiske side. For det er jo bloated lige meget hvor meget jeg så end optimere. Bare tag et hurtigt kig på hvor mange liner du skal bruger for at beskrive en simple funktion i et WSDL dokument og så kan man hurtigt drage den konklution at det aldrig bliver så simpelt og lækket som man godt kunne ønske sig.

For hvis det skulle være effektivt og småt på linje ville en custom binær protokol helt sikkert alt tid være end bedre ide. Men er det nemmer at bruge og arbejde med? Og er de 30 ekstra milisekunder XML fortolkeren skal bruge på at opbyggen den interne repræsentation virkeligt den lille linje besparelse værd? Og når man kaster komprimering ind over(som er standard i stort set alle webservere i dag) bliver den forskel jo endnu mindre.

Så hvor så ikke bare købe noget mere jern, slå komprimering på og lade værd med at spilde flere konsulent timer på at optimere på noget der alligevel ikke gøre det store fra eller til.

  • 0
  • 0
#4 Dennis Krøger

Pjat, man udskifter en algoritme med en større/langsommere uden grund.

Det er en simpel afvejning mellem f.eks. en optimeret, men uigennemskuelig og ikke validerbar binær prototol, og en WS-* protokol der er selvbeskrivende og validerbar.

I andre tilfælde kan det være mellem udviklingstid og optimering, eller mellem fleksibilitet og optimering.

Den binære protokol er ofte den dårligste løsning, med mindre man virkelig har BRUG FOR den optimale ydeevne. Her kunne visse spil, eller kontrol der kræver lynreaktioner være eksempler.

  • 0
  • 0
#5 Dennis Krøger

Bloat er oftest en betegnelse for ting der unødigt er større, det er jeg ikke helt enig i er tilfældet ret ofte.

Eller er jeg enig, og vil jeg tilføje at WSDL filen jo kun bliver læst en gang per klient per... Well, dag eller uge eller whatever alt efter caching indstillinger.

En ting der dog skal siges, er at man helst skal undgå alt for meget urn: pjat i selve SOAP kaldene, de kan i visse tilfælde nemt både fordoble og tredoble størrelserne. Men det er så hudt jeg visker op til SOAP versionen og SOAP stakken, men ens WSDL kan indvirke.

  • 0
  • 0
#7 Henrik Liliendahl Sørensen

Jeg er også opvokset med filnavne på 8 karakterer - og ikke hele første afsnit af tekstdokumentet.

Engang oplevede jeg en kunde som syntes at prisen på OIS data var utrolig billig - nogle håndører pr. MB. Det var lige indtil der kom data i XML.

Den største fordel ved XML er vel, at det er en standard. Og anvendeligheden af standarder stiger med udbredelsen.

PS: Tænk at 'OIOXML NDR 3.0' ikke tillader forkortelser.

  • 0
  • 0
#9 Kåre Kjelstrøm

Det er måske rigtigt lige indtil man begynder at more sig med de mere subtile specifikationer som XMLSignature og WS-Encryption.

Disse specifikationer lider af helt særskilte problemstillinger fordi man nu begynder at betragte den ellers så relativt whitespaceignorante XML som en stream af bits der død og pine skal være identisk mellem klient og server for at signering/validering og kryptering/dekryptering kan fungere.

Så får man pludselig brug for algoritmer for at fjerne whitespace og formattere XML ens (skriver man f.eks. "Ø" eller Ø ?)

Emnet er faktisk så omfattende at det næsten fortjener sit eget blogindlæg :-)

  • 0
  • 0
#10 Mikkel Hippe Brun

Super indlæg! Spørgsmålet om hvor meget XML fylder, og hvilke konsekvenser det har for processeringen har fyldt meget gennem årene.

Jeg var hovedforfatter til NDR 1.0 og har selv været med til at lave reglen om at man ikke må benytte forkortelser. Jeg kan sagtens se, at denne regel kan give anledning til mange grinagtige navne. For en dansker er "CPR" forkortelsen almen kendt, men det er den ikke ude i den ikke i fx. Indien. Den stakkels indiske programmør har ikke et begreb skabt om hvordan han skal opfatte "CPRid". Hvilken semantik knytter der sig til dette tag? Han ved at det er et ID for en eller anden TBF. Hvis han er heldig, er der udarbejdet en dokumentation for de forskellige tags, og hvis han er uheldig er dokumentationen på dansk.

Prøv i øvrigt at se de regler der er om brug af danske og engelske elementnavne i NDR 3.0. Vi gør det ikke lettere at ’out source’ vores systemer hvis vi benytter danske elementnavne. Det er en anden diskussion som jeg godt kunne tænke mig at få op her på Version2.

Tilbage til diskussionen om de potentielt store datamængder som vi får med XML. Det er ikke nogen hemmelighed at jeg er stor fan af XML. Jeg har også prøvet at arbejde med meget store XML-filer i fx OmniMark. Det er min opfattelse at man med de rigtige værktøjer meget sjældent har udfordringer med de lange elementnavne. Men der hersker ingen tvivl om at hvis man ikke tænker sig om, så kan en applikation blive sløvet gevaldigt ned. Vi har eksempler på elektroniske regninger med flere hundrede tusinde varelinjer på op til 42 MB. I sig selv ikke nogen stor datamængde, men det kan godt være et problem for et fakturahåndteringssystem, som skal opbygge en DOM repræsentation inden det kan behandle dokumentet.

Udfordringerne melder sig også i relation til web services via http. Her ligger grænsen ligeledes omkring de 50 MB og i de sammenhænge er det naturligvis ikke ligegyldigt hvor meget et element fylder.

I stedet for at komme med svarene her vil jeg gerne benytte anledningen til at invitere alle interesserede til en brainstorm /workshop omkring indholdet til en kommende web service profil for "store datamængder". Workshoppen forventes afviklet i slutningen af januar. Interesserede kan sende en mail til mhb@itst.dk.

Mikkel Hippe Brun Center for Serviceorienteret Infrastruktur IT- og Telestyrelsen

  • 0
  • 0
#11 Kåre Kjelstrøm

Hej Mikkel,

Tak og fint tilbagespil :-)

Mht. forkortelser så kommer vi alligevel ikke udenom at begreber løsrevet fra en sammenhæng kræver et par ekstra ord med på vejen fordi det talte sprog er jo netop kontekstsensitivt som i "the man opened his chest", hvilket kan være to meget forskellige ting :-).

Modeller er jo alligevel netop det, en repræsentation af elementer i et domæne og dermed kontekstsensitive. Derfor skal udenforstående alligevel sætte sig ind i begrebernes betydning i en given situation og kan vel godt lære hvad CPR står for når vi snakker personoplysninger? Ad samme tangent står PLO for Praktiserende Lægers Organisation når konteksten er sundhedsvæsenet, mens det har en lidt anden betydning i nærheden af Palæstina ...

Godt initiativ med workshoppen - Jeg deltager gerne!

/Kåre

  • 0
  • 0
#12 Peter Nørregaard Blogger

Vi har også et par bitvendere i min organisation som synes at XML (fx OIOXML) er spild af bits. Men de har ikke rigtigt forstået budskabet: At pladsforbruget er underordnet hensynet til en forståelig kommunikation på et tilpas højt abstraktionsniveau.

Men XML tillader også en elegant lagdeling: Udpakket når der er behov for det på applikationslaget og effektivt komprimeret når der er behov for det på netværkslaget eller på storage.

Et eksempel: Microsofts OOXML er en (relativt – nu skal jeg passe på flamerers herinde) sigende struktur som er til at forstå når man er en applikation. Og ved lagringen på harddisk eller transport over net er dokumentet zippet / komprimeret. Nettoresultat: En Word-fil i OO-format fylder mindre og er mere forståeligt beskrevet end det samme dokument gemt i Words 2003s binære format. Se, det er da elegant.

PS, Mikkel, jeg er også gerne med :-)

  • 0
  • 0
#13 Henrik Liliendahl Sørensen

Spørgsmålet om anvendelse af XML kræver - som så mange andre spørgsmål - ikke et 'enten eller' svar.

XML er klart overlegen på mange fronter. Men der er bestemt situationer, hvor det er uhensigtsmæssigt grænsende til absurd at holde fast i en standard.

Et par eksempler:

Staten tilbyder download af OIS ejendomsdata kun som XML. Der er ikke tale om nogle elegante strukturer :-)men ganske flade filer, hvor det svære i øvrigt er at gennemskue deres indhold og sammenhæng. Der er tale om relativt store datamængder. Jeg vil tro, at det første alle gør, når man har fået de mange GB ned gennem kobberet er, at lagre dem i nogle databasetabeller. XML'en tjener formentlig intet formål - det er bare fyld i standardens navn.

I en løsning vi har leveret til brug ved match af data mod et verdensomspændende virksomhedsregister gennemføres en XML forespørgsel måske omkring en million gange om dagen. I første omgang leveredes svaret som XML. Men ved omlægge dette veldefinerede og gennemprøvede svar til et tabulator format, kunne der opnås en performance forbedring - som ganget op en million gange ikke er uvæsentlig.

  • 0
  • 0
#14 Kristian Thy

Kåre, du skriver at man ved signering og lignende pludselig skal til at tage højde for whitespace. Det er derfor W3C har lavet Canonical XML, der godt nok kun er på Technical Recommendation-niveau, men som jeg da alligevel mener at en del værktøjer implementerer.

  • 0
  • 0
#15 Mikkel Hippe Brun

I dette indlæg taler jeg som privatperson og ikke som repræsentant for IT- og Telestyrelsen.

Jeg undres altid når folk med længsel taler om "de gode gamle dage" hvor dataudveksling skete med kommaseparerede (CSV) filer.

Ja – jeg vil godt medgive, at CSV-filer fylder mindre, og at der kan være situationer, hvor de kan være at foretrække, hvis der er tale om tabulære datastrukturer med store mængder data. Men er der tale om mere end en enkeltstående udveksling, med lidt mere komplekse data, så er CSV-filer besværligere at manipulere og besværligere at validere.

Jeg gør mig derfor følgende antagelser i nedenstående argumentation: * Der er tale om jævnlige udvekslinger af de samme data * Udvekslingen skal i størst muligt omfang automatiseres

Hvis man udnytter fordelene med XML og XML Schema har man efter min opfattelse følgende fordele med XML-filer sammenlignet med CSV-filer.

XML-filer med et tilknyttet XML Schema med stærke datatyper giver automatisk validering. Med Schematron er det muligt at opsætte endda meget komplekse validering på tværs af data (integritetsregler som vi kender dem fra relationelle databaser). Med XSLT er det en leg at manipulere og præsentere data. En XML-fil kan omdannes til en CSV-fil med et meget simpelt XSLT stylesheet. Versionsinformation er tydelig via namespaces. Sker der en ændring i data, så fremgår det eksplicit af importfilen fordi namespace har ændret sig. Vi får mao. ikke importeret de forkerte data i de forkerte felter. Med en intelligent versioneringsstrategi er det endda muligt importere nye versioner af XML-filer såfremt ændringen er bagudkompatibel med tidligere XML-schemaer (lidt komplekst - men muligt fx i OIOUBL – og jeg forklarer gerne teknikken offline).

Skulle jeg gøre det samme med en CSV-fil, skal jeg skrive min egen parser og manipulator i Perl, Python eller lign. Alternativt kan jeg oprette nogle tabeller i en database, som matcher data i CSV-filen og så skrive et lille script, som manipulerer data til det tabellayout jeg selv har defineret. Med denne arkitektur er jeg stærk afhængig af at de data jeg får leveret i CSV-filen ikke ændrer sig. Får jeg ekstra felter skal jeg til at debugge noget Perl / Python-kode (og det er ikke nogen let sag en time efter det er skrevet) eller også skal jeg til at tilføje felter til min database.

Jeg forstår ikke, at man vil give afkald på alle de fordele som man får foræret med XML-værktøjerne, blot for at spare lidt plads. Jeg er ikke i tvivl om at der findes domæner, hvor plads virkeligt er afgørende, og hvor antallet af transaktioner gør det nødvendigt at se kritisk på hvor meget ens XML fylder. Til militære formål og i kommunikationen med mobile enheder med små båndbredder er det helt sikkert tilfældet. I de fleste andre tilfælde er det min påstand, at den fleksibilitet man taber og den ekstra omkostning man påfører sig (ekstra kode) ikke kan opvejes af tilsvarende fordele når man vælge CSV-formatet.

Venlig hilsen Mikkel Hippe Brun

  • 0
  • 0
#18 Mikkel Hippe Brun

Hej Jens,

Du må endelig ikke tro, at XML lægger nogen som helst bindinger på din brugergrænseflade. Og XML bør ikke få en programmør til at tænke anderledes i forhold til brugergrænsefladen.

Som du selv skriver, er XML-strukturen, eller for den sags skyld de editeringsmuligheder du har i en XML-editor eller notepad, slet ikke velegnet som brugergrænseflade for alm. mennesker. Men det er heller ikke det der er meningen.

XML kan ikke sammenlignes med regneark, men et regneark kan som bekendt repræsenteres i XML (lad os ikke gå ned af den sti). Et regneark er en applikation som er velegnet til at præsentere tabulære data med regneregler. XML er et format der primært er velegnet til at transportere, manipulere, validere og arkivere data. XML er ikke en applikation og har ikke nogen standardiseret brugergrænseflade.

Venlig Hilsen Mikkel Hippe Brun

  • 0
  • 0
#20 Henrik Schmidt

Jens,

Der er ikke noget, der hedder "for langsomt", bare fordi der er noget, der er hurtigere. Hvis man vil arkivere nogle data i en XML fil frem for en database, så er det hurtigt nok til langt de fleste ting. Med hensyn til at slå op i data, så findes der værktøjer, i hvertfald i Java-verdenen, som kan indeksere data på en mere kraftfuld og pæn måde end SQL. Databasers store styrker som jeg ser det er deres transaktions-sikkerhed.

Med hensyn til CSV, så er det rigtigt sjovt at parse CSV, hvori der indgår både komma og linieskift i de komma-separerede data-felter. Især fordi CSV så vidt jeg ved ikke er en standard. Nej tak, jeg foretrækker XML.

  • 0
  • 0
Log ind eller Opret konto for at kommentere