» Startsidan/
senaste numret

» Tidigare nummer

» Varför Rockad?

» Kontakta redaktionen

» Teknik/
hjälpprogram

E-post: rockad@rockad.nu

Copyright © 2001, Rockad.

UDDI - kokar soppa på en spik?

Av: Stig Berild, Framkom AB

Inledning

Nu är vi där igen. Ett nytt modeord att lägga på minnet. Ett nytt konsortium som deklarerar sin tillblivelse placerar sin aktivitet mitt i den framforsande floden av Internetrelaterade standarder, produkter, arkitekturer genom att referera till några häftiga modetrender som XML och e-business målar en lockande vision som gärna pekar ut radikalt nya principer för hur Internet kan komma att nyttjas samt förutspår att visionen inom en relativt kort tidsperiod kommer att paketeras i en konkret specifikation.

Visar det sig nu att konsortiet består av ett antal prominenta aktörer inom IT har startskottet med automatik gått för ännu en ’hype’. Media på bred front hugger snabbt tag i nyheten, formulerar svepande översikter samt lägger gärna till någon dramatisk knorr för att om möjligt väcka våra sinnen för detta nya unika fenomen. Vem vill, hinner, orkar i Internettider stanna upp, ta till sig fakta, fundera, kanske ifrågasätta. Med dagens närmast oändliga uppsättning informationskanaler tillgängliga, inte minst över Internet, exponeras istället i stort sett samma information på ”full bredd” över många webbplatser. Det massiva genomslaget driver väloljat upp hypen till nya dramatiska nivåer. Och så vidare. Inget ont med de ursprungliga syftena eller med det ansvariga konsortiet. Det kan i bästa fall plötsligt och högst påtagligt känna sig som en bricka i ett spel som pågår över dess huvuden. Vi vet ju alla hur en liten snöboll kan bli en lavin, fjäder bli en höna...

UDDI (Universal Description, Discovery and Integration) är en sådan hype. Presenterad i sin första version i september 2000 och redan på allas läppar. Med IBM, Microsoft och Ariba som grundare är dragningskraften given. Att därtill välja en förkortning representerande begrepp som knappast kan upplevas tillhöra de blygsammaste, underlättar förstås. Alla övriga företag som vill synas i rampljuset har följdriktigt snabbt registrerat sig som medlemmar. Alla tiders för konsortiet eftersom det ger ännu större tyngd. Att alla de stora företagen regelmässigt har råd att helgardera sig genom medlemskap i alla upptänkliga sammanhang - för säkerhets skull - vägs sällan in i bedömningen.

Kanske är denna syrliga introduktion till UDDI orättvis. Förhoppningsvis har den väckt intresset för lite mer ”kött på benen”, för behovet av ett eget ställningstagande baserat på fakta. Låt oss därför för en stund lämna gnället till förmån för en faktaöversikt. Gnället återkommer vi till i avsnittet ”Diskussion”.

Syfte

I en Internetvärld där vi förväntas samverka globalt för alla upptänkliga syften, under alla möjliga förhållanden, med alla tänkbara parter, dessutom under kontinuerligt nya förutsättningar, behövs teknikoberoende samverkansstandarder och regler som erbjuder en stabil plattform att operera på. Därutöver behöver vi kunna beskriva, etablera och genomföra e-affärsprocesser under ordnade, avtalsbundna förhållanden. Men det räcker inte. I denna nya öppna globala e-värld kan vi skönja en närmast oändlig mängd potentiella parter att samarbeta med, en närmast oändlig mängd processer - services – tjänster att samverka över eller utnyttja. Var finns de, vem tillhandahåller dem, vilka förutsättningar gäller för deras nyttjande? Hur kan jag på ett smidigt sätt teckna avtal om att få tillgång till eller rätten till tjänsten? Hur etablerar jag samverkan rent tekniskt? Och så vidare. Detta är frågeställningar som UDDI avser att presentera lösningar på.

Lösning i stort

Centralt för UDDI är existensen av ett repository (UDDI Business Registry), en kunskapsbas tillgänglig för alla och envar på Internet. Där finns primärt information om alla upptänkliga företag, organisationer som erbjuder någon form av webbservice. Där finns också generella beskrivningar över olika typer av service samt referenser till vem eller vilka som sagt sig villiga att erbjuda respektive service och under vilka förutsättningar.

Obs, att fortsättningsvis begreppet ’tjänst’ kommer att användas som synonym till begreppet ’service’ av den enkla anledningen att tjänst är lättare att ange i pluralform.

Något förenklat kan man se UDDI som en global marknadsplats för tjänster tillgängliga över Internet. För att detta ska kunna etableras på ett standardmässigt sätt tillgängligt för alla över Internet krävs att den information som kunskapsbasen hanterar är entydigt definierad. Därtill krävs ett standardiserat gränssnitt som definierar den tillgängliga uppsättningen operationer mot kunskapsbasen. Varje typ av uppgift måste vara unikt identifierad för fullständig entydighet. Detta åstadkoms med hjälp av identifierare uppbyggda enligt UUID-standarden (UUID=Universally Unique ID).

Nästa avsnitt diskuterar kortfattat informationsstrukturen medan avsnittet därefter ägnas åt kunskapsbasen och dess gränssnitt.

Informationsperspektivet

Företagsinformation

När det gäller företagsinformationen har man valt att dela upp den i tre skikt där de två första avses leda tankarna till telefonkataloger. Med begreppet ’företag’ menar vi i realiteten alla typer av organisationer som väljer att exponera tjänster. UDDI kallar dem för businessEntities.

”White Pages” innehåller basinformation såsom namn, unika identifierare (t.ex. organisationsnummer), telefonnummer, adress, allmän beskrivning...

”Yellow Pages” klassificerar företagen under olika tillämpliga klassificeringssystem. Allt för att lättare kunna leta och hitta bland en viss kategori företag. För första versionen har man valt följande tre:

  • den industri företaget opererar inom (enligt t.ex. NAICS)
  • de produkt/tjänstekategorier som utbjuds (enligt t.ex. UN/SPSC – ECMA)
  • var företaget geografiskt befinner sig

Senare versioner kommer att inkludera fler klassificeringsmöjligheter, allt i syfte att erbjuda en mer precis beskrivning och därmed bättre sökmöjligheter.

Det tredje skiktet ”Green Pages” beskriver de tjänster som erbjuds och hur någon extern part kan få tillgång till dem. UDDI kallar dessa tjänster för businessServices. Bland beskrivningselement kan finnas såväl benämning, allmän beskrivning som en mer detaljerad definition av vad tjänsten är kapabel till, om sådan är relevant. Under respektive tjänst dokumenteras även tillgängliga webbServices (webbtjänster). Dessa dokumenterar de olika till buds stående alternativen att realisera kontakt med tjänsten på det tekniska planet, kunskap som potentiella externa nyttjare behöver känna till för att kunna bedöma den tekniska realiserbarheten av en eventuell samverkan.

Observera att denna information i dagsläget närmast är tänkt som kompletterande allmän upplysning/dokumentation för en extern intressent, inte för att möjliggöra automatisk ”uppkoppling” mot webbtjänsten. För det senare skulle betydligt mer information och standardiserade uppkopplingsprocedurer behöva definieras. Efterfrågan på ökad automatik kommer dock säkerligen att efterhand bli allt intensivare. Det är ju först då som Internet på allvar blir riktigt dynamiskt. Kvarstår dock ett antal synnerligen knepiga såväl tekniska som semantiska nötter att knäcka för att denna goda karamell ska kunna smakas. UDDI räknar med att i sinom tid erbjuda denna nötknäckare.

UDDI-dokumentationen antyder att även tjänster vid behov kan klassas enligt olika lämpliga klassificeringssystem, ett slags ”yellow pages” inom ”green pages”.

Figur 1

Tjänstekategorier

Varje företag tillhandahåller sin uppsättning tjänster, var och en realiserad genom en lämplig uppsättning webbtjänster. En tjänst kan vara helt unik för företaget ifråga. En annan tjänst kan också vara av en mer generell kategori som ett antal företag kanske erbjuder sin version till lösning för. Ta exempelvis ”inköpsorderhantering”. Är jag som nyttjare intresserad av en lösning på just detta problem vore det ju finurligt om jag kunde gå in i kunskapsbasen, leta fram den tjänstekategori jag är intresserad av och sedan få uppgift om vilka företag som erbjuder lösningar i enlighet med den aktuella kategorin. För att detta ska vara realiserbart behöver varje tjänstekategori utförligt beskrivas så att den intresserade entydigt kan konstatera dess egenskaper och om dessa faller ”i smaken”. Därefter måste det från kategoribeskrivningen finnas referenser till de realiserade tjänster som företag erbjuder och som var och en svarar upp mot den dokumenterade kategoribeskrivningen. Bland beskrivningselementen återfinns en unik identifikation, referens till den som definierat tjänstekategorin, en förklarande beskrivning, nyttjade format och standarder, kanske en verbal affärsprocessbeskrivning, med mera. Typiska specificerare av tjänstetyper tror UDDI blir standardiseringsorgan, branschorgan, ledande företag inom området, innovativa affärsutvecklare, kanske i specifika fall systemutvecklare.

Repositoryperspektivet

Arkitektur

Det är knappast svårt att inse att ett centralt repository (kunskapsbas) inte är en vettig lösning när syftet är att ge globalt tillgänglig information, dessutom förmodligen med olika profil och olika ambitionsnivå för olika specialsyften eller för att ge specifikt riktad högkvalitativ information. Säkerhet, tillgänglighet, underhållsansvar, innehållsmässig flexibilitet gynnas av en höggradigt distribuerad arkitektur. Däremot ligger det i själva grundidén att den totala informationen från en nyttjares perspektiv bör kunna upplevas nåbar från en enda given punkt. Hur väljer då UDDI att lösa denna delikata utmaning?

Jo, man tänker sig kunskapsbasen uppbyggd av ett antal fristående ”Operator Sites” (noder) som alla har vetskap om de övrigas existens. Eftersom syftet är en global, virtuell kunskapsbas ser man framför sig att noder kommer och går över tiden. Vem som så önskar ska i princip kunna etablera sig som en accepterad nod under förutsättning att man kontraktsvägen förbinder sig uppfylla nödvändiga krav. Ett krav är nyttjandet av ett gemensamt protokoll för informationsutbyte (baserat på SOAP). Ett annat är att noden måste kunna hantera kunskapsbasens fulla informationsmängd. Eftersom uppdateringar kan ske vid valfri nod har man valt principen att varje dygn replikera egna uppdateringar till övriga noder. En gång per dygn är alltså innehållet i varje kunskapsbas i stort sett överensstämmande.

Figur 2

Programgränssnitt

Ett globalt och intensivt nyttjande kräver givetvis ett standardiserat API (gränssnitt) mot kunskapsbasen så att alla behöriga som så önskar smidigt kan uppdatera med ”sina” tjänster respektive söka bland existerande innehåll, dessutom oberoende av vilken nod man vänder sig till. Inte konstigare än finessen med att ha ett standardiserat gränssnitt mot databaser t.ex. SQL mot relationsdatabaser. Varje nod får tillämpa sin princip för behörighet så länge som en av UDDI definierad miniminivå vidmakthålls.

UDDI definierar dels en uppsättning alternativa utsökningsinstruktioner dels en uppsättning uppdateringsinstruktioner. Se figur 3.

Figur 3

”Binding” svarar mot webbtjänst, d.v.s. hur man tekniskt kan realisera kontakt med en tjänst. ”tModel” svarar mot kategoribeskrivning.

SOAP-standarden nyttjas som tidigare indikerats som protokoll och syntax vid interaktionerna.

Användargränssnittet kan förväntas komma att se olika ut mellan de olika noderna beroende på kreativitet, målgrupp, mm. Varje nod har dock att in mot kunskapsbasen nyttja de definierade instruktionerna ovan.

Diskussion

Åter till gnället.

Det finns mycket att säga om UDDI, både positivt och negativt. Detta avsnitt innehåller mest av den senare kategorin. Inte för att gnälla för formens skull utan för att förhoppningsvis väcka läsaren till fortsatt kritisk granskning. Därefter är det givetvis varje läsares ansvar att bilda sig en egen uppfattning.

Kanske är det orättvist att redan i denna inledande fas av UDDI-projektet komma med kritiska synpunkter. Förhoppningsvis fyller dock rapporten en roll som nyanserad motvikt mot de glättiga Internet-notiser och –artiklar som följt på den inledande ganska stora uppmärksamhet UDDI förunnats. Kanske blir effekten istället att författaren hamnar i blåsväder genom gjorda missbedömningar eller missuppfattningar. Den risken får tas med i beräkningen. Om inte annat är det i så fall bevis på att rapporten haft minst en aktiv läsare. Vad mer kan man begära?

Idén som sådan

  • Intressant och viktigt insatsområde. Vissa vill i UDDI-lösningen se nästa generation generella kataloglösning att appliceras för alla upptänkliga ändamål över det allomfattande Internet. Dock lång väg att gå. I realiteten säkert betydligt svårare att realisera än vad UDDI låter påskina.
  • Ta tjänst till exempel. Den är bara intressant om den formuleras tillräckligt utförligt och entydigt (tekniska, ekonomiska, säkerhets, etiska, … aspekter). När det kommer till kritan är det ju den exakta tolkningen av vad tjänsten erbjuder som är avgörande för om någon vågar ta den i anspråk. Det får inte råda någon tvekan om vad den kan och inte kan. I alla händelser inte om vi hoppas kunna förhandla elektroniskt och komma fram till e-avtal. Något som UDDI i dokumentationen säger sig sträva mot. Visst, en intresserad kan alltid surfa omkring på nätet och få uppslag - bl.a. i UDDI - för att sedan fortsätta med att ringa och be om kompletterande information, kanske träffas för en demonstration, göra en testuppkoppling, 30 dagars fri testtid, o.s.v. men då är i viss mån hela grundidén förfelad. Då är UDDI närmast att likna vid en mer avancerad sökmotor. (Fler synpunkter på tjänstebegreppet ges i avsnitt ”Datamodellen” nedan.) På sikt kan vi dock tänka oss att denna kompletterande information kommer att kunna utbytas i form av en mer eller mindre omfattande e-dialog mellan de e-agenter som företräder den presumtive nyttjaren respektive tillhandahållaren. Men där är vi långt ifrån ännu.
  • En förutsättning för en rimligt exakt beskrivning av företag och erbjuden tjänst är i sin tur att alla UDDI-nyttjare använder sig av en och samma överenskomna datamodell, en modell som samtliga förstår att tolka. Vem är skickad att definiera denna modell, speciellt när vi kan ana att det finns en närmast oändlig variation av såväl företag som tjänstetyper vilka knappast alldeles enkelt låter sig stöpas in i samma typ av beskrivning? UDDIs aktuella datamodell bara snuddar vid behovet. Lämnar dessutom en ocean av otydlighet. Se vidare avsnitt ”Datamodellen” nedan.
  • UDDI får ses som det första stapplande steget i en lång utvecklingskedja. Låt oss hoppas att man orkar med ytterligare ett antal steg. I dagsläget står det för en högst vanlig enkel databastillämpning som dessutom onödigtvis givits en rörig datamodell. Var finns det vibrerande nytänkandet? Var finns den unika kapaciteten? Var målas visionen upp? Var skissas spännande scenarier t.ex. i kombination med ett agenttänkande? Var står de uttalade behoven att läsa? Var...

Varvid vi är framme vid några synpunkter på UDDI som projekt.

UDDI-projektet

  • En naturlig upprinnelse till den vision UDDI företräder borde naturligen komma från dem som exponerar och/eller nyttjar olika typer av Internet-baserade tjänster som komponenter i de affärsprocesser man driver eller medverkar i. Både reella och presumtiva intressenter borde känna sig kallade. In på arenan kommer IBM, Microsoft och Ariba och mutar in området med UDDI. De visserligen både exponerar och nyttjar tjänster men är i det perspektivet endast tre av hundratusentals andra som av olika skäl önskar samverka över Internet. Däremot är deras dominerande roll som leverantör av tjänsteprodukter ovedersäglig. Är då dessa tre bättre skickade än andra att formulera behov och finna en lösning? Är de månne bara fyllda av större initiativkraft? Är detta en generös insats för att stärka Internet och dess nyttjande för affärssamverkan? Finns där möjligtvis andra mer närliggande syften? Oavsett vilket måste UDDI bedömas vara ett ganska modigt initiativ som till glädje för initiativtagarna omgående gett ringar på vattnet genom den goda tillströmningen av andra företag till projektet.
  • Ambitionen är det inget fel på. Inte heller uppslutning och massmedialt intresse. Syftet är att realisera en Internet-baserad tillämpning med global räckvidd, en dynamisk organism av kunskap, nyttjare och tillhandahållare. Intressant, avancerat, viktigt. Vid närmare betraktelse flagnar dock glansen. Fram träder en tillämpning som i åtminstone sina tidiga versioner påfallande liknar en traditionell databastillämpning innefattande såväl processer, datamodell, programgränssnitt, m.m. Den konventionelle betraktaren undrar förstås nyfiket om man följdriktigt också valt att utveckla UDDI som en helt vanlig databastillämpning enligt någon vedertagen metod, t.ex. någon som tillämpar UML för dokumentation av gjorda framsteg? Utgår man från vedertagen kunskap, modeller, plattformar andra organ redan genererat, t.ex. de erfarenheter OMG under flera år arbetat upp inom affärs- och affärsprocessmodellering? Har man utgått från konstaterade verkliga behov eller – som tyvärr är vanligare – utifrån ett förmodat behov formulerat med teknikförtecken?

    Den existerande dokumentationen indikerar snarare det senare. Pang på rödbetan bara. Där finns redan en datamodell innefattande ett antal begrepp och deras samband utritade, men där de viktigaste begreppen saknar begriplig precisering av innebörd. Se vidare under nästa rubrik. Där finns redan en utförlig uppsättning gränssnittsinstruktioner redovisade som helt naturligt i allmän objektorienterad anda schablonmässigt svarar mot begreppen i datamodellen. Men var finns behoven analyserade på ett klargörande sätt, var finns de ekonomiska och ansvarsmässiga aspekterna genomlysta, var finns den teknikoberoende designen gjord, var finns motiveringen till gjorda teknikval inför en realisering? Är UDDI ytterligare ett projekt som låter full entusiasm och en god portion självtillit resultera i en ad hoc tekniklösning? Som sedan blir föremål för tester mot en ofta skoningslös verklighet, följt - i bästa fall, om man så orkar – av ett antal tidsödande revideringar. Inte osannolikt hinner intresse svalna, alternativt andra ansatser bedömas bättre svara upp mot grundidén.
  • Varför arbetar man inte under ebXML istället? ebXML brottas med samma problematik och har en betydligt större intressentplattform att vila på. Förutom tillämpningsorienterad kompetens. De flesta UDDI-företagen är ju för övrigt genom OASIS medlemmar i ebXML. Beror det på otålighet, kompromissovilja eller finns andra syften? Två snarlika men konkurrerande ansatser gynnar i långa loppet varken användare eller teknikleverantörer.

Som synes mer frågor än utropstecken för närvarande. Än mer frågetecken infinner sig för den som försöker titta närmare på datamodellen.

Datamodellen

  • Först och främst ett par ord om modelleringsspråket. I linje med aktuella strömningar använder man sig av XML. Varför? Har de senaste trettio årens utveckling inom databas- och datamodelleringsområdet passerat spårlöst förbi arbetsgruppen? XML är primärt lämplig som modelleringsspråk i samband med datautbyte. Det har också alltid varit syftet. För vissa databaser, där man primärt arbetar med dokumentanpassade data, kan visserligen XML fungera bra, men det är att göra XML en otjänst att utnyttja det i UDDI. UDDI handlar om att hantera strukturerade data i en databas och att leverera ett varierande antal olika utsnitt av den totala datamängden för olika behov. Vad värre är; den dokumenterade datamodellen representerar ett tänkande präglat av XML men i en form som snarare liknar en EntityRelationship-modell. Vaddå läsvänligt, vaddå entydigt?
  • Hur ser då datamodellen ut? Eftersom varje sida i varje UDDI-dokument innehåller en Copyright-symbol väljer jag att hänvisa till dokumentet UDDI Technical White Paper, sidan 11. Dokumentet finns på www.uddi.org. De centrala begreppen i datamodellen är ”businessEntity”, ”businessService”, ”bindingTemplate” och ”tModel”. Vad de två första representerar går att ana sig till. De två senare är knepiga att förstå även med dokumentationen tillgänglig. En ”bindingTemplate” beskriver ett av kanske flera olika alternativ att rent tekniskt ta kontakt med viss businessService, sannolikt det man i texten ibland kallar för webb service. ”tModel” är närmast att betrakta som en slags generell indexeringsfacilitet, något som i vanliga databaslösningar i huvudsak hanteras med automatik.
  • Åter till ”businessEntity”. Det räcker knappast att bara ana dess betydelse, i alla händelser inte om vi hoppas på ett brett nyttjande av UDDI. De som registrerar respektive söker information om businessEntities behöver tolka in samma sak i betydelsen för att undvika misstag av olika slag. Är det ett företag, en tillämpning, en affärsprocess, en elektronisk agent, en mellanhand – kanske marknadsplats, varför inte en businessService som har rollen att erbjuda tjänster,...? Är det något överordnat som täcker ”alla” tolkningar? Kanske är varje tolkning relevant? I så fall måste de framgå av datamodellen och där kanske företrädda genom olika slags specialiseringssamband.
  • Än värre blir det med ”businessService”. Enligt dokumentationen gäller följande tolkning: ”the businessService structure is a descriptive container that is used to group a series of related Web services related to either a business process or category of services”. Knappast klargörande. Vad är t.ex. lämplig generalitet på en tjänst? Kan det vara (från specifik till generell):
    • försäljning av min begagnade cykel
    • försäljning av 3-växlade Monark-cyklar med 26 tumshjul (eller varför inte försäljning av skor av typen Aristokrat storlek 42-47 samt galoscher för damer i softlinneplast som är räfflade i hälen för extra friktion på isigt underlag samt med det kompletterande budskapet att de alla säljs med en tvåårs internationellt giltig garanti)
    • försäljning av cyklar
    • en cykelförsäljningsportal som samlar ett antal cykelförsäljande detaljister med varierande utbud
    • försäljning i största allmänhet?
    Är det snarare försäljning av tjänster (såsom ordermottagningsprogram),...? Oklart vilket. Kanske allt av detta? Kanske något helt annat. Någon närmare distinktion mellan businessService och webbservice ges heller inte annat än ” Within each businessService live one or more technical Webb service descriptions”. Är syftet med UDDI främst att vara behjälplig med ”uppkoppling mot” snarare än ”sortimentet”? Förväntas sortiment, affärsidé m.m. återfinnas som en del av beskrivningen av businessEntity?

    Mer funderingar om vad som konstituerar en tjänst: Cykelaffären Trampapå erbjuder primärt cyklar till försäljning. Är ”cykelsäljande” därmed att betrakta som affärens tjänst? Kanske, det är ju trots allt det affären livnär sig på. Nyligen har Trampapå bestämt sig för att nyttja Internet som säljkanal. För den delen har produktexponeringprogrammet Finnlekandelätt och orderhanteringsprogrammet Ordningochreda införskaffats. Är månne dessa två tjänsterutiner att betrakta som erbjudna tjänster? Med andra ord, är det erbjudna produkter eller sättet att genomföra köpet som ska klassas som tjänst? Kanske både och, eller varken eller?

    Antag nu att företaget Köprutiner AB säljer Ordningochreda med flera programvaror och – till råga på allt - gör det över Internet på samma sätt som Trampapå med hjälp av Finnlekandelätt och det egna Ordningochreda. Är Ordningochreda då tjänsten eftersom det är en produkt av typen tjänst som exponeras till försäljning eller är tjänsten att betrakta som en allmän programvaruförsäljningstjänst eller är det de två kontaktytorna i form av de tjänster för att genomföra ett köp som Finnlekandelätt respektive Ordningochreda erbjuder?

    Köprutiner AB har också i sortimentet en momsuträkningsrutin på den egna servern som alla som så önskar får anropa och nyttja mot en mikrobetalning per anrop. Är inte denna rutin att betrakta som en mer påtaglig form av tjänst eftersom rutinen på samma gång är produkten som erbjuds och en tjänst som utförs?

    Vilken precision på beskrivningen är meningsfull? Bör t.ex. garantivillkor (eventuellt per produktkategori), betalningsrutiner, leveransvillkor, återköpsnormer, kanske referenser till nöjda kunder, m.m. finnas med? Dessa beskriver ju viktiga affärsaspekter snarare än teknikaspekter. Om valfri beskrivningsprecision – hur kommer i så fall detta att upplevas av UDDI-nyttjarna? Blir man nöjd eller irriterad av att finna beskrivningar på en mängd olika ambitionsnivåer? Blir man nöjd eller irriterad av att därmed inte kunna jämföra olika tjänstealternativ?

    Att notera i sammanhanget: Förmodligen är nyttjandet av en tjänst omgärdad av lagstiftning som kan skilja markant mellan olika typer av tjänster, mellan branscher, mellan länder, ….? Var och hur beskrivs detta?

    Finns det anledning att hålla distinktion mellan typ och förekomst? Ta som exempel tjänsteprogrammet Ordningochreda. Det  representerar en viss given funktionalitet som lämpligen bör kunna beskrivas på ett enda ställe. Samtidigt har Ordningochreda sålts till 2000 kunder (webb-butiker). Varje webb-butik erbjuder sina kunder tjänsten att beställa varor över webben (med hjälp av Ordningochreda under ytan). I det senare fallet kan det finnas anledning att per webb-butik definiera vissa förutsättningar som gäller specifikt i det enskilda fallet. 2000 sådana beskrivningar behöver förmodligen upprättas fristående från typbeskrivningen.

    UDDI förutsätter att en businessService unikt tillhör viss businessEntity. Exemplen ovan har också utgått ifrån att så är fallet. Men antag nu att tjänsten är en sammansatt process där ett antal företag (businessEntities) är involverade i olika steg med sina delansvar. Tjänsten som helhet står de gemensamt för. Vem av dem bör stå som ansvarig businessEntity? Den som tecknar avtal eller står som officiellt kontaktorgan? Låter rimligt. Men förmodligen vill den presumtive nyttjaren få en utförlig beskrivning av tjänstens bakomliggande process, kanske även få vetskap om vilka övriga businessEntities som är involverade. Allt givetvis uttryckt i det standardiserade beskrivningsspråk UDDI erbjuder ….. UDDI erbjuder i realiteten inget stöd alls för detta i dagsläget.

    Antag nu att Köprutiner AB håller på att som ansvarig etablera en ny sammansatt tjänst enligt ovan. Mellan de olika arbetsstegen (sub-tjänster) gäller vissa beroendeförhållanden att ta hänsyn till. Kanske komplicerade krav som påverkar sammanfogningsmöjligheterna med andra, t.ex. i form av att något annat utförts innan, alternativt att någon annan tar över och gör vissa handgrepp efteråt för att det tillsammans ska ge mening. Kanske behöver en gemensam databas hanteras med de villkor den ställer i form av datastruktur och gränssnitt. Självfallet önskar Köprutiner AB använda sig av UDDI för att finna de felande länkarna. Kan man förmoda att UDDI har kapacitet att ge det upptäcksstöd Köprutiner AB behöver? Svaret måste bli ett entydigt nej för närvarande. Dock ska i ärlighetens namn noteras att UDDI avser ta i affärsprocessproblematiken i en senare version. Tips till UDDI: Börja med att titta närmare på UML.

    En allmän fundering: Inom objekt- och komponentområdet har man länge försökt sträva efter återanvändning utan att lyckas speciellt bra (annat än för mycket avgränsade behov). Ju närmare affärsprocesserna man kommer desto större krav ställs på anpassning till unika förutsättningar. Alltså knappast bara att plugga in en tjänst. Okej om man bara är en mellanhand, förmedlare, t.ex. i någon portal, men inte om förutsättningen är samverkan. Kommer UDDI att drabbas av samma problem med sina erbjudna tjänster?

    Internationalisering är en annan aspekt att ta hänsyn till men som UDDI ännu inte berört. Man kanske inte beskriver businessEntities och businessServices på samma sätt i Ryssland eller Kina som i USA? Man kanske bedriver samverkan på helt andra sätt, utefter andra sociala mönster och med helt andra regelmassor i botten. Man kanske inte ens nyttjar begreppen ”business” eller ”service”. Vems syn på ”världen” ska råda?

En noggrannare analys av datamodellen skulle säkert upptäcka fler frågetecken.

Drift, underhåll

Antag att UDDI realiseras och sätts i ”produktion”. Genast infinner sig ytterligare ett par frågetecken:

  • Vem ska ansvara för driften?
  • Var finns ekonomin, incitamentet för den ansvarige? Kan knappast bygga på idealitet. På vilket sätt kommer prislapp att införas? Kommer det att verka hämmande för acceptansen?
  • Vem svarar för kunskapsbasens innehållsmässiga kvalitet? Respektive uppgiftslämnare? Varje nod? Den helhetsansvarige om sådan finns? Hur kan man överhuvudtaget kontrollera kvaliteten? Hur förfara för att alltid erbjuda aktuell information, d.v.s. se till att inaktuell sådan sorteras ut?
  • Hur övervaka att behöriga uppdaterare sköter sig? Kriterier för missbruk? Vad händer då?

Intresset för UDDI kommer att helt stå i paritet med upplevt värde, nytta. Börjar kvaliteten på innehållet att ”rämna” faller intresset snabbt för såväl den som nyttjar som den som erbjuder tjänst.

Avrundning

I det längre perspektivet ligger förstås förhoppningen om ett dynamiskt Internet i enlighet med UDDIs vision. Givetvis baserat på en höggradig automatisering. Till en början med målsättningen att smidigt – helst utan mänsklig inblandning - kunna leta fram och koppla upp sig mot en webbtjänst. På något längre sikt med förhoppningen att kunna etablera hela affärsprocesser på motsvarande sätt. Just nu är det dock långt mellan vision och verklighet. UDDI kan i dagsläget betraktas som en enkel databastillämpning där databasen innehåller diverse information om företag och deras erbjudna tjänster över Internet. Låt oss hoppas att intressenterna bakom UDDI lyckas samla sina krafter och i nästa version förmå kittla vår nyfikenhet och öka vår respekt. Visionen är det nämligen inget fel på.

Än så länge dock en ganska tunn soppa. Är inte spiken till och med lite rostig? I med en portion starka kryddor och några läckra ingredienser och soppan kan bli delikat.