Har vi brug for Semantic Web?

Paul Festa diskuterer i denne artikel om Semantic Web er det nye internet eller en kompleks teknologi, der søger efter et problem at løse.

Min vurdering er, at man skal passe på med kun at betragte den fremtidige vision for Semantic Web, men primært kigge på hvor kan virksomheden bruge teknologierne i dag?
Semantic Web muliggør en lettelse af informationsintegrationen, ikke applikationsintegrationen som webservices-standarderne fokuserer på. Det drejer sig om at forbinde data til dets definitioner og sammenhæng og bevæge os fra en web af dokumenter til en web af data.

Ligesom med webservices er den i øjeblikket primære brug af semantic web internt i virksomhederne og som Gartner angiver: "It will be a long time before a significant portion of the Web follows the vision of the Semantic Web, which is about machine-readable content. Still, in many areas (such as content management, life sciences, government, media, industry and market information), the principles of the Semantic Web (for example, ontologies) will be adopted much earlier."
Paul Festas artikel findes her

Styrelse vil aflive papir-regnskab

Denne artikel af Dan Jensen fra Computerworld sætter fokus på Erhvervs- og Selskabsstyrelsens beslutning om at alle virksomheder med den digitale signatur kan indsende deres regnskaber elektronisk i XBRL-formatet.
XBRL-formatet er et eksempel på en spændende udvikling indenfor de næste par år.
Det må antages, at alle virksomheder udover deres traditionelle regnskab i PDF også vil offentliggøre XBRL-regnskabet på deres hjemmeside.
Da XBRL er en global XML-standard, vil det være relativt simpelt, at lave en agent der analyserer regnskaber fra alverdens selskaber. F.eks. hvad er den årlige vækst indenfor farmaceutiske virksomheder i et specielt geografisk område?
Dan Jensens artikel kan du finde her

Risici ved at køre en SOA uden et register

Luc Clement tager i denne artikel fat på diskussionen omkring anvendeligheden af et UDDI-register. En SOA kan ikke implemnteres i stor skala uden et register hvor alle tilgængelige og godkendte services er udstillet. Man kan enten vælge at bygge det selv eller benytte webservice-standardern UDDI og selv om UDDIen indeholde rmange facilieteter som der ikek er behov for i dag, så vil det være den bedste fremtidssikring man kan opnå.

UDDI har ikke som XML, SOAP og delvist WSDL slået igennem i virksomhedernes brug. Det skyldes primært, at selve brugen af UDDI for mange virksomheder kræver en ny måde at bruge it på, men det er værd at understrege vigtigheden af et centralt register for et distribueret medium som internettet. Før Yahoo! i 1994 begyndte at offentliggøre og vedligeholde et register over hjemmesider, de fandt, var det at finde information på internettet en besværlig og tidskrævende proces. Det afhang simpelthen af, om brugeren vidste, hvor han skulle kigge. Uden UDDI er processen med at finde Web Services meget lig denne. Personer, der skal implementere og forbinde distribuerede systemer, skal offline blive enige om en protokol og er afhængige af manuel dokumentation for at deres computere og software kan tale sammen. UDDI vil fjerne denne udfordring og skabe muligheden for, at internetbaseret software kan forbinde til andet software. Derved forøges effektiviteten ved integrering af internetbaserede applikationer. Efterhånden som e-business mere og mere bevæger sig hen imod et miljø af A2A-kommunikation, vil effektiv opdagelse og vedligeholdelse af automatiske forretningsprocesser være essentiel.
Luc Clements artikel findes her

Undgå dårlig SOA

Jason Bloomberg gennemgår i denne artikel nogle af de faldgruber, der er i en SOA-implementering.

• Argumentere om hvad SOA er frem for at gøre SOA rigtigt
• Forveksle webservices med SOA - Vær dog opmærksom på at opbygning af en SOA uden brug af webservicestandarerne, vil forøge risikoen for en dårlig SOA.
• At overlade SOA til it-afdelingen
• Tro at man kan købeen SOA fra en leverandør
• Opbygge SOA fra grunden
• Vandfalds-SOA-projekter
• Gøre SOA for vanskeligt

Jeg vil tilføje en: Det vil ikke give mening at opbygge en tidslinie for brugen af SOA. Virksomheden må forstå, at forretningsverdenen er i konstant bevægelse, og planlægge derefter. Der er heller ingen deadline for, hvornår virksomheden skal have afsluttet overgangen til SOA. Det kan sagtens tænkes, at mange virksomheder vil fortsætte med kun at være delvist serviceorienteret i al evighed. Der er vigtige økonomiske fordele ved at tage denne pragmatiske og fleksible tilgang til SOA. Migreringen sker på håndterbare trin, og hvert trin vil have en målbar indtjening. SOA er den rette til at løse mange af de vanskeligste integrationsproblemer. Efterhånden som en virksomhed bevæger sig mod SOA, vil udfordringer som kompleksitet, ufleksibilitet og skrøbelighed gradvist forsvinde og virksomheden blive mere og mere behændig.
Det er vigtigt rimelig tidligt i processen at opbygge en overordnet arkitekturbyplan , der udstikker retningen for virksomhedens arkitektur. Denne byplan skal fungere som retningsgivende uden at specificere implementeringsdetaljer.
Jason Bloombergs artikel findes her

Hvad du ikke ønsker at vide om SOA!

I denne artikel præsentere Philip Howard ti ting man skal vide om en SOA. Han fremhæver blandt andet:

• Det er svært at fortælle en forretningsansvarlig hvad SOA er. Det er svært at bygge en business case baseret på forøget behændighed og fleksibilitet. SOA bliver derfor nødt til at være en løsning på et forretningsproblem.
• Business Proces Management (BPM) er ikke det samme som en SOA. Det kan endda vise sig at være en flaskehals, hvis alt bygges omkring BPM-løsningen og ens services konstant skal referere til BPM’en for instruktioner
• De fleste leverandører accepterer behovet for hændelser i en SOA, men mange forstår ikke konsekvenserne for øjeblikkelig reaktion på forretningshændelser
• Det er ikke nødvendigt at anvende SOAP
• Hvordan kan man forvente, at service kan genbruges, når det ikke lykkedes med objekter og komponenter?
• Data ignoreres ofte i problemstillingen indenfor SOA.

Jeg vil overlade til læseren at kigge på de øvrige punkter og her fokusere på hans kommentar om, at det ikke er nødvendigt at anvende SOAP eller i bredere forstand at SOA ikke er det samme som webservices.
Webservices er standard baserede interfaces til softwarefunktionalitet og har vist sin værdi ved at reducere omkostninger til integration. SOA er derimod en software-arkitektur rettet mod services. Webservices repræsenterer den mest accepterede type af software-service, fordi den er uovertruffen til at forbinde forskellige teknologier og er den teknologi, der har givet vind i sejlene til SOA. Men SOA inkluderer også politikker, governance og ikke webservice-protokoller og internt i applikationen kan f.eks. JMS og MQ anvendes.
Webservices er typisk første berøring og det giver forventninger om

• Produktivitets-forbedringer
• Hurtig tilbagebetaling
• Simple måder at tilgå systemer på

Men det er vigtigt, at balance det mod at webservices

• Ikke giver en SOA
• Er en mekanisme i en SOA

Når man anvender webservices skal man være opmærksom på, at selv om konceptet har været kendt i årtier, så er webservices et relativt nyt fænomen og man kan ikke forvente, at webservices fungerer som forventet. Dels skal standarderne modnes før de accepteres, produkter til understøttelse af webservices skal modnes og organisationerne, der skal benytte webservices, skal også modnes.
De opportunistiske måde at bruge webservices på skal forblive opportunistisk, samtidig skal virksomheden opbygge en SOA-strategi, der også indeholder et web-servicerammeværk

Man kan bygge en SOA uden webservices og man kan bygge webservices uden at have en SOA, men sammen giver de den største værdi.

Elektronisk tinglysning

Domstolsstyrelsen er i gang med et spændende projekt, hvor formålet er at ændre tinglysningen i Danmark fra at være primært papirbaseret til 100 % elektronisk. Der er ikke nogle eksisterende systemer at tage hensyn til, hvorfor det har været muligt at serviceorientere systemet til elektronisk tinglysning (e-TL) lige efter bogen.

Eletronisk Tinglysning er et af de initiativer indenfor digital forvaltning, der har den mest attraktive business case. Der regnes med samfundsmæssige besparelser på over 300 mio. kr om året og selve projektet har budgetteret med samlede udviklings- og drifts-omkostninger på 250-350 mio kr over en fem årig periode.

Elektronisk tinglysning vil på skæringsdatoen 25. marts 2008 ændre tinglysningen af rettigheder i Danmark fra udelukkende at kunne tinglyse baseret på papirbaserede dokumenter til udelukkende at kunne tinglyse XML-baserede dokumenter påført digital signatur.

Elektronisk tinglysning er et skoleeksempel på mulighederne ved en serviceorienteret arkitektur, da det kræver fleksibilitet til de fremtidige lovgivningsmæssige og samfundsmæssige ændringer samt skal indgå i forretningsproces-orkestreringer med et stort udvalg af eksterne interessenter (Realkredit, Banker, Finansieringsinstitut, Ejendomsmægler, Advokater, Landinspektører, Offentlige register osv.).

Nedenfor har jeg beskrevet konsekvenserne ved elektronisk tinglysning, yderligere information kan findes på http://www.e-tl.dk/

I Danmark modtager de 82 retskredse i dag ca. 3,5 mio. anmeldelser om tinglysninger om året. Tinglysningen sker udelukkende på basis af papir-dokumenter modtaget fra anmelderen. Den nuværende it-understøttelse består i, at medarbejderne, efter de har kontrolleret/prøvet anmeldelsen, indtaster summariske informationer i et it-system

Papir-dokumentet er efterfølgende arkiveret i ejendommens aktmappe. Der er i dag ca. 2.5 mil. aktmapper som indeholder ca. 70 mio. stykker papir.

For at strømline processen er det besluttet tre indsatsområder:
Centralisering – Alle medarbejdere skal samles et sted, i Tinglysningsretten i Hobro.
Digitalisering – Efter 26. marts 2008 vil det udelukkende være muligt at tinglyse, ved at sende elektroniske dokumenter (i XML) signeret med digitale signaturer. Alle papirbaserede anmeldelser vil blive afvist. Alle 70 mio. stykker papir i aktmapperne skal skannes ind og bliver tilgængelig som søgbare PDF-dokumenter.
Automatisering – Væsentlige dele af opgaven med at kontrollere og prøve anmeldelsen vil blive automatiseret. Ligesom al forespørgsel sker via webservice-kald eller fra den eksterne portal, som tinglysningsretten stiller til rådighed

Der er forventet, at disse initiativer vil reducere antal medarbejdere der foretager tinglysninger fra 400 til 150, hvilket, sammen med et bedre it-baseret sagsbehandlingssystem, vil betyde en omkostningsreduktion for Domstolene. Det nye it-system kaldes e-TL.

De største besparelser vil det danske samfund dog opleve, når behandlingen af en tinglysning reduceres fra i gennemsnit 5 dage (op til 3 uger i spidsbelastninger) til få sekunder.

Beregninger viser potentielle årlige effektiviseringer på 300-400 millioner kroner.
Effektiviseringerne kommer fra
Færre ressourcer skal bruges hos de professionelle aktører (Finansielle institutioner, ejendomsmæglere, advokater, landinspektører osv.)

• Al kommunikation til e-Tl sker via webservices, det betyder at de professionelle aktører kan foretage anmeldelser og straks modtage svar fra Tinglysningen om resultatet af den automatiserede prøvelse på ”egen skærm”. Ligesom information kan hentes automatisk og elektroniske dokumenter kan udfyldes automatisk.
• Den øjeblikkelige behandling af anmeldelsen medfører færre afbrudte arbejdsprocesser og færre kundemøder, ligesom kopiering, kuvertering og ingen skrivning af følgebrev reducerer deres omkostninger.
• Den indskannede akt kan tilgås elektronisk via webservice kald hvilket giver dem mulighed for at integrere de gamle papir-akter i egne systemer

Sparede finansielle omkostninger for borgeren på grund af en hurtigere registreringsproces (estimeret til 100 mil. om året)

• Bankgaranti i en kortere periode
• Mindre rentetab af overskuddet ved salg af fast ejendom
• Osv.

Dertil kommer forbedringer i form af bedre service overfor borgerne, der vil opleve en hurtigere tinglysningsproces og få præcis angivelse af det tidsmæssige forløb (der bruges et BPM-værktøj til at håndtere processen og indsamle oplysninger om sagsbehandlingstiden). I forbindelse med ejendomshandler vil det være lettere at se, hvilke rettigheder der er tinglyst på ens ejendom, sagsbehandlingstiden vil være ens i hele landet, fortolkning af formalia vil være den samme og tinglysningssystemet vil være mindre følsomt over for perioder med særligt mange tinglysninger f.eks. ved konverteringsbølger

De samlede omkostninger for at bygge e-TL inkl. indskanningen af akterne er estimeret til 250-350 mil kr. indtil slutningen af 2012.

Et væsentligt punkt i kravspecifikationen har været ønsket om et fleksibelt system, der simpelt kan tilpasse sig ændret dansk eller EU-logivning, den teknologiske udvikling samt ændringer i den måde som professionelle aktører og borgere vil anvende tinglysningen på. Dertil kommer behovet for, at professionelle aktører skal kunne integrere tinglysnings-funktionalitet tilbudt af e-TL direkte ind i deres interne sagsbehandlingssystemer

Den nødvendige fleksibilitet opnås ved at basere e-TL på en serviceorienteret arkitektur og at basere grænsefladerne til de eksterne parter på webservices.

Serviceorientering sker ved at opbygge et antal principper, som e-TL skal baseres på. Det drejer sig f.eks. om:

Sikkerhedsprincippet – Sikkerheds-infrastrukturen må ikke sætte unødige grænser for nuværende og fremtidige parter. Sikkerheden skal håndteres på en måde, der er omkostningseffektiv for såvel e-TL som for dets partner

Forretningshændelsesprincippet – Enhver forretningshændelse der sker i e-TL offentliggøres øjeblikkeligt til interesserede parter. Det giver parterne mulighed for, at reagere øjeblikkeligt i henhold til deres egen forretningskontekst, når en forretningshændelse sker. Dette i modsætning til traditionelle service-kald, hvor man først får besked, når man spørger.

Princippet om åbne standarder - Åbne standarder skal anvendes konsekvent. Det giver e-TL mulighed for at integrere med et betydeligt antal partnere på netop en måde

Netværksdata princippet – Alle informationer fra eksterne offentlige databaser (CPR, CVR, DMR …) vil blive tilgået direkte ved kilden ved brug af webservices. Det betyder, at der ikke vil eksisterer nogle kopier af eksterne databaser hos e-TL.

E-TL vil iværksættes henover påsken 2008 i form af et såkaldt ”big bang”, hvor man overgår fuldstændigt fra det gamle papirbaserede system til det nye elektroniske system.

SOA efter hype

I denne artikel har Rich Seeley interviewet en gruppe personer om, hvor SOA står i dag. Det er der kommet nogle interessante betragtninger ud af:

• Leverandør-hype omkring SOA er stadig rimelig høj, men er nu begyndt at blive modsagt af skuffelser hos udviklere og ledelsen
• SOA applikationer er sammensat af mange ”bevægelige enheder”, så de er mere komplekse end enkeltstående applikationer
• Den væsentligste fordel ved SOA er den kortere tid til ændring. SOA tilbyder ikke væsentlige omkostningsbesparelser for virksomheder. Men SOA har en positiv indflydelse på virksomhedens behændighed
• SOA skal være med til at føre virksomheden videre og bør afprøves, frem for at blive adopteret for sin egen skyld. En hjørnesten i ethvert SOA-initiativ er, at det skal involvere en konstruktiv konversation mellem it og forretningen
• Et andet problem er, at mange fokuserer på service-orienteringen frem for på arkitektur. Men det er arkitekturen og disciplinen, der gør det muligt for SOA at levere værdi. Uden en solid arkitektur og styring er SOA basalt set spild af tid.
• Der er nu mange virksomheder, der kommer med rigtige SOA-projekter. Mange virksomheder har brugt det sidste års tid på undersøgelser og ikke tekniske opgaver såsom at overveje den rigtige tilgang, spørgsmålet om de har de rigtige kvalifikationer tilgængelig, hvordan de vil organisere deres SOA osv. (Se også denne undersøgelse)
• Industrien er nu modnet så meget, at virksomheder har tilstrækkelig med funktioner og muligheder, der er tilstrækkelig med software, de har tilstrækkelig med applikationer, men de har behov for at forbedre det som de allerede har og få applikationer til at arbejde bedre sammen

SOA er ikke slutningen/løsningen på al virksomheds-arkitektur, indenfor en årrække vil der komme noget andet. Men SOA har bevist, at det har betydning, er værdifuld nok og tilstrækkelig komplekst til at organisationer vil arbejde på at få deres SOA-aktiviteter til at give et godt afkast i lang nok tid til, at vi kan regne med, at den næste bølge af arkitektur-evolution vil afhænge af og bygge på SOAs succes.

Rich Seeleys artikel

Serviceorienterede portaler

En serviceorienteret portal er ét sted, hvor der tilbydes standardiseret tilgang til al relevant information og funktionalitet indenfor portalens område.
Det væsentligste formål er, at den skal lette samarbejdet med interessenterne, så de ikke har behov, for en detaljeret viden om hvordan processerne fungerer internt mellem de enkelte organisationer.

Portalen skal være forberedt på, både at håndtere anmodninger direkte fra et brugerinterface samt til at håndtere anmodninger, der kommer fra programmer / applikationer, der udfører opgaver på vegne af en bruger.

Data integration med OWL

Ronald Schemlzer diskuterer i denne artikel, hvorledes man kan udnytte semantic web standarden OWL til at lave en løs kobling af betydningen af data..
Hvis vi har en løs koblet fælles forståelse af data, vil sammenstilling af viden placeret i proprietært designede databaser være lettere.
Tag for eksempel en situation hvor en organisation modtager et XML-dokument. Det skal checkes for syntaktiske og semantiske fejl. Syntakscheck foregår i en XML-parser på baggrund af et XML-Schema. Semantikchecket foregår i dag typisk i et specieludviklet program hvor logikken er indkodet i selve programkoden.
Ved at opbygge semantikken i en OWL-ontologi kan XML-dokumentet efter syntakschecket blive semantikchecket i en OWL-parser på baggrund af OWL-ontologien.
Denne ontologi er løst koblet og den beskrevne viden kan derfor genbruges af andre programmer internt såvel som eksternt.
Ronald Schmelzers artikel kan du finde her

Bered dig på at blive en udviklingsplatform

Nitin Bhartis artikel beskriver hvordan eBay oplever at flere og flere af deres leverandører integrerer eBays auktionswebservices i deres egne systemer. Et godt eksempel på et "nul-klik" initiativ; mennesket fjernes som integrationslimen, den håndteres i stedet af webservicestandarderne.
Det betyder også, at eBay skal til at tænke som en applikationsleverandør. De kan f.eks. ikke forvente at alle opdaterer til nye versioner, hvorfor versionering og udvidelser skal håndteres meget bevidst.
Hvis vi vender blikket til Danmark kan vi se samme udvikling hos Kort og Matrikelstyrelsens (KMS) Kortforsyning. KMS stiller her kort og geografiske data til rådighed som netværksdata tilgængelige via webservices. I øjeblikket kan de godt håndtere opdateringer til webservicene på grund af de relativ få partnere, men efterhånden som kort og geodata bliver integreret i flere og flere applikationer, vil det ikke være muligt. KMS må derfor tænke som en applikationsleverandør. F.eks. må de tænke bagud og fremad kompatibilitet ind i deres webservices, opbygge en fleksibel sikkerhedsinfrastruktur, forberede deres løsninger til at indgå i orkestreringer og sikre SLA.
Nitin Bhartis artikel findes her

Enterprise Service Bus myter aflivet

Dave Chappell forsøger i denne artikel at aflive 10 myter omkring ESB.
En ESB er en infrastruktur til opbygning af virksomhedens SOA.
I modsætning til EAIs traditionelle integrationsfokus er ESB baseret på koordineret serviceinteraktion
En ESBs funktionalitet er selv bygget op som services, det muliggør en fleksible og uafhængig udnyttelse af funktionaliteten hvor og hvornår, der er behov.
En ESB skal være designet til at udnytte de fremkomne teknologier, efterhånden som de bliver modne. Standarder som f.eks. WS-ReliableMessaging fjerner ikke behovet for en ESB, men skal inkluderes i ESBen og vil forøger dens værdi.
En ESB er en produktkategori ikke bare en sammensætning af eksisterende middelware og applikationsserver infrastruktur. Definitionen af en ESB inkluderer:

• En distribueret servicearkitektur
• En beskedbus der sikre troværdig leverance af beskeder mellem applikationer og services
• XML datatransformation
  Serviceorkestrering og intelligent routing af beskeder baseret på deres indhold.
• Et fleksibelt sikkerhedsrammeværk
• En managementinfrastruktur hvor man kan konfigurere, iværksætte, overvåge og håndtere ens remote services

En ESB er afgørende for effektiv opbygning af en serviceorienteret portal, der integrerer flere bagvedliggende systemer. ESBen håndterer mæglingen af forskellige forbindelsesmuligheder, protokoller, sikkerhed og dataformater.
ESBens mantra er konfiguration frem for kodning. En service konfigureres med information omkring dets input og output formater og hvordan man skal sende og modtage request/response mønstre eller en-vejs eventnotifikationer. Servicene er derefter koordineret af det omkringliggende rammeværk, ikke af selve servicen.
Dave Chappells artikel findes her

Bizmasteren

David Chapell diskuterer i denne artikel hvordan en business analysts (jeg kalder ham en Bizmaster) rolle vil vokse, bl.a. fordi:

• at orkestreringen af processer i en SOA kræver forretningsforståelse og vil ske i grafisk brugergrænseflade.
• fremkomsten af brugervenligt software til at håndtere forretningsregler, vil give BizMasteren en større rolle, når applikationer opbygges.
• Bizmasteren vil spille en væsentlig rolle, når overvågningen af forretningsaktiviteter (BAM) skal defineres.
• Informationsteknologi for forretningen bliver overført fra virksomhedens it-afdeling til forretningsområder, som selv vil sammensætte de forretningsprocesser, de har behov for.

Der vil blive stillet store krav til disse bizmastere, dels skal de forstå teknologien, så de kan diskutere med it-folkene, dels skal de forstå, hvordan processerne i en virksomhed hænger sammen, så de kan være sparringspartner for forretningsdelen.
David Chapells artikel findes her

Behændig helt ind til benet

Bruce Silver diskuterer i denne artikel, hvorledes SOA understøttet af BPM forøger virksomhedens behændighed.
I den forbindelse vil jeg også henvise til en blog fra Kristian Hjort-Madsen, hvor han påbegynder en diskussion omkring hvad Agile egentlig betyder.

Han referer selv til fire principper:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

En anden metafor for en behændighed virksomhed kommer fra Roy Schulte fra Gartner. Han vurderer, at det at ændre en lastbils retning er meget lettere. end at få toget til at køre, hvor sporene ikke er. " If you want the train to move over one foot, you have to do an immense amount of work tearing up and re-laying tracks". Han vurderer at behændighedens underliggende accelerator og støtte er integration og at behændighed kræver event-baserede forretningsmetoder, understøttet af en serviceorienteret arkitektur. “Traditional business strategies are not event driven. Many companies, for instance, build to stock. On the other hand, an event-driven approach sees products being built to order,"
Bruce Silvers artikel findes her

Serviceorientering og eventhåndtering bør ikke betragtes som to separate koncepter

Applikationsudviklere har traditionelt ikke set et behov for øjeblikkeligt at transmittere en hændelsesbesked for hver ændring af tilstand bare for at forøge synligheden af processen eller accelerere aktiviteterne hos andre forretningsenheder eller applikationer. Men den teknologiske udvikling både i form at hurtigere, billigere og mere stabile netværk samt den generelle tilgængelighed af nye teknologier såsom radio-frequency identification mærkater (RFID), gør det praktisk at opsamle og udsende hændelsesinformation mere bredt end tidligere.
Der er finansielle og strategiske fordele ved at implementere hændelses-baserede forretningsprocesser, fordi de nedarver den hændelsesbaserede natur af mange aspekter i den virkelige verden.
Event Driven Architecture tilbyder yderligere værdi til eksisterende it-systemer ved at åbenbare tidligere gemte hændelser, der kan udløse værdifulde, tværgående forretningsprocesser i reel tid.
Serviceorientering og eventhåndtering bør ikke betragtes som to separate koncepter, men mere som en måde at tilvejebringe værdi til organisationen under en samlet SOA-banner.

Forbunden identitet og Web Services

Eugene Kuznetsov tager i denne artikel fra Indien fat på et centralt emne: Hvordan deles brugerautentifikation og autorisation mellem de enkelte Web Sevices?
Mange partnere vil være involveret i en Web Service-model. Det er derfor nødvendigt, at brugeridentitet og tilhørende information kan deles mellem mange virksomheder, samtidig med at brugerens information og hver enkelt virksomheds unikke relationer med brugeren beskyttes. Hvis adgang til en Web Service skal besluttes, baseret på informationer om slutbrugeren, må denne Web Service have adgang til information, der gør den i stand til at træffe denne autorisationsbeslutning . Oplysninger om identiteten på brugeren er ikke nødvendig, relevant autorisationsinformation er tilstrækkeligt.
Da hvert led i en Web Services proces kan være ejet af forskellige enheder, må det forventes, at de har hver deres modeller, systemer og standarder for autentificering. For at disse Web Services kan arbejde sammen, må der være troværdige mekanismer, hvormed disse adskilte modeller kan udveksle identiteter. Da autentifikationsmodeller kan variere, må et sådan system også være løst koblet. Godt designede Web Services skal være fleksible i forhold til deres forventninger omkring andre systemers autentifikationsmodeller.
I en proces, der involverer adgang til flere systemer, bør det ikke være situationen, at brugeren skal autentificere sig, hver gang en SOAP-anmodning skal sendes på dets vegne. Udfordringen med at levere denne funktionalitet betegnes som single sign-on eller federated trust (forbunden troværdighed).
Eugene Kuznetsovs artikel findes her