Jeg vil igang med at lave en "Cross Domain Mashup":http://www.frankvilhelmsen.com applikation der asynkront kan hente data fra forskellige domains. Min klient er i HTML5, CSS3 og naturligvis Javascript. Protokollen er HTTP, kommunikation er asynchronous og indholdet skal være JSON fordi det allerede er Javascript, kompakt og ikke behøver parsing af nogen art. JSON skal pakkes ind JSONP for at overvinde Same Origin Policy sikkerheds modellen. Flickr Flickr er en fantastisk ressource til at præsentere og administrere billeder. De udstiller også en stribe API'er til mange forskellige ting. Jeg har kun interesser for "REST API'et":http://www.flickr.com/services/api Den præcise URI jeg vil bruge er til min egen foto feed på flickr. Det er værd at bemærke de sidste parameter i URI'en "format=json&jsoncallback=?". Disse paramter fortæller resourcen at response skal være i formattet JSON og at kaldet måske er Cross Browser og derfor skal JSON pakkes ind som et JSONP kald. Ydermere kan man specificere et callback navn "joncallback=?" ved spørgsmålstegnet hvis man vil have en bestemt metode kaldt når script er loadet. | URI | JSONP | | &format=json | jsonFlickrFeed({ "title":"Uploads" }) | | &format=json&jsoncallback=? | ({ "title": "Uploads"}) | | &format=json&jsoncallback=visfoto | visfotos({ "title": "Uploads"}) | Det kan betale sig at undersøge data grundigt inden man går igang med at skrive klienten. Hvis man kan operere/navigere med curl -i URI gennem de ønskede scenarie er man langt. Nu klienten. <pre> $(document).ready(function(){ $.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?id=7185299@N07&format=json&jsoncallback=?", function(data){ $.each(data.items, function(i,item){ $("<img/>").attr("src", item.media.m).appendTo("#images"); if ( i == 8 ) return false; }); }); }); </pre> Flickr ressourcen bliver ramt gennem Jquery og henter data. Der itereres gennem data der indeholder title, link til foto location, hvornår det er taget og en masse andet. Elementet item.media er en server location men der følger et m med som fortæller noget om de størrelse og repræsentationer som billedet allerede er skaleret til. Prøv fx at skifte m ud med et s. Nu til den næsten klient app som er twitter updates. Koden herunder henter et antal twitter status update og iterere gennem hver update. Undervejs ledes efter regulære udtryk der minder om et link tag og hvis udskiftes med et rigtig html link anker. Hver update bliver adderet til hash# div tag. Det er muligt at bruge this[array] til at hente data ud af strukturen. Læg også mærke til at twitter vil have en count parameter med ind for at minimere antal updates over linjen. Bemærk også at er mere REST aware i det de udnytter HTTP header information om den returnerede repræsentation og caching TTL i netværket. De udnytter infrastrukturen bedre end flickr. <pre> var regexp = /((ftp|http|https):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?)/gi; $(document).ready(function(){ $.getJSON("http://twitter.com/statuses/user_timeline/frankvilhelmsen.json?count=6&callback=?", function(data, textStatus) { $.each(data, function(i) { var twitter_time = prettyDate(this['created_at']) var twitter_uri_encoded_text = this['text'].replace(regexp,'<a href="$1">$1</a>') $("#statuses").append("<li>"+twitter_time+": "+twitter_uri_encoded_text+"</li>"); }); }); }); </pre> Server Indtil nu har jeg kun forbrugt ressource hvor jeg kun kender interfacet men jeg vil jo også gerne udstille mine egne REST baseret Cloud ressourcer. Heldigvis understøtte rubyonrails dette lige ud af boxen. Min platform er "Heroku | Ruby Cloud, Platform as a Service":http://heroku.com git og Rails. DNS og alt er sat op. <pre> p = Post.find(:all, :select => 'id, title, osv') response_to ... format.json {render :json => @posts, :callback => [:callback] } end </pre> Det eneste jeg skal gøre for at enable en ressource til cross browser er tilføje denne ":callback => [:callback]". Rails har altså dekoreret JSON til JSONP format uden at jeg behøver at gøre mere. Men måske ville jeg reagere anderledes på ønsket om at give parameter som denne med i requestet "&callback=chanceheader". Direkte til klienten. Og nu er det nemt for koden er næsen det samme som før. <pre> $(document).ready(function(){ $.getJSON("http://XXX/posts/title/all?format=json&callback=?", function(data){ $.each(data, function(i) { $("#titles").append("<li>"+this.post.id+" - " +this.post.title+"</li>") }); }); }); </pre> 2010-01-22T11:49:10Z 157 157 true 25 2010-01-22T14:32:11Z Titlen på denne post kan måske forekomme misvisende eller ligefrem tvetydig idet den blander to paradigmer, to protokoller og to praktiske modeller. Men netop denne dualisme og tværgående egenskaber kan resultere i en styrke. Abstrakt handler dette blot om at se på services som resource. Denne post har absolut intet at gøre med REST men kun om brug og kombination af enkle og gode egenskaber omkring HTTP Applikations Protokollen. For at komme i gang vil jeg lige sige et par ord om Mocks. Mocks er objekter der indenholder en forventet reaktion. Man kunne fx mock'e information om "processen af købe en kop kaffe":http://www.frankvilhelmsen.com/posts/33-Caf-shop i nogle trin uden af kende hele den samlede proces til bunds. På den måde ville kaffe tørstige sjæle kunne benytte cafe-service'en ved at bestille forskellige type af kaffe. Endda før kaffebaren er helt færdig. En Stub derimod ville i samme senarie blot returnere den samme kedelige kop kaffe hvergang uden nogen hensyntagen til modtageren. Hvad har kaffe med SOAP at gøre? Jo, jeg har modtaget en række løstformulererede krav til en SOAP service der kan erstatte en ESB. Kravende indeholder ord som enkelhed, robusthed og fleksibel. Sjovt nok hænger de egenskaber ikke naturligt sammen med de flestes opfattelse af SOAP og WS-. Jeg må blankt indrømme at jeg normalt løber min vej når talen kommer ind på SOA, SOAP og WS- "dødsstjerne teknoliger":http://www.frankvilhelmsen.com/posts/56-WS-Death-Star Men på samme måde som en skatterevisor til fest er min interesse altid på ca. 50 procent når noget er dukket op på området. Min holdning er blot at jeg kan tilføre mere værdi med andre metoder. Som udgangspunkt enig med med folkene bag "http://soa-manifesto.org":http://soa-manifesto.org om at SOA som arkitektur er en god ting og SOAP som protokol er noget markværk. Derfor vil jeg bryde alle (mine) principper og forsøge at angribe med ord som "Brute Force" og "WS-* Duck-Typing":http://www.frankvilhelmsen.com/posts/21-WS-Duck-typing Når man operaer med "Brute Force!" metoden er det næsten det samme bare med mere traditionelle værktøjer. Paul Sandoz fra SUN, som i øvrigt sidder i ekspertgrupperne JSR-154, JSR-224, JSR-311 har på en konference fortalt mig at man kan se på enhver SOAP besked som en resource. Og hvis ikke er der et design issue. Derfor vil jeg i dette forsøge at udstille et SOAP endpoint som en resource. Eller rettere, forbrugeren vil ikke opdage en forskel men blot kalde en service som sædvandeligt men for service udbyderen er der en væsenlig forskel. Klienten kalder med JSR-244 (JAX-WS) og serveren svare med JSR-311(JAX-RS). Med denne metode kan jeg overholde WS-* Ducktyping principperne og på samme tid arbejde highlevel mod HTTP protokollen uden de afledte effekter som codeeksplosion, classeksplosion interoperability og de andre aspekter der bunder i en tæt bundet SOAP protokol. SOAP definere sin egne protokol ovenpå HTTP protokollen og den abstraktion er vigtig set ud fra det perspektiv at man kan skifte transportlag til JMS eller noget andet. Men hvis man kun bruger HTTP som transport er det naturligvis kun en abstraktion der altid vil ende med "Law of leaking abstractions by Joel Spolsky":http://www.joelonsoftware.com/articles/LeakyAbstractions.html I denne context er Highlevel er lig med det "Uniforme Interface":http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm fra REST der tilbyder ensartede operationer på tværs af alle komponenter. Det er en kæmpe fordel frem for SOAP protokollen hvor hver WSDL definere et specifikt service interface. Med SOAP arbejder man med et lag ovenpå http protokollen mens man med REST arbejder med protokollerne og derfor siges det at abstraktionen mellem de to fremgangsmåder er på forskellige plan. Resoucen <pre> @Path("/Customer") public class CustomerResource { @POST @Consumes("appliction/soap-xml;charset=UTF-8") @Produces("appliction/soap-xml;charset=UTF-8") public String method(String body) { ... } } </pre> Denne resource klasse repræsentere en kunde. Path symbolet viser den relative URI til ressourcen. For at kunne attakere denne metode som en resource kan man fx sende et HTTP (@POST) med den rette content-type (@Consumes) i HTTP headeren. Metoden modtager en SOAP besked og returnere en SOAP (@Produces) besked. Hvordan beskeden teknisk behandles i metoden er ligegyldigt. For en brugern af denne SOAP service er det transparent at der benyttes ressource. Ved en fejl i metoden returenes naturligvis en "optional SOAP Fault element". Det er muligt at skabe en @Singelton instans ved at tilføre en annotation. Således finder der kun den samme ressource for alle consumere og det er muligt at udnytte den feature på flere måder end jeg kan komme på her. Ved Mocking er det selvvalgt en naturlig ting idet man kan ændre indhold på ressource output i køretid. Under normale forhold vil vi naturligvis stræbe efter stateless resourcer for at bibeholde egenskaber som skalerbarhed, samtidighed osv. Indtil nu er der kun brugt annoteringer fra API'et på en POJO Java klasse men det er tid at vælge hvilken implementation der skal bruges. Jeg bruger JAX-RS API og SUN's Jersey 1.1 reference implementation fordi den er langt den mindste jeg kender og har en opstartstid jeg kan udholde. Ikke et ond ord om Apache CXF der har suppport for JAX-RS i sin JAX-WS implementation. Registrering og brug af denne resource kan ske på flere måder, både standalone og i container. Jersey har en super cool scanner der selv register klasser efter annotationer og binder dem til det rigtige endpoint der dekoreres dels i Web.xml og dels direkte i annotationer. Det bliver ikke bedre end det. :-) En af de stærke sider ved Jersey er deres client interface. Kan ikke lade være at vise en stumt kode der simulere et SOAP WS kald mod en ESB eller whatever du nu har. Læg især mærke til den dejligt "Java Fluent Interface":http://www.frankvilhelmsen.com/posts/111-Fluent-interface måde man opbygger sin request på, næsten i DSL stil. Mange forskellige teknologier har adopteret og overholder HTTP, Servlets og JAX-WS. Det betyder at man kan bruge en ressource som et endpoint for alle komponenter der taler samme sprog. De vil aldrig vide hvad der ramte dem. På samme måde kan man bruge klientdelen til at invokere fx ESP endpoints. Det er faktisk sjovt. <pre> Client client = Client.create(); WebResource endpoint = client.resource(uri); ClientResponse response = endpoint. type("application/soap+xml;charset=utf-8"). accept("application/soap+xml;charset=utf-8"). post(ClientResponse.class, xml); int status = response.getStatus(); String s = response.getEntity(String.class); </pre> Jersey og hele REST tankegange er baseret tæt omkring HTTP Applikations Protokollen. Man er "ON The Web" eller en del af "The Semantic Web":http://en.wikipedia.org/wiki/Semantic_Web og ens applikation kan understøtte "Linkede Data":http://en.wikipedia.org/wiki/Linked_Data Med disse tanker og metoder smelter applikationen sammen med internettet. Den forrige resource "/resource/Customer" vil blive ramt af SOAP klienter. Men jeg kan ikke dy mig for at lade den samme resource blive brugt af simpelt AJAX (Asynchronous JavaScript and XML). Med AJAX kan man fra Javascript kommunikere med en server gennem XMLHttpRequest objektet uden at reload HTML siden. En anden ting er, at man kan kontroller stort set alle de ekstra header informationer som overføres til serveren hvilkent betyder at man kan rammer en resource fx med en bestemt content-type. <pre> new Ajax.Request("/resource/Customer", { method:'GET', asynchronous:true, requestHeaders: ['Content-Type', 'text/html;charset=UTF-8'], onSuccess: function(transport){ $('message').update(transport.responseText); }, onFailure: function(transport){ $('message').update(transport.responseText); } }); </pre> Denne metode laver en GET på ressourcen Custormer og forventer at modtage en repræsentation af dennes response i form af HTML. Hvis man skal bruge JSON skal man kun ændre content-type til "applikation/JSON". Hvis man i stedet vil POST'e et ændret indhold ind i ressourcen kan man bruge denne form: <pre> new Ajax.Request("/resource/Customer", { method:'POST', asynchronous:true, requestHeaders: ['Content-Type', 'appliction/xml;charset=UTF-8'], postBody: $F('body'), onSuccess: function(transport){ ... </pre> Dette POST bindes sammen med ressourcen gennem POST med content-type 'appliction/xml;charset=UTF-8' og forventer at modtage en Customer i XML format som input i HTTP body. Hvis ressourcen ikke har implementeret denne indgang svares med "Status Code 415 Unsupported Media Type":http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Fik jeg så hvad jeg kom efter? Ja, det synes jeg. Ved at mappe ressource til simulering af SOAP endpoints og Servlets side om side fik jeg en cross platform, cross service implementation og mere clean snitflade uden de logiske layer som jeg hader. Håber bare at mine kravsstiller ikke vil skifte transport metode. Anyways, det sker nok alligevel aldrig. At efterleve DuckTyping principperne er en fornøjelse og jeg har virkelig hygget mig undervejs. Tak til Paul Sandoz for at starte den ide i mit hoved i 2007. 2009-11-06T17:28:12Z 151 151 true 25 2009-11-06T17:32:11Z 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":http://roy.gbiv.com disputats om "Representational State Transfer (REST)":http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 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 11 2007-11-02T11:00:00Z 80 80 false 25 2008-02-18T09:46:14Z If you are an architect or developer working on service-oriented architecture projects you probably are not doing representational state transfer now. But within the next five years you will. Looking to the future, Burton predicts that REST adoption is now and in the next three, five and 10 years. Today, it is only innovators that are really working with REST. But within the next three years we should see the early adopters start to play with REST. It will probably be five years before it is adopted by the early majority. What will drive REST adoption eventually is that it brings structure in the form of constraints to the sometimes chaotic world of Web services It will provide a level of maturity for SOA development. So what does this mean to IT departments in general, and enterprise architects and developers in particular? It depends on the skills of the architects and developers and their willingness to think outside the box of object-oriented programming. The basic concept of REST which starts with sending out GET commands sent via HTTP to URIs to retrieve data is simple enough. But noted that even long-time REST advocates admit having trouble thinking of applications in terms of REST. Frameworks and tools for designing and building such REST applications are coming from major vendors, especially IBM and Microsoft which are making major investments in the technology, she said. It is also coming from the open source community. The new version 2.0 of Ruby on Rails will make it easier to do REST Web services. A major vendor commitment was confirmed this past week by Jerry Cuomo, IBM Fellow and WebSphere CTO, who said in an interview at IBM's Impact 2007 conference in Orlando, that Big Blue also sees REST as the next big thing. But architects and developers will not have long to wait before REST is baked into frameworks. You're going to see some very interesting frameworks come down the line in the not too distant future. 3 2007-06-03T22:50:00Z 44 44 false 25 2008-04-08T07:25:16Z