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

Overvejelser i det systematiske stadie

Mike Lehman giver i denne artikel nogle råd om overvejelser i forbindelse med at man som virksomhed går fra det organiske stadie til det systematiske stadie med en gennemtænkt model for indførelse i i virksomheden.
Det er i det systematiske stadie, man har opnået så megen erfaring med Web Services, at man vil gøre Web Services til den foretrukne integrationsmetode. Det er derfor nødvendigt at opbygge en mere sammenhængende og gennemtænkt model for virksomhedens Web Service-baserede SOA og en gennemarbejdet strategi for indførelse af den i virksomheden.
Man skal være opmærksom på, at det at bruge Web Service-standarderne ikke er det samme som at bygge en Service Orienteret Arkitektur. Når der kun fokuseres på det tekniske, opnås primært en integration af udviklingsværktøjer, standarder og produkter, der udnytter Web Services-teknologien. Det er derfor nødvendigt at opbygge en god forståelse for SOA-koncepterne, før der i større grad udvikles virksomhedsstandarder og applikationer med brug af Web Services. Partnerne i værdikæden vil have opnået erfaring i brug af Web Services, hvorfor koordinering med forretningspartnere til forbedring af kritiske processer vil være lettere. Man vil også opleve en reduktion i omkostningerne til både ekstern og intern integration. Disse besparelser kan bruges til at inkludere flere partnere i processen og derved udvide ens manøvremuligheder, eller integrere flere interne systemer og derved forbedre beslutningsgrundlag og hastighed i organisationen
Mike Lehmans artikel findes her

Event Driven Architecture

Jeg vil starte med at henlede opmærksomheden på mit seneste whitepaper omkring Event Driven Architecture.
Organisationer der ønsker at operere i reel tid, er ofte ikke opmærksomme på, at deres vigtigste forretningshændelser ligger slumrende, lukket inde i de sikre rammer af deres komplekse system. Hændelsesbaseret eller Event Driven Architecture (EDA) tilbyder muligheden for at åbne for forretningspotentialet i en verden, hvor forretningsprocesser og deres afhængighed af forretningshændelser sker uden forsinkelse.
Forestil en virksomhed hvor:
Enhver vigtig forretningshændelse let, effektivt og troværdigt kan blive identificeret, opfanget og offentliggjort til virksomhedens "besked-bus" uden omkostningsfuld og risikabel applikationsombygning.
Informationen, der beskriver hændelsen, fortsætter gennem virksomheden med potentiale til at påvirke flere forretningsenheder, der kan udlede unik værdi ved at abonnere på disse hændelser
Forretningsanalytiker kan dynamisk konfigurere hele systemet uden at iværksætte komplekse tekniske implementeringsopgaver.
Event Driven Arkitektur bliver ofte præsenteret som efterfølgeren til en Service Orienteret Arkitektur (SOA). Men en EDA er ikke en separat arkitektur-tilgang, den er et væsentlig element i, hvordan en virksomhed bør implementere SOA korrekt.
Mit whitepaper findes her

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