advertisement

Resource Oriented Architecture

50 %
50 %
advertisement
Information about Resource Oriented Architecture

Published on February 12, 2008

Author: samijaber

Source: slideshare.net

Description

Resource Oriented Architecture, Symposium DNG
advertisement

Page  Ressource Oriented Architecture L’architecture du Web et le REST

Aurélien Pelletier Architecte Logiciel Expertise Java En charge de la veille technologique Web 2.0 au sein du département innovation d’Atos Origin http://blogpro.toutantic.net Qui ? Page 

Aurélien Pelletier

Architecte Logiciel

Expertise Java

En charge de la veille technologique Web 2.0 au sein du département innovation d’Atos Origin

http://blogpro.toutantic.net

Page  Objectifs Comprendre le style d’architecture REST Comprendre les différences entre service et ressource

Comprendre le style d’architecture REST

Comprendre les différences entre service et ressource

Page  Agenda L’architecture des Mash-Up Crée une application RESTful L’architecture orientée ressource REST Le débat SOAP/REST Ressources & Services

D’un Web de pages

A un web de Ressources

Mash-up

L’approche REST HTTP URI XML Abstraction ( Web 2.0) ‏ ROA Technologies Style d'architecture Architecture Technologies

Crée une application RESTful

http://dng.org/symposium/2008/ http://dng.org/symposium/2008/sessions http://dng.org/symposium/2008/sessions/ROA http://dng.org/symposium/2008/speakers/aurelien http://dng.org/symposium/2008/participants/ 1 Donner un identifiant unique à toutes les choses intéressantes ou Donner une URI à toutes les ressources Page 

http://dng.org/symposium/2008/

http://dng.org/symposium/2008/sessions

http://dng.org/symposium/2008/sessions/ROA

http://dng.org/symposium/2008/speakers/aurelien

http://dng.org/symposium/2008/participants/

2 Permettre plusieurs représentations Page  Représentation GET http://dng.org/symposium/2008/sessions/day1 Accept : text/html

GET http://dng.org/symposium/2008/sessions/day1 Accept : text/html

2 Permettre plusieurs représentations Page  Représentation <sessions> <date>11/02/2008</date> <session id=&quot;1&quot;> <time></time> <name>Session Plénière</name> <summary> Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés. </summary> </session> GET http://dng.org/symposium/2008/sessions/day1 Accept : application/xml

GET http://dng.org/symposium/2008/sessions/day1 Accept : application/xml

2 Permettre plusieurs représentations Page  Représentation <sessions> <date>11/02/2008</date> <session id=&quot;1&quot;> <name>Session Plénière</name> </session> GET http://dng.org/symposium/2008/sessions/day1?format=court Accept : application/xml

GET http://dng.org/symposium/2008/sessions/day1?format=court Accept : application/xml

3 Mettre des liens dans les représentations Page  <sessions> <date>11/02/2008</date> <session id=&quot;1&quot;> <time></time> <name>Session Plénière</name> <summary> Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés. </summary> </session> <session id=&quot;5&quot; ref=&quot; http://dng.org/symposium/2008/sessions/roa &quot;> <time>16:00 - 17:00</time> <name>Resource Oriented Architecture (ROA)</name> <summary></summary> <speaker ref=&quot; http://dng.org/symposium/2008/speakers/aurelien &quot;> Aurélien Pelletier</speaker> </session>

4 Utiliser l'interface uniforme d'HTTP Page 

GET Page  GET retourne une représentation de l'état courant d'une ressource Get est idempotent La même requête produit à chaque invocation le même résultat sur le serveur. Ne change pas l'état d'une ressource

POST crée une nouvelle ressource C'est le serveur qui décide de l'URI de la nouvelle ressource POST n'est pas idempotent ! Crée une nouvelle URI Page  POST

POST crée une nouvelle ressource

C'est le serveur qui décide de l'URI de la nouvelle ressource

POST n'est pas idempotent !

Crée une nouvelle URI

PUT crée ou modifie une ressource Dans le cas d'une création c'est le client qui décide de l'URI de la ressource Change l'état d'une ressource PUT est idempotent DELETE efface logiquement la ressource DELETE est idempotent Page  PUT & DELETE

PUT crée ou modifie une ressource

Dans le cas d'une création c'est le client qui décide de l'URI de la ressource

Change l'état d'une ressource PUT est idempotent

DELETE efface logiquement la ressource

DELETE est idempotent

HEAD Obtenir uniquement les entêtes OPTIONS Liste des méthodes supportées par une ressource HTML 4 ne supporte que GET et POST Page  OPTION & HEAD

HEAD Obtenir uniquement les entêtes

OPTIONS Liste des méthodes supportées par une ressource

HTML 4 ne supporte que GET et POST

Page  Approche services RPC Calculatrice 4 opérations

Page  Approche ressources REST http://calc/soustraction?val1=xx&val2=yy http://calc/multiplication?val1=xx&val2=yy http://calc/addition?val1=xx&val2=yy http://calc/division?val1=xx&val2=yy Calculatrice 4 opérations

Calculatrice 4 opérations Page  http://calc/chiffres/1 http://calc/operations/division http://calc/operations/addition http://calc/operations/... http://calc/calculs/ http://calc/nombres/ Approche ressources REST

Page  Calculatrice 4 opérations PUT /nombres/douze HTTP/1.1 Host: calc <nombre> <dizaine> http://calc/chiffres/1 <dizaine> <unite> http://calc/chiffres/2 <unite> </nombre> 201 Created POST /calculs/ HTTP 1.1 Host: calc <calcul> <nombre> http://calc/ nombres/douze </nombre> <operation> http://calc/operation/addition </operation> <nombre> http://calc/ nombres/cinq </nombre> <calcul> 201 Created Location: http://calc/calculs/UID <result>17</result> Requête Réponse

PUT /nombres/douze HTTP/1.1 Host: calc

<nombre> <dizaine> http://calc/chiffres/1 <dizaine> <unite> http://calc/chiffres/2 <unite> </nombre>

201 Created

POST /calculs/ HTTP 1.1 Host: calc

<calcul> <nombre> http://calc/ nombres/douze </nombre> <operation> http://calc/operation/addition </operation> <nombre> http://calc/ nombres/cinq </nombre> <calcul>

201 Created Location: http://calc/calculs/UID

<result>17</result>

Page  Calculatrice 4 opérations GET /calculs/UID HTTP/1.1 Host: calc 200 OK <calcul> <nombre> http://calc/ nombres/douze </nombre> <operation>http://calc/operation/addition</operation> <nombre> http://calc/ nombres/cinq </nombre> <result ref =&quot;http://calc/nombres/resultUID&quot;>17</result> <calcul>

Application RESTful 1 Identifier les ressources 2 Définir les représentations 3 Relier les représentations par des liens 4 Utiliser l’interface uniforme

1 Identifier les ressources

2 Définir les représentations

3 Relier les représentations par des liens

4 Utiliser l’interface uniforme

Page  Architecture Orientée Ressource

4 ième génération d'architecture Net - Ware 3 tiers Client léger Hard - Ware Mainframe Client passif Soft - Ware Client-server Client lourd Info - Ware ROA Client riche

Page  Affichage Construction des écrans Traitements métiers Données persistantes Données de sessions Mainframe / Client passif

Page  Interface ODBC/JDBC/... Poste client Base de données Client-serveur / Client lourd

3 tiers / Client léger Page  Interface HTTP Navigateur Base de données Serveur d'applications Interface ODBC/JDBC/...

ROA / Client riche Page  Interface de services Ressources Client riche Serveur d'applications Base de données Interface ODBC/JDBC/...

Identifiant, ressource, représentation Page  Architecture of the World Wide Web, Volume One W3C Recommendation 15 December 2004 http://www.w3.org/TR/webarch/

Cool URI don't change L'URI fait partie de l'interface publique URI are opaque Utiliser des URI logiques plutôt que physiques: http://dng.org/symposium/2007/sessions.html => Couplage faible => Evolutivité => Lisibilité Cool URI don't change Page 

Cool URI don't change

L'URI fait partie de l'interface publique

URI are opaque

Utiliser des URI logiques plutôt que physiques:

http://dng.org/symposium/2007/sessions.html

=> Couplage faible

=> Evolutivité

=> Lisibilité

REST Page 

Page  Representational State Transfer REST Le terme provient de la thèse de Roy Fielding en 2000 - principal architecte d'HTTP 1.1 - co-auteur de la spécification des URI. L'appel à GET transfère la représentation d'une ressource. Cette représentation place le client dans un certain état. Suivre un lien va transférer une nouvelle représentation et changer l'état du client. => Representational State Transfer

Page  Representational State Transfer REST est un style d'architecture Un style d'architecture est un ensemble de contraintes cohérentes qui en limitant un système lui procure des propriétés désirées. REST capture les principes fondamentaux qui font le succès du Web. REST décrit les contraintes qui permettent au web d'être simple, performant, fiable, scalable et évolutif

REST est un style d'architecture

Un style d'architecture est un ensemble de contraintes cohérentes qui en limitant un système lui procure des propriétés désirées.

REST capture les principes fondamentaux qui font le succès du Web.

REST décrit les contraintes qui permettent au web d'être simple, performant, fiable, scalable et évolutif

Envoyer un message sur le réseau Page 

Page  Principes d'architecture généraux

Page  Principes d'architecture généraux Système en couche Capacité à monter en charge Sécurité Intégration au legacy Code à la demande (optionnel) Evolutivité Javascript => AJAX

Interface uniforme Fonctionne avec 4 contraintes complémentaires Identification des ressources (URI) Manipulation des ressources par des représentations Messages auto-descriptif L’Hypermedia comme moteur de l’état de l’application L’interface uniforme (principe de généricité) + Simplicité + Evolutivité - Efficacité

Le débat: SOAP vs REST Page 

Ressources et Services Page  Objectif Style d'architecture REST SOAP WSDL UDDI WS-* HTTP URI XML Aligner l'IT sur le métier Aligner l'IT sur le Web SOA Ressources Services + Architecture ROA Technologies

Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans d’HTTP seul HTTP vs SOAP Technologies

Web Services = SOAP + WSDL + UDDI +WS-* Où est le Web dans ces Web Services ? - Mauvaise utilisation du protocole HTTP - Pas d'URI Il faut trouver un autre nom Big Web Services vs Light Web Services Un service web léger est un site web navigable par les machines Page  Web Services ?

Web Services = SOAP + WSDL + UDDI +WS-*

Où est le Web dans ces Web Services ?

- Mauvaise utilisation du protocole HTTP

- Pas d'URI

Il faut trouver un autre nom

Big Web Services vs Light Web Services

Un service web léger est un site web navigable par les machines

Page  WS-* est trop complexe Ce sont les « big vendors » qui ont inventé et poussent SOAP / WS-*

Interopérabilité Page  SOAP WS-* => Design by commitee Interopérabilité moyenne REST s'appuie sur des standards existant et largement répandu: Identification des ressources URI Transport et l'interface générique HTTP Représentations HTML , XML, gif, ... Type Mime Des clients HTTP et des parseurs XML de qualité sont disponibles pour tous les langages Véritable Interopérabilité SOAP/WS-* sont les DRM de la SOA, HTTP en est le MP3.

Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans de SOAP HTTP vs SOAP Technologies

Page  Fonctionnalités avancées

Page  Conversation machine to machine HTTP + XML fonctionne très bien pour les échanges Humain/serveur au travers d'un navigateur. SOAP/WS-* est plus adapté pour des échanges bidirectionnels entre composants serveur machine to machine.

REST-ROA / SOA Page  Style d'architecture REST SOA Architecture ROA

REST-ROA / SOA Page  REST/ROA Un travail théorique de référence (thèse de Fielding)‏ Une architecture: celle définie par le W3C Une implémentation: le Web Des principes et des contraintes d'architectures bien définis Approche bottom-up Hérite de la culture du Web SOA Englobe le style d'architecture et les architectures Pas de contraintes d'architectures ou de principe universellement reconnus Approche bottom-up Hérite de la culture Entreprise et RPC/CORBA/DCOM

REST/ROA

Un travail théorique de référence (thèse de Fielding)‏

Une architecture: celle définie par le W3C

Une implémentation: le Web

Des principes et des contraintes d'architectures bien définis

Approche bottom-up

Hérite de la culture du Web

SOA

Englobe le style d'architecture et les architectures

Pas de contraintes d'architectures ou de principe universellement reconnus

Approche bottom-up

Hérite de la culture Entreprise et RPC/CORBA/DCOM

Ressources et Services Page  Ressources Services

Ressources et Services Page  Une seule interface uniforme générique Plusieurs interfaces spécialisées Verbes Noms Services Ressources Orienté données Plus de possibilités de réutilisation Moins de contrôle Plus de simplicité Orienté traitement Meilleure efficacité Plus de contrôle Plus de complexité

Accéder à une donnée avec un service? getFacture(Identifiant)‏ serialization/deserialization XML Accéder à un traitement avec une ressource? Une ressource est une abstraction on peut mapper un traitement sur une ressource. Ce n'est pas toujours pertinent (service de conversion de température)‏ En mappant un traitement sur une ressource on lui donne une URI (utile pour retrouver une commande)‏ Il faut faire de l'URI design nouvelle compétence Ressources et Services Page 

Accéder à une donnée avec un service?

getFacture(Identifiant)‏

serialization/deserialization XML

Accéder à un traitement avec une ressource?

Une ressource est une abstraction on peut mapper un traitement sur une ressource.

Ce n'est pas toujours pertinent (service de conversion de température)‏

En mappant un traitement sur une ressource on lui donne une URI (utile pour retrouver une commande)‏

Il faut faire de l'URI design nouvelle compétence

Ressources et Services Page  Traitements Données Back end Front end Services SOA SOAP/WS-* Ressources REST HTTP

Softwares + Services + Ressources Page  procédural Objet Service Service procédural Objet procédural procédural Objet Ressource

Page  “ 25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a Service d'ici 2011” Fin du débat propriétaire VS open source Importance du lock-in par les données. L'important est/sera la portabilité des données Open Data Softwares + Services + Ressources

“ 25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a Service d'ici 2011”

Fin du débat propriétaire VS open source

Importance du lock-in par les données.

L'important est/sera la portabilité des données

Open Data

Intéropérabilité (HTTP + XML) + Adressabilité (URI)‏ Surface de contact plus grande avec les applications Favorise la sérendipité ( serenpidity ) «  L'art de faire une découverte intéressante en cherchant autre chose  » Donc l'innovation Innovation Page 

Intéropérabilité (HTTP + XML) + Adressabilité (URI)‏

Surface de contact plus grande avec les applications

Favorise la sérendipité ( serenpidity )

«  L'art de faire une découverte intéressante en cherchant autre chose  »

Donc l'innovation

Restafarians ? Page 

La bible Page 

Le nouveau testament Page 

Les apôtres Pete Lacey http://wanderingbarque.com/nonintersecting/ Stefan Tilkov http://www.innoq.com/blog/st/ Bill de Hora http://dehora.net/journal/ Mark Baker http://www.markbaker.ca Steve Vinoski http://steve.vinoski.net/blog/ Stuart Charlton http://www.stucharlton.com ... YOU ? Page 

Pete Lacey http://wanderingbarque.com/nonintersecting/

Stefan Tilkov http://www.innoq.com/blog/st/

Bill de Hora http://dehora.net/journal/

Mark Baker http://www.markbaker.ca

Steve Vinoski http://steve.vinoski.net/blog/

Stuart Charlton http://www.stucharlton.com

...

YOU ?

Conclusion Page  4ième génération d'architecture Softwares + Services + Ressources Open Data L'approche orienté ressources + interface uniforme est l’un des moteurs de l'innovation sur le Web

4ième génération d'architecture

Softwares + Services + Ressources

Open Data

L'approche orienté ressources + interface uniforme est l’un des moteurs de l'innovation sur le Web

- IstockPhoto pour les photos - Le projet Crystal pour les icônes - Mes collègues d'Atos Origin pour leurs retours critiques Remerciements

- IstockPhoto pour les photos

- Le projet Crystal pour les icônes

- Mes collègues d'Atos Origin pour leurs retours critiques

Page  Annexes

HTTP ne garanti pas la livraison d'un message Mais GET/PUT/DELETE sont idempotent On peut renouveler l'appel jusqu'à obtenir une réponse Problème avec POST Utiliser une « ressource factory » pour obtenir une url pointant vers une ressource « vide » Utiliser PUT Page  Comment gérer la fiabilité en HTTP

HTTP ne garanti pas la livraison d'un message

Mais GET/PUT/DELETE sont idempotent

On peut renouveler l'appel jusqu'à obtenir une réponse

Problème avec POST

Utiliser une « ressource factory » pour obtenir une url pointant vers une ressource « vide »

Utiliser PUT

Add a comment

Related pages

Resource-oriented architecture - Wikipedia

In software engineering, a resource-oriented architecture (ROA) is a style of software architecture and programming paradigm for designing and developing ...
Read more

Resource-Oriented Architecture: The Rest of REST

In this first article in the Resource-Oriented Architecture series, Brian Sletten discusses the REST architecture style, the history of SOA, SOAP and WS ...
Read more

ROCA: Resource-oriented Client Architecture

Resource-oriented Client Architecture. A collection of simple recommendations for decent Web application frontends. Home; FAQ; Libraries; Discussion ...
Read more

Resource Oriented Architecture and REST - INSPIRE EU

Assessment of impact and advantages on INSPIRE EUR 23397 EN - 2008 Resource Oriented Architecture and REST Roberto Lucchi, Michel Millot European Commission
Read more

What is resource-oriented architecture (ROA)? - Definition ...

A resource-oriented architecture (ROA) is the structural design supporting the internetworking of resources. A resource, in this context, is any entity ...
Read more

Resource-Oriented Architecture Patterns for Webs of Data ...

Lesen Sie Resource-Oriented Architecture Patterns for Webs of Data von Brian Sletten mit Kobo. The surge of interest in the REpresentational State Transfer ...
Read more

Resource-Oriented Architecture Patterns for Webs of Data ...

Brian Sletten - Resource-Oriented Architecture Patterns for Webs of Data - Buchhandel.de - Bücher lokal kaufen
Read more

Representational state transfer - Wikipedia

Representational state transfer ... Resource-oriented architecture (ROA) Resource-oriented computing (ROC) Semantic URLs; Service-oriented architecture (SOA)
Read more

Resource-Oriented Architecture: Resource Metadata

In this second article in the Resource-Oriented Architecture series, Brian Sletten discusses the benefits of REST, what constitutes a resource, associating ...
Read more

RESTful Web Services - Crummy

Deprecation notice: RESTful Web Services has been replaced by a new book, ... Chapter 10: The Resource-Oriented Architecture versus Big Web Services.
Read more