Business Magazine artikel fra 2009 og Web of Trust

I Poul Fords artikel "August 2009: How Google beat Amazon and Ebay to the Semantic Web" gennemgår han ideerne bag Semantic Web.
Semantic Web bygger på reglen om at ”alle kan sige alt om alting”. Men med denne vision kommer spørgsmålet, om det hele så ikke er ubrugeligt! Hvem vil stole på information dannet af nogle fuldstændig fremmede. I dag bruger vi den menneskelige dømmekraft til at vurdere, om vi vil bruge en kilde, vi finder på internettet. Med Semantic Web har vi software agenter, der finder informationen til os og de har ikke denne dømmekraft. Så spørgsmålet er, hvordan kan vi opbygge en løsning, så disse agenter ved hvem og hvad, de kan stole på?
Web of Trust bygger på, hvorledes vi i det daglige liv opbygger vores egne netværk, som vi stoler på. Det gøres ved at vælge et antal venner, som vi stoler mest på, og derefter deres venner som vi stoler lidt mindre på, så deres venner som vi stoler endnu mindre på og så videre. På samme måde vil man på Web of Trust fortælle hvem man stoler på og hvor stor troværdighed de har, samt hvor meget man stoler på disses venner osv. Den vil også kunne benyttes til at angive utroværdighed, som kan være lige så værdifuldt som troværdighed: Hvis ens agent finder et dokument, hvor ingen eksplicit har angivet, at det stoler på det og der er ingen, der eksplicit har angivet, at de ikke stoler på det, vil agenten hellere stole på dette dokument, end på et dokument hvor nogle har angivet, at det er utroværdigt.
Til hver opgave vil man selv kunne sætte ens krævede niveau af troværdighed og derved kan computeren bestemme hvor meget af det, den læser, den skal stole på.
Agenten benytter først de sætninger, der er tættest på en i Web of Trust. Hvis svaret ikke findes, bevæger det sig længere og længere væk.
Der vil bruges digitale signatur, til at sikre at sætningerne er dannet af dem, de hævder, at de blev dannet af, til at signere ens dokumenter samt til at signere ens ”udtalelser” omkring troværdigheden af en ressource.
Poul Fords artikel kan findes her

BPEL og brugeranbefalinger

I P. J. Jakovljevics artikel diskuterer han vigtigheden af at virksomhederne i dag tager beslutninger om hvordan de vil udnytte orkestrerings-teknologier som BPEL.
Fokus for mange omkring SOA har været på servicesiden af denne arkitektur. At opbygge service er nødvendigt, men ikke nok. Ligesom med tidligere arkitekturskifter vil overgangen til serviceorienterede applikationer give en ny type platform for applikationsudvikling - en platform, der bliver fundamentet for forretningsprocesser. Muligheden for at integrere og samle individuelle Web Services til standardbaserede forretningsprocesser er et vigtigt element i den serviceorienterede virksomhed og den samlede Web Service-teknologi-stak.
Forretningsprocesser på tværs af virksomheder har længe været et ønske, og med Web Services og især BPEL-standarden er det blevet et opnåeligt mål – en løsning, der også vil være realiserbar for mindre virksomheder. Den store udfordring, der resterer, er at få partnerne til at blive enige om strukturen af de forretningsdokumenter, der skal udveksles som del af en forretningsproces. I de fleste industrier er det de manglende WSDL-abstrakte definitioner, og ikke orkestreringsteknologierne, som vil forsinke adoptionen af forretningsproceshåndtering på tværs af virksomheder.
Når man går i gang med mere pragmatiske Web Service-projekter, er det vigtigt for virksomheden hele tiden at have orkestreringskonceptet i baghovedet og lade det afspejle sig i de langsigtede visioner, efterhånden som man udvikler sin serviceorienterede arkitektur. En komplet orkestrering af forretningsprocesser fra mange parter vil tilbyde forretningsfordele, så det er af stor vigtighed, at virksomhedens systemer, applikationer og organisation placeres i en situation, hvor potentialet kan udnyttes, når tiden er inde.
P. J. Jakovljevics artikel findes her

Undgå leverandør-musefælden

Prashant Sarode understreger i sin blog. At man skal være bevidst om vigtigheden for opbygning af en beskedmodel i virksomheden.
Hvis man i højere grad benytter de "effektiviserings"-funktioner, som leverandørerne stiller til rådighed i deres udviklingsprodukter, til automatisk at generer WSDL-interfacet til sin service, vil man ende med en fast koblet binding til denne leverandørs "forbedringer" af Web Service interfacet.
Man misforstår hele pointen med Web Services ved at lade WSDL-dokumenter blive genereret automatisk. Formålet med Web Services er komponentinteroperabilitet baseret på vertikale standarder. Når dannelsen af WSDL-dokumentet kontrolleres, er det muligt mere præcist at specificere servicens semantik for en snæver målgruppe: Per industri, per forretningsaktivitet, per område, per partnerskab osv. Konsensus omkring forretningssemantikken skal udtrykkes i et neutralt sprog; dette sprog er WSDL. Det er hverken interessant eller brugbart at bygge Web Services fra et mere eller mindre tilfældigt programmeringsværktøjs interface og typer.
Prashant Sarodes blog findes her

Forretningen opnår bedre indsigt gennem serviceorienterede hændelser

Den sidste artikel diskutere hvordan en hændelsesbaseret SOA kan forøge virksomhedens udsyn til hvordan virkeligheden er i øjeblikket, frem for hvordan den så ud historisk.

Artiklen beskriver karakteristika ved stream computing og produkter til at behandle hændelsesstrømme (Event Stream Processing – ESP).

En hændelsesbaseret integrationsstrategi kan levere konsistent information hurtigt på tværs af virksomheden. Ofte er hændelsesdrevet integration den eneste måde at sikre konsistens, da mange hændelser kun giver mening, hvis de er opfanget præcis på det tidspunkt, hvor de skete. I mange virksomheder sker der større forsinkelser mellem, at en hændelse sker, og den er blevet identificeret af afdelingen, der skal håndtere den. Afhængig af hændelsestypen og dens vigtighed kan værdien af en hændelse formindskes proportionalt med den tid, der er gået, siden den skete. For visse hændelser er alt andet end øjeblikkelig behandling uacceptabel. For andre kan timer eller dage passere uden væsentlig forringelse af forretningsværdien. Hændelsesbaseret integration er essentiel for den første og kan repræsentere interessante, nye forretningsmuligheder for den sidste. Hændelsesbaseret integration skal derfor fokusere på hurtigt at få informationen, der beskriver hændelsen, hen til modtageren. Det skal ske så hurtigt, at værdien af hændelsen ikke degraderes.

Behovet for en beholder til metadata

Den næste artikel er et whitepaper, jeg har skrevet. Det behandler behovet for en metadata-beholder i en serviceorienteret arkitektur

Udfordringen til at styre virksomhedens SOA ligger i at levere en tilstrækkelig governance-infrastruktur uden at sætte behændigheden og fleksibiliteten af arkitekturen på spil. Hvis virksomheden vælger at fasttømrer deres governance-værktøjer og processer, vil den miste løftet om behændighed. Det er derfor nødvendigt at bygge fleksibilitet ind i selve governance-infrastrukturen. Hemmeligheden til at vedligeholde behændigheden ligger i metadata.

Mange virksomheder forsøger at håndtere denne metadata ved at bruge værktøjer såsom regneark, word-dokumenter eller Visio-diagrammer. For effektivt at kunne styre og håndtere mere komplekse systemer er det nødvendigt med en disciplineret proces til styring af metadata, der er understøttet af et Metadata Repository (MR) (Metadata-beholder).

BPM og SOA

I nogle artikler er der en diskussion omkring business process management BPMs i forhold til en SOA. Sandheden er, at BPM og SOA passer perfekt sammen og er afhængig af hinanden.

Hele budskabet omkring SOA er, at det i højere grad vil understøtte forretningen, at webservices er mere behændige end enkeltstående applikationer og det giver mulighed for at virksomheden hurtigere og bedre kan reagere på ændringer i efterspørgsel og markedsmuligheder. Det kan kun ske med en BPM, det er nødvendigt først at forstå virksomhedens forretningsprocesser, før man kan bygge services, der kan understøtte dem!
Uden BPM ved en SOA ikke hvad der skal bygges.

På den anden side er der heller ikke noget formål med at dokumenter og strømline virksomhedens forretningsprocesser uden en gennemgående metode for at levere nye services omkring dem!
Uden en SOA mangler BPM muligheden for at kunne ændre ting.

Tom Dwyers artikel om SOA og BPM giver et godt indblik i behovet for SOA og BPM sammen

Killerapplikationen for Web Services

Jonathan Sapir diskutere i denne artikel hvad der kendetegner en killerapplikation, det vil sige den applikation der får brugen af en teknologi til at eksplodere. Han nævner som eksempel spreadsheet for den personlige computer og browseren for internettet.

Han vurderer at Web Service- killerapplikationen vil være en Personal Service Builder (PSB). En PSB vi opfylde videnarbejderens behov for fleksibelt at kunne sammensætte services efter personlige behov og markedets krav om øjeblikkelig reaktion på ændrede situationer.

Jonathan Sapirs artikel kan findes her

Er UDDI den grimme ælling?

Jason Bloomberg diskutere hvordan UDDI i dets tidlige barndom blev betragtet som den grimme ælling som ingen kunne se behovet for. "Det vil være alt for bedrøveligt at fortælle al den nød og elendighed, den måtte prøve i den hårde vinter." Men nu ser det endelig ud til, at nogle har fået øjnene op for dets skønhed.

It-arkitekter har indset, at styrken i UDDI ligger i dets rolle i en SOA, som en nøglestandard der hjælper virksomheder med at realisere den løse kobling ved at understøtte placeringsuafhængigheden. Derved implementeres abstraktionslaget, som services repræsenterer i en SOA.

Informationen til UDDI’en er ikke indsamlet. Det er virksomhederne selv, der skal indtaste relevant information om dem og deres Web Service. Det kan godt være et stykke software eller en tredje part, der gør dette på virksomhedens vegne, men det vigtige er, at det er virksomheden, der er ansvarlig for indholdet. En UDDI kan derfor bruges til at se, hvilke services en specifik virksomhed tilbyder, og til at identificere de parametre, der bruges, for at en partner hurtigt kan bygge eller konfigurere et interface til at tilgå Web Servicen.

Kvaliteten af indholdet i UDDI’en er derfor afhængigt af, at virksomhederne har en interesse i, at UDDI’en indeholder korrekt information, og at de har velfungerende procedurer, der sikrer, at deres information altid er opdateret og korrekt. En af udfordringerne for UDDI er at præsentere en business case for virksomhederne, så de er villige til at investere ressourcer i at holde deres information opdateret. Det er et klassisk hønen eller ægget-princip, hvor ingen vil bruge UDDI’en, fordi der ikke er kvalitetsindhold i den, og ingen vil ofre ressourcer på at lægge indhold ind, fordi ingen bruger UDDI. For at UDDI’en bliver en succes skal det være en lige så vigtig parameter for virksomheden, at den har korrekt information i UDDI’en, som at den har korrekt og veldesignet layout på sin hjemmeside.

Det vil kræve nogle medarbejdere med ansvar for kvaliteten af virksomhedens UDDI-poster. Først når sådanne etiske regler er til stede, vil virksomheder turde bruge Web Services fra velrenommerede virksomheder, som de finder i UDDI’en.

Jason Bloombergs artikel findes her

Fordelen ved at bygge applikations- sikkerhed ind i infrastrukturen

Paul O'Connor diskuterer i denne artikel muligheden for, at Web Services og WS-Security standarderne vil være et paradigmeskifte i hvordan applikationer kan sikres.

Han argumenterer for hvorledes det vil være muligt at inkludere finkornede politikker og datasikkerhed i sikkerhedsinfrastrukturen frem for i applikationskoden.

Hvor hurtigt en Formel 1-racerkører kører ind i et sving afhænger ikke af motorens størrelse, men af hvor gode bremserne er. Jo bedre de er, jo senere skal der bremses, og jo bedre klarer racerkøreren sig i konkurrencen. Virksomheden kan kun operere fleksibelt, hvis den ved, at sikkerheden er i stand til at følge med. Det er nødvendigt at opbygge sin sikkerhedsinfrastruktur lige så fleksibelt, som man ønsker sin forretning skal være.

Selvom Web Services tilføjer en ekstra dimension til sikkerhedsspørgsmålet, opbygger de også et nyt paradigme for at levere en gennemgående sikkerhedsservice på en konsistent og omkostningseffektiv måde på tværs af hele organisationen. De vil derfor på sigt selv være med til at løse problemet. Ved at opbygge en samlet sikkerhedsinfrastruktur, som leverer sikkerheds-Web Services , der kan forbruges af andre Web Services på tværs af organisationen og mellem handelspartnere, bliver det lettere at benytte sikkerhedsfunktionaliteter såsom autentificering, autorisation og kryptering. Det må forventes, at disse sikkerheds-Web Services vil blive brugt på et større antal ressourcer, end det er praktisk og økonomisk muligt i dag, fordi det vil være lettere for ikke-uddannede at benytte disse.

Paul O'Connors artikel findes her

XMLs kompleksitet introducerer sikkerhedsrisici

Michael S. Mimoso hævder i denne artikel at XML sikkerhed i dag ikke drejer sig om crackers, ondsindet kode og lignende men om at fjerne kompleksiteten og den medfølgende performance-degradering, som introduceres af tunge autentifikationsmetoder.

Kravene til sikkerhed må ikke sætte noget krav til kunden/partneren om brug af specielle sikkerhedsløsninger. Det er et helt fundamentalt princip inden for Web Services, at alle partnerne skal kunne beholde deres eksisterende systemer, og standarderne vil så sikre, at de individuelle systemer kan arbejde sammen. Ved at integrere gennem abstraktionen af en enkelt sikkerhedsmodel gør man det muligt for virksomheder at udnytte deres eksisterende investering i sikkerhedsteknologi, samtidig med at man kan kommunikere med virksomheder, som bruger en anden teknologi. Langt det meste af tiden bruges sikkerhedssystemet internt, og det vil derfor være uøkonomisk at skulle lave specielle løsninger, når man skal kommunikere med eksterne partnere.

Selvom en virksomhed har lagt en stærk ring rundt omkring virksomheden, som forhindrer angreb udefra, er problemet med angreb indefra ikke håndteret. Disse angreb er ofte de mest skadelige og foretages af personer, der allerede har adgang til interne systemer. Derudover er få applikationsprogrammører blevet trænet inden for sikkerhed. Efterhånden som Web Services bliver lettere at udvikle og implementere, vil flere og flere ikke-sikkerhedsuddannede udviklere bruge dem, hvilket igen kan kontrolleres bedst ved at tage sikkerhedsspørgsmålene ud af programmørens hænder og i stedet håndtere dem separat.

Selvom Web Services tilføjer en ekstra dimension til sikkerhedsspørgsmålet, opbygger de også et nyt paradigme for at levere en gennemgående sikkerhedsservice på en konsistent og omkostningseffektiv måde på tværs af hele organisationen. De vil derfor på sigt selv være med til at løse problemet. Ved at opbygge en samlet sikkerhedsinfrastruktur, som leverer sikkerheds-Web Services , der kan forbruges af andre Web Services på tværs af organisationen og mellem handelspartnere, bliver det lettere at benytte sikkerhedsfunktionaliteter såsom autentificering, autorisation og kryptering. Det må forventes, at disse sikkerheds-Web Services vil blive brugt på et større antal ressourcer, end det er praktisk og økonomisk muligt i dag, fordi det vil være lettere for ikke-uddannede at benytte disse.

Michael S. Mimosos artikel kan findes her

Hurtig udvikling af forretningsapplikationer med SOA

John McDowall diskutere i denne artikel tre koncepter som virksomheden skal kunne håndtere for at udnytte SOAs løfter om behændighed, mindre risici og hurtigere implementering. De tre koncepter udgør:

- Løs kobling,
- Delt infrastruktur og services og
- Mere simpel udviklingsmodel

Den løse kobling giver virksomheden mulighed for at forbinde sig til partnerne, samtidig med at integriteten af ens systemer er bibeholdt, og indkapsle dem fra uundgåelige uforudsigelige ændringer. En virksomheds behændighedsgrad afhænger af, hvor løst koblet den er i stand til at samarbejde med partnere.

Den løse kobling ofrer helt bevidst optimeringen mellem de enkelte komponenter for at opnå fleksibel interoperabilitet mellem systemer, som er forskellige i teknologi, placering, ydeevne og tilgængelighed. En løst koblet applikation isoleres fra interne ændringer af andre applikationer ved at bruge abstraktioner og sen binding i interfacet mellem applikationer. I forhold til traditionelle tæt koblede applikationer er målet med en løst koblet applikation at forøge genbrugeligheden og tilpasningen til det uforudsete.

Løs kobling er en måde at designe og udvikle på – det er ikke en teknologi. Hele dette paradigmeskifte kræver en omskoling af virksomhedens udviklere samt revidering af udviklingsstrategier og metoder. For mange vil det føles unaturligt ikke mere at skulle fokusere på let målbare fordele såsom performance, men i stedet udvikle til at optimere det mere abstrakte begreb fleksibilitet. Man skal til at lære at udvikle løst koblet, eventbaseret og til generelle standarder, ikke direkte til en anden virksomheds system. En ikke ubetydelig udgift og et område, hvor ændringsmodstanden i organisationen kan være høj. Arkitekters og udvikleres forståelse og udnyttelse af løs kobling vil imidlertid mere end noget andet være afgørende for succesfuld ekstern forretningsprocesintegration.

Artiklen findes her

Standing up for UDDI

I dette interview med Luc Clement, co-chair på OASIS UDDI diskuteres fremtidsperspektiverne for UDDI. Hans væsentligste budskab er, at uden et centralt register såsom UDDI kan en virksomhed ikke lave en SOA, derfor ser han også en stigende interesse for UDDI.

En vigtig pointe omkring UDDI er, at informationen til UDDI’en ikke er indsamlet. Det er virksomhederne selv, der skal indtaste relevant information om dem og deres Web Service. Det kan godt være et stykke software eller en tredje part, der gør dette på virksomhedens vegne, men det vigtige er, at det er virksomheden, der er ansvarlig for indholdet. En UDDI kan derfor bruges til at se, hvilke services en specifik virksomhed tilbyder, og til at identificere de parametre, der bruges, for at en partner hurtigt kan bygge eller konfigurere et interface til at tilgå Web Servicen.

Kvaliteten af indholdet i UDDI’en er derfor afhængigt af, at virksomhederne har en interesse i, at UDDI’en indeholder korrekt information, og at de har velfungerende procedurer, der sikrer, at deres information altid er opdateret og korrekt. En af udfordringerne for UDDI er at præsentere en business case for virksomhederne, så de er villige til at investere ressourcer i at holde deres information opdateret. Det er et klassisk hønen eller ægget-princip, hvor ingen vil bruge UDDI’en, fordi der ikke er kvalitetsindhold i den, og ingen vil ofre ressourcer på at lægge indhold ind, fordi ingen bruger UDDI. For at UDDI’en bliver en succes, skal det være en lige så vigtig parameter for virksomheden, at den har korrekt information i UDDI’en, som at den har korrekt og veldesignet layout på sin hjemmeside. Det vil kræve nogle medarbejdere med ansvar for kvaliteten af virksomhedens UDDI-poster. Først når sådanne etiske regler er til stede, vil virksomheder turde bruge Web Services fra velrenommerede virksomheder, som de finder i UDDI’en.

Interviewet med Luc Clement findes her

Web Service og "the Grid"

Rickland Hollar diskuterer i denne artikel implikationerne af at "the Grid" og Web Services smelter sammen. Det betyder helt konkret, at visionerne for "the Grid" bliver opfyldt af de kommende Web Service standarder.

Grid Services er Web Services, der tilbyder et veldefineret antal basale funktionaliteter. Den generelle værditilvækst, som Grid Services tilbyder i forhold til Web Services, er:

- En sofistikeret sikkerhedsinfrastruktur
- En standard serviceopstartsmekanisme til at kunne styre og overvåge servicen i hele dets levetid
- Håndtering af servicens tilstand
- En standard serviceforespørgselsmekanisme.

Grid Services er startet ved brug af en "service fabrik" mekanisme. Når en applikation skal bruge en Grid Service, kontakter den en "fabrik" og anmoder om en instans af servicen. "Fabrikken" danne en serviceinstans og giver applikationen en reference til denne instans. Denne standard mekanisme muliggør sofistikerede serviceovervågningsmekanismer.
Styring af servicen over hele dens levetid sikrer, at servicen er "ryddet op", når der ikke længere er brug for den. Hver service opstart indikerer hvor lang tid, der vil være brug for servicen. Hvis en klientapplikation går ned eller holder op med at kommunikere med en service, vil servicen og alle de ressourcer den bruger automatisk blive ryddet op, når livstiden udløber. Applikationer kan udvide livstiden af en service.

Håndtering af servicens tilstand tillader Grid Services at holde styr på tilstanden mellem forskellige anmodninger. I stedet for at tilbyde et anmod/svar interface som de fleste Web Services gør i dag, er Grid Services vedholdende i hele deres levetid og muliggør forbindelsesløse interaktioner, multiple klientforbindelser og håndtering af fejl på klientsiden.

Grid Service tilbyder et standardinterface for applikationer og andre services til at forespørge om deres interne tilstand. For eksempel: en service, der udfører computerbehandling, kan tilbyde et interface for forespørgsel om tilstand af de behandlinger, der er i gang, den type af system hvor behandlinger udføres og hvilke typer af forespørgsler, der vil blive honoreret. Alle disse ville bruge en standard forespørgselsmekanisme leveret af alle Grid services. Denne information kan blive samlet ved brug af standard "push and pull" mekanismer til mange formål. For eksempel en dynamisk oversigt over tilgængelige services, samlet information over tilgængelige computerkraft, grafisk overblik der viser placering og karakteristik af lokationer og services i en Grid osv.

Rickland Hollars artikel kan findes her

At tilføje Web Services til en eksisterende arkitektur, giver ikke en SOA

Thomas Erl tager i sin blog fat på en helt central udfordring, når virksomheden skal opbygge en SOA. Det er rimeligt simpelt at lægge et Web Service lag ovenpå ens eksisterende applikationer, men en veldesignet SOA kræver, at man sætter sig udover ens eksisterende applikationsportefølje og designer serviceorienterede, forretningscentrerede services.

Web Services åbner døren til nye integrationsmuligheder, og hver Web Service kan potentielt blive en vigtig del af virksomhedens it-infrastruktur. Det sætter krav til kvaliteten af det interface, der tilbydes. Selvom Web Services er klassificeret som en løst koblet teknologi, kan den omfattende integration i virksomheden stadig medføre mange afhængigheder af serviceinterfacet. At ændre et interface, efter det er blevet etableret, kan være en omkostningsfuld og uoverskuelig opgave, især i miljøer, der udnytter samlinger af services. Et solidt kendskab til forretningsmodellen, som servicen skal fungere i, de teknologier, den skal understøtte, SOA-designstrategier og tilhørende standarder er vigtige komponenter i en Web Service-implementeringsplan.

Blogen findes her

UBL har revolutionære implikationer

Tirsdagens (uge 46 - 2004) ratifikation af Universal Business Language (UBL) som en OASIS standard vil have væsentlig indflydelse på forretningsverdenen.

UBL er et bibliotek for XML-forretningsdokumenter (indkøbsordrer, fakturaer osv.). Intentionen er, at UBL skal være en international standard for elektronisk handel let og gratis tilgængelig for alle. Standarden vil hjælpe mindre og mellemstore virksomheder lave overgangen fra papirhandel til elektronisk handel uden store investeringer i EDI.

UBL er en standard implementering af ebXML. EbXML bruger XML til sikker udveksling af forretningsdata. Det understøtter eksisterende internetstandarder og kan køre på alle platforme og tilbyder en infrastruktur, der garanterer datainteroperabilitet, semantik der sikre kommerciel interoperabilitet og mekanismer der hjælper handelspartnere med at finde hinanden. Kort sagt tilbyder ebXML en XML-baseret infrastruktur, der muliggør EDI funktionalitet over internettet. UBL leverer et standard dataformat for beskeder, der skal udveksles i en sådan infrastruktur.

For at reducere opgaven med e-handelsstandardisering til håndterbare størrelser, differentiere UBL datastandardiserings-problematikken fra processtandardiserings-problematikken. UBL fokuserer på standardisering af forretningsdata som det første trin mod global e-handel integration og overlader standardisering af forretningsprocesser til industriorganisationer og brugergrupper. Derved vil procesdefinitionerne blive håndteret i et separat lag i stakken. En sidegevinst er, at det gør UBL brugbar for den bredest mulige vifte af procesdefinitionsteknologier.

UBL er opbygget udvidelsesbart og det forventes at industrieksperter vil opbygge egne industrispecifikke versioner af UBL dokumenter. Den værdi UBL tilføjer her, vil være en reduktion i omkostningerne for at lave sådanne dokumenter og maksimere genbrug.
Det offentlige Danmark har valgt at bruge Universal Business Language (UBL) som standard for e-handel i den offentlige sektor. Ved valg af en global standardmetode er udgifter til etablering af interface mellem offentlige institutioner og leverandører reduceret. Det gør det mere attraktivt og lettere for mindre virksomheder og internationale foretagender at deltage.

UBL hjemmesiden findes her