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.
søndag, november 05, 2006
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
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
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:
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
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
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:
David Chapells artikel findes her
- 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.
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.
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
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
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
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
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
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
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.
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).
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).
Abonner på:
Opslag (Atom)
Opslag
