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