Resource Oriented Architecture (ROA) November 02, 2007 11:00 over 4 years ago
Elektronisk Tinglysning, elektronisk Pension og elektroniske patient journaler er alle gode eksempler på forretningsområder hvor ressource orienteret arkitektur ville være en naturlig del af løsningen.
Typisk for disse forretningsområder er at de logisk tilhører et sted eller en instans hvorfra det er muligt at udstille de ofte meget vigtige informationer. Man ser meget nødigt et tinglysningsdokument eller en patient journal hos flere aktører på samme tid. Det er dog muligt at vise en repræsentation flere steder samtidigt men nye entiteter eller opdatering styres gennem adgang til ressourcen. Hvis man vil tilføre en kreditor til et tinglysningsdokument får man altså adgang til den ressource hvori en kreditor tilføres. Derefter kan man få en repræsentation af det nye dokument.
Ressource Orienteret Arkitektur er tankemæssigt den dimentrale modpol til Service Orienteret Arkitektur. SOA forholder sig til en distribueret verden og udstiller services, hvori gennem fx et tinglysningsdokument deles mellem mange aktører. ROA forholder sig til ressource og deler kun adgangen til disse ressourcer som logisk kun eksisterer et sted.
Historie
Resource-Oriented Architecture blev nævnt første gang af IBM 2004 {@todo} og siden i en blog entry af Alex Bunardzic med titlen Replacing Service Oriented Architecture with Resource Oriented Architecture som skabte en livlig debat blandt early adopters. I foråret 2007 udkom bogen ‘RESTful Web Services’ af Leonard Richardson & Sam Ruby.
Hvad er Resource Oriented Architecture?
Resource-Oriented Architecture er en metode til at konkretisere et problem til en RESTful webservice. Et arrangement af URI, HTTP og XML der vil arbejde på samme måde som resten af World Wide Web og som både mennesker og maskiner kan udnytte på en let og overskuelig måde.
Resource-Oriented Architecture er også RESTful. Men REST i sig selv er ikke en arkitektur men blot et sæt af designkriterier. En arkitektur kan imødekommer disse designkriterier bedre end andre men der findes ikke en REST arkitektur.
REST er meget generel og ikke forbundet til WWW. REST er ikke afhængig af strukturen i URI’en eller elementer af HTTP protokollen. Men når man taler om web services i forbindelse med ROA binder man automatisk Resource-Oriented Architecture til de teknologier som udgør World Wide Web.
Frasen resource oriented er blevet brugt til at beskrive generelle RESTful arkitekturer men der er langt til den fulde forståelse.
Hvad er en ressource?
En ressource er noget som er vigtig nok til at være tilgængeligt. Alle ressource må som minimum have et navn og en adresse i form af en Uniform Resource Identifier(URI). Hvis ressource ikke har en URI er det ikke en ressource. URI må være entydige og intuitiv. URI bør have struktur og variation på en forudselig måde. En ressource kan godt have to URI men der kan aldrig findes to ens ressource.
Når der findes en ressource med en URI kan man definere to vigtige elementer af ROA: Addressability og Statelessness.
Addressability
Scoping information: the principle of addressability
En applikation er læsbar når den eksponere interessante aspekter af data som ressourcer. Siden ressourcer bliver eksponeret gennem URI, levere en læsbar applikation en URI for hvert stykke værdifuldt information den indeholder. For slutbrugerens perspektiv er dette det vigtigste aspekt ved enhver applikation.
Statelessness
Statelessness eller tilstandsløs betyder at ethvert kald sker i totalt isolation. Når en klient udfører et kald er alle informationer med i selve kaldet. Serven beror sig aldrig på information fra det tidligere kald. Hvis et kald kræver allerede indhentede information må klienten sende det igen.
Tænkt på tilstand i forbindelse med læsbarhed. Læsbarhed siger at alle stykker interessant information som serveren kan levere er ressourcer med sin egen URI. Tilstandsløs siger at alle plausible tilstande fra serveren er også tilstande, og som sådan også givet sine egen URI’er. En klient bør aldrig tvinge en server gennem bestemte trin for at komme i en specifik tilstand.
Der er to typer af tilstande i ROA. Applikations tilstand og ressource tilstand. Serveren kender kun til ressource tilstand. Denne tilstand er ens for alle klienter og lever kun i et enkelt kald mellem klient og server. Derefter er serveren tilstandsløs og kender ingenting til klienten. Applikationen derimod har en indre tilstand, gerne i tæt forbindelse med brugeren. Den nuværende tilstand kommer fra det sidst foretagne kald og dennes repræsentation fra serveren. En klient kan være på side tre mens en anden kun er på side et.
Representations
Når man dele sin applikation op i ressource forøges grænsefladen voldsomt. Brugene kan konstruere URI’er som passer til deres applikationer, men ressource er ikke data men blot repræsentationer af data. Serveren returnerer data i et bestemt format og måske i et bestemt sprog. Dette er en repræsentation af ressourcen. En ressource er kilde til mange repræsentationer.
Et eksempel på en URI: http://host.dk/blog/123.da
Repræsentationer er virkelige effektive når både maskiner og mennesker kan bruge samme grænseflade. Ind i mellem kan repræsentationerne indeholde mere end blot seriliseret data, ofte er repræsentationer hybermedia: dokumenter som indeholder data og links til andre ressource.
Connectedness
I Rod Fielding disputats om Representational State Transfer står ‘Hybermedia as the engine of application state’. Det betyder kort sagt at klient tilstanden ikke bliver gemt på serven men kun er applikations tilstand hos klienten og bliver overført gennem URI’erne. Serveren giver klienten ved at overføre hybermedia links og forms indeni hybertext repræsentationer.
Kvaliteten af fremsendte hybermedia er bla baseret på de næste klikbare tilstande. Se fx google, de sender altid next link, page 2, related to this osv
Det menneskelige Internet er let at benytte fordi det er godt forbundet.
Uniform Interface
Method information: the principle of uniform interface
På World Wide Web er der kun nogle få basale ting man kan gøre med en ressource. HTTP levere fire grundlæggende metoder for de mest almindelige operationer.
@todo Why the Uniform Interface matters
By Frank Vilhelmsen - 3 tags: architecture roa soa - Add comment