fredag, december 22, 2006

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

søndag, november 05, 2006

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

onsdag, oktober 11, 2006

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

mandag, september 18, 2006

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

fredag, september 08, 2006

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

torsdag, september 07, 2006

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

onsdag, september 06, 2006

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

Sir Tim Berners-Lees forventninger omkring Semantic Web

Mark Frauenfeld har interviewet Tim Berners-Lee om status på Semantic Web.
Semantic Web er det næste trin på interoperabilitetsstigen. Internetstandarderne har forbundet maskinerne, Web Service-standarderne forbinder applikationerne og Semantic Web-standarderne vil forbinde informationen.

Semantic Web drejer sig om at opbygge en infrastruktur, hvor information fra forskellige kilder, kan blive integreret dynamisk for at udføre nogle opgaver. Semantic Web leverer mekanismer, der muliggør integration af informationer. Data er ikke det samme som information. Data bliver information, når det kan forstås. Data med tilhørende metadata til beskrivelse af dets betydning, bliver information der kan behandles af en computer.

En af de mest spændende ting ved Internettet er, at det er så mange forskellige ting for så mange forskellige personer. Den kommende Semantic Web vil multiplicere denne mangesidighed tusinder af gange. For nogle vil den afgørende feature af Semantic Web være letheden hvormed ens PDA, bærbare, kontor PC, server og ens bil vil kommunikere med hinanden. For andre vil det være automatiseringen af virksomhedsbeslutninger, der tidligere skulle udarbejdes i hånden. For andre igen vil det være muligheden for at tilgå troværdigheden af dokumenter på nettet og den lethed hvormed man vil kunne finde svar på spørgsmål. Lige meget hvad grunden er, vil alle kunne finde en grund til at understøtte visionen om Semantic Web.

Mark Frauenfelds interview findes her

SOBA vil revolutionere applikationsintegrationen

Michael S. Mimosos artikel "Gartner: SOBAs will revolutionize Application integation" diskuterer hvordan leverandører, der ikke er klar til at levere deres applikationer som services, vil forsvinde.

Budskabet er ikke, at store, integrerede standardsystemer forsvinder, men leverandørens løsninger skal være mere fleksible og åbne over for andre leverandører end de nuværende monolitiske løsninger, og de skal kunne implementeres mere pragmatisk.

Glenn Petersen sendte mig for nylig en mail, som er værd at overveje i hele diskussionen omkring SOAs muligheder for mindre afhængighed af leverandørerne. Han skriver bl.a. "Man kan sagtens forestille sig en service, som er løst koblet ud fra en teknisk synsvinkel, men tæt koblet forretningsmæssigt. Som eksempel kan nævnes SAP, som udstiller sin forretningslogik som løst koblede (Web) services (eller i det mindste har planer om at gøre det). Da de annoncerede deres plan om at gøre det, faldt deres aktiekurser straks, fordi analytikere så det som en risiko, at man nu gjorde SAP kunderne mere frie i deres valg af leverandør. Hvad det imidlertid tegner til er, at de udstillede services faktisk låser kunderne endnu mere end tidligere. For nu kan kunderne integrere SAP i deres egne IT-løsninger, hvilket gør, at det faktisk bliver sværere at udskifte SAP."

Michael S. Mimosos artikel findes her

Betaling for Web Services

Phil Wainewright tager i sin blog "Amazon to charge for services" udgangspunkt i Amazons annoncering af Alexa Web Information Service (AWIS). Amazon vil kræve betaling og han diskuterer hvordan betaling af indhold via mikrobetalinger vil være anderledes end betaling for brug af services

At forstå hvordan man skal tjene penge på sine services, bliver en proces, hvor der skal opnås mange erfaringer og det er positivt at se, at førende e-business virksomheder som Amazon, begynder at opnå erfaringer med betalingsmodeller. Erfaringer som andre kan have glæde af.
Han skal dog være opmærksom på at har man noget af værdi, så vil folk og virksomheder gerne betale for det, og bare fordi vi snakker Web Services, behøver afregningen ikke være specielt avanceret

Den største brug af Web Services vil ske mellem virksomheder. Her vil Web Services primært bruges inden for allerede indgåede aftaler. Ideen om, at ukendte og perfekt beskrevne Web Services eksisterer et eller andet sted derude, som skal kunne opdages, skræddersyes og være pålidelige nok til at bygge sin forretning på, beskriver kun en lille og ubetydelig del af mulige services. I realiteten vil de fleste værdifulde Web Service-interaktioner blive udført mellem kendte og troværdige forretningspartnere. Først når to parter har opbygget relationer, eventuelt indirekte via en troværdig tredjepart, vil teknologierne for automatiseret opdagelse bruges til at offentliggøre, finde og muliggøre nye services mellem dem samt forbinde nye versioner af eksisterende services, og her er afregningsdelen lettere håndteret.

"Det kan forventes, at det vil være et kundekrav, at it-leverandørernes løsninger skal være interoperable. It-leverandørernes kunder vil opleve, at deres egne kunder ønsker at få adgang til information på mange forskellige måder. For at være konkurrencedygtig må de tilbyde kunderne en simpel måde at tilgå deres information. Derved vil de sætte krav til deres it- leverandører om, at deres løsninger overholder standarder, så de bliver interoperable."
Phil Wainewrights blog findes her

Introduktion til forbunden troværdighed

Preston Gralla præsentere i disse to artikler begrebet "forbunden troværdighed" og de tilhørende standarder.
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).
Forbundne systemer kan samarbejde på tværs af organisatoriske grænser. Disse systemer kan bygge på forskellige teknologier, forskellige sikkerhedstilgange og programmeringsmodeller. De er autonome forstået på den måde, at de har kontrol over deres egen ”ø”, men er bygget til at samarbejde med andre systemer.
Forbunden identitet er muligheden for sikkert at kunne genkende og forstå en brugers identitet ejet af andre organisationer uden at kræve, at brugeren indtaster navn og password, når han skal have adgang til ens hjemmeside eller Web Service.
Det tillader også organisationen på en sikker måde at dele konfidentielle brugeridentiteter med andre troværdige organisationer samt applikationer på internettet. Når man sikkert kan stole på identiteter fra andre organisationer, og disse organisationer kan stole på de identiteter, som man selv danner, forøges behændigheden i hele værdikæden.
Preston Grallas artikel findes her

SOA, BPM og Event-driven arkitektur

denne pressemeddelelse tager Gartner fat på tre områder: Kombinationen af Business Process Management og SOA, behovet for at opnå erfaring nu for at kunne håndtere SOA når det bliver maninstream i 2007 samt Event-driven arkitektur.

Virksomheder vil gennemløbe tre Web Services-stadier, før de er blevet til en behændig virksomhed: et organisk , et systematisk og et altgennemtrængende stadie.

Det er essentielt, at man begynder med at opnå noget erfaring med Web Services og konstant har et par Web Services-projekter kørende, som langsomt bliver mere og mere komplekse, indtil man behersker udviklingen af Web Services fuldstændigt. Lad være med at serviceorientere alting, før organisationen har opbygget tilstrækkelig viden. Begræns de første projekter til lav-risiko projekter , indtil udviklerne opnår en tilstrækkelig viden om, hvordan Web Services bedst udnyttes i virksomhedens miljø.

De første pilotprojekter bør være processer, der er rimelig godt forstået, rimeligt simple og har veldokumenteret semantik. Det er også vigtigt at huske, at omkostninger og kompleksiteten varierer, afhængig af hvilket miljø der vælges. F.eks. vil eksterne Web Services ofte være vanskeligere at designe end interne, fordi det udvidede omfang introducerer nogle yderligere udfordringer:
Den organiske fase er karakteriseret ved to ting, henholdsvis
uddannelse, hvor virksomheden ikke får nogen fordele af Web Services, men bruger det meste af tiden på at undersøge, hvad andre gør med Web Services, og afprøve offentlige Web Services, samt
eksperimenter, hvor man typisk har et begrænset antal Web Services i produktion, og kun en mindre gruppe af udviklere er dedikeret til disse projekter. Her handler det ikke om effektivitet, men om at lære. Så ting vil tage tid, og tålmodighed er en dyd i denne fase.

I slutningen af dette stadie skal man have opnået erfaring i at bygge simple forbindelser mellem interne applikationer og tætte forretningspartnere.

Pressemeddelelsen findes her

SOA og it som infrastrukturel teknologi

Ronald Schmelzer diskuterer i denne artikel hvordan SOA og outsourcing er et vigtigt aspekt af it's bevægelse mod en infrastrukturel teknologi. Hvor it mere og mere bliver betragtet som en infrastrukturkomponent på linje med jernbaner, elektricitet, telefon og vand.
Virksomheden er derfor nødt til at forholde sig til, at muligheden for længerevarende differentiering ved hjælp af nye innovative it-løsninger bliver vanskeligere, efterhånden som ”it-kraft ” bliver billigere og let tilgængeligt, fordi konkurrenterne lettere kan kopiere løsningen uden krav om store, faste investeringer i starten.

At have adgang til ”it-kraft” vil kun forøge hastigheden, hvormed ændringerne sker på markedet. For at organisationen skal kunne følge med, er det nødvendigt med strategier, der lægger mere vægt på bølger af kortsigtede (typisk seks til tolv måneders) operative initiativer – initiativer, der følger den langsigtede retning udstukket af den overordnede strategi. Ved at fokusere organisationen på rullende bølger af kortsigtede operative initiativer vil denne tilgang opmuntre til innovation, som over tid reflekteres i voksende kompetencer i virksomheden og hurtigere læring. Disse gradvise forbedringer er afhængige af den øjeblikkelige situation og bliver meget vanskelige for konkurrenter at replicere. Konkurrenter kan forsøge at kopiere processen, men fordelen vil holdes ved lige i de rullende bølger af forbedringer.

Indtrængningsbarrieren til en industri er reduceret på grund af den konstant forøgede effektivitet, som nye it-løsninger giver, og den lettere adgang til kunderne, som internettet har medført. Nytilkomne til en industri har ofte 30 procents omkostnings- og effektivitetsfordel i forhold til eksisterende virksomheder, fordi nybyggede systemer er optimeret til den moderne leverancekanal. Ineffektivitet og ufleksibilitet vil derfor straffe virksomheder hårdere.

Ronald Schmelzers artikler findes her

tirsdag, september 05, 2006

XML - For meget af det gode?

David Beckers artikel diskuterer, hvor vigtig XML er blevet efter at have været på banen i 6 år.
Artiklen understreger, at det er vigtigt at have en bevidst standardstrategi i virksomheden. Lav ikke egne formater, men benyt industristandarder. Selv i tilfælde hvor det drejer sig om udveksling mellem to interne systemer, skal der benyttes standarder. Er man konsekvent omkring brug af standarder, forøger det fremtidssikring og fleksibiliteten i ens systemer.
Virksomheden skal være opmærksom på, at der i øjeblikket tages beslutninger i mange industriorganer om, hvordan data og forretningsprocesser skal se ud. Vær derfor bevidst omkring deltagelse i standardorganisationer.

Mange udviklere, der er vant til at optimere alt, vil kigge på XML og sige ”Jeg kan bygge noget, det er ikke helt XML, men det er en slags XML, og jeg er sikker på, at det vil være hurtigere og fylde mindre.” Men det fungerer ikke i det lange løb. Til syvende og sidst er standarderne standarder, og de har en stor værdi på grund af det.

David Beckers artikel findes her

Psykologien i SOA

Jim Ericsson diskuterer her udfordringen med at få forretningen til at forstå og udnytte de muligheder som SOA giver.
It bliver en mere og mere vigtig del af virksomheders konkurrenceevne. Derfor skal der hos it-afdelingerne opnås en bedre forståelse for it’s indvirkning på forretningssiden. På samme måde skal de forretningsorienterede med-arbejdere opnå en større forståelse for, hvad teknologien indeholder, og hvordan den kan udnyttes i praksis
Jim Ericssons artikel findes her

Hvor løs er din kobling?

Den første artikel jeg vil henlede opmærksomheden på, er Jason Bloombergs ”How Loose is your Coupling?”.
Løs kobling er en måde at designe og udvikle på — det er ikke en teknologi. Paradigmeskiftet vil kræve omskoling af mange udviklere samt revidering af udviklingsstrategier. For mange vil det være unaturligt ikke mere at skulle fokusere på let målbare fordele såsom performance og økonomi, men i stedet optimere det mere abstrakte begreb, fleksibilitet

Jason Bloombergs artikel findes her