Page     Ressource Oriented Architecture L’architecture du Web et le REST
<ul><li>Aurélien Pelletier </li></ul><ul><ul><li>Architecte Logiciel </li></ul></ul><ul><ul><li>Expertise Java </li></ul><...
Page     Objectifs <ul><li>Comprendre le style d’architecture REST </li></ul><ul><li>Comprendre les différences entre ser...
Page     Agenda L’architecture des Mash-Up Crée une application RESTful  L’architecture orientée ressource REST Le débat ...
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
<ul><ul><li>http://dng.org/symposium/2008/ </li></ul></ul><ul><ul><li>http://dng.org/symposium/2008/sessions </li></ul></u...
2  Permettre plusieurs  représentations Page     Représentation <ul><ul><ul><li>GET  http://dng.org/symposium/2008/sessio...
2  Permettre plusieurs  représentations Page     Représentation <sessions> <date>11/02/2008</date> <session id=&quot;1&qu...
2  Permettre plusieurs  représentations Page     Représentation <sessions> <date>11/02/2008</date> <session id=&quot;1&qu...
3   Mettre des  liens  dans les  représentations Page     <sessions> <date>11/02/2008</date> <session id=&quot;1&quot;> <...
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...
<ul><li>POST crée une nouvelle ressource </li></ul><ul><li>C'est le serveur qui décide de l'URI de la nouvelle ressource <...
<ul><li>PUT crée ou modifie une ressource </li></ul><ul><li>Dans le cas d'une création c'est le client qui décide de l'URI...
<ul><li>HEAD Obtenir uniquement les entêtes </li></ul><ul><li>OPTIONS Liste des méthodes supportées  par une ressource </l...
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 htt...
Calculatrice 4 opérations Page     http://calc/chiffres/1 http://calc/operations/division  http://calc/operations/additio...
Page     Calculatrice 4 opérations <ul><li>PUT /nombres/douze HTTP/1.1 Host: calc </li></ul><ul><ul><ul><ul><li><nombre> ...
Page     Calculatrice 4 opérations GET /calculs/UID HTTP/1.1 Host: calc 200 OK <calcul> <nombre> http://calc/ nombres/dou...
Application RESTful <ul><li>1 Identifier les ressources </li></ul><ul><li>2 Définir les représentations </li></ul><ul><li>...
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-s...
Page     Affichage Construction  des écrans Traitements métiers Données  persistantes Données de sessions Mainframe  /  C...
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 Inter...
Identifiant, ressource, représentation Page     Architecture of the World Wide Web, Volume One W3C Recommendation 15 Dece...
<ul><li>Cool URI don't change </li></ul><ul><ul><li>L'URI fait partie de l'interface publique </li></ul></ul><ul><li>URI a...
REST Page  
Page     Representational State Transfer REST Le terme provient de la thèse de Roy Fielding en 2000 - principal architect...
Page     Representational State Transfer <ul><li>REST est un  style d'architecture </li></ul><ul><ul><li>Un style d'archi...
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 C...
Interface uniforme Fonctionne avec 4 contraintes  complémentaires   Identification des ressources (URI) Manipulation des r...
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...
Page     SOAP WSDL UDDI WS-* HTTP URI XML Les arguments  des partisans d’HTTP seul HTTP vs SOAP Technologies
<ul><ul><li>Web Services = SOAP + WSDL + UDDI +WS-* </li></ul></ul><ul><ul><li>Où est le Web dans ces Web Services ? </li>...
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 exis...
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...
REST-ROA / SOA Page     Style d'architecture REST SOA Architecture ROA
REST-ROA / SOA Page     <ul><li>REST/ROA </li></ul><ul><ul><li>Un travail théorique de référence (thèse de Fielding)‏ </l...
Ressources et Services Page     Ressources Services
Ressources et Services Page     Une seule interface uniforme générique Plusieurs interfaces spécialisées Verbes Noms Serv...
<ul><li>Accéder à une donnée avec un service? </li></ul><ul><ul><li>getFacture(Identifiant)‏ </li></ul></ul><ul><ul><li>se...
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 ...
Page     <ul><ul><li>“ 25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a ...
<ul><li>Intéropérabilité (HTTP + XML) + Adressabilité (URI)‏ </li></ul><ul><ul><li>Surface de contact plus grande avec   l...
Restafarians ? Page  
La bible Page  
Le nouveau testament Page  
Les apôtres <ul><li>Pete Lacey  http://wanderingbarque.com/nonintersecting/ </li></ul><ul><li>Stefan Tilkov  http://www.in...
Conclusion Page     <ul><li>4ième génération d'architecture </li></ul><ul><li>Softwares + Services + Ressources </li></ul...
<ul><li>-  IstockPhoto  pour les photos </li></ul><ul><li>- Le  projet Crystal  pour les icônes </li></ul><ul><li>- Mes co...
Page     Annexes
<ul><li>HTTP ne garanti pas la livraison d'un message </li></ul><ul><li>Mais GET/PUT/DELETE sont idempotent </li></ul><ul>...
Prochain SlideShare
Chargement dans…5
×

Resource Oriented Architecture

5 863 vues

Publié le

Resource Oriented Architecture, Symposium DNG

Publié dans : Technologie
1 commentaire
3 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
5 863
Sur SlideShare
0
Issues des intégrations
0
Intégrations
230
Actions
Partages
0
Téléchargements
216
Commentaires
1
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Entreprise JavaBeans 3.0 Entreprise JavaBeans 3.0
  • Resource Oriented Architecture

    1. 1. Page  Ressource Oriented Architecture L’architecture du Web et le REST
    2. 2. <ul><li>Aurélien Pelletier </li></ul><ul><ul><li>Architecte Logiciel </li></ul></ul><ul><ul><li>Expertise Java </li></ul></ul><ul><ul><li>En charge de la veille technologique Web 2.0 au sein du département innovation d’Atos Origin </li></ul></ul><ul><ul><li>http://blogpro.toutantic.net </li></ul></ul>Qui ? Page 
    3. 3. Page  Objectifs <ul><li>Comprendre le style d’architecture REST </li></ul><ul><li>Comprendre les différences entre service et ressource </li></ul>
    4. 4. 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
    5. 5. D’un Web de pages
    6. 6. A un web de Ressources
    7. 7. Mash-up
    8. 8. L’approche REST HTTP URI XML Abstraction ( Web 2.0) ‏ ROA Technologies Style d'architecture Architecture Technologies
    9. 9. Crée une application RESTful
    10. 10. <ul><ul><li>http://dng.org/symposium/2008/ </li></ul></ul><ul><ul><li>http://dng.org/symposium/2008/sessions </li></ul></ul><ul><ul><li>http://dng.org/symposium/2008/sessions/ROA </li></ul></ul><ul><ul><li>http://dng.org/symposium/2008/speakers/aurelien </li></ul></ul><ul><ul><li>http://dng.org/symposium/2008/participants/ </li></ul></ul>1 Donner un identifiant unique à toutes les choses intéressantes ou Donner une URI à toutes les ressources Page 
    11. 11. 2 Permettre plusieurs représentations Page  Représentation <ul><ul><ul><li>GET http://dng.org/symposium/2008/sessions/day1 Accept : text/html </li></ul></ul></ul>
    12. 12. 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> <ul><ul><ul><li>GET http://dng.org/symposium/2008/sessions/day1 Accept : application/xml </li></ul></ul></ul>
    13. 13. 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> <ul><ul><ul><li>GET http://dng.org/symposium/2008/sessions/day1?format=court Accept : application/xml </li></ul></ul></ul>
    14. 14. 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>
    15. 15. 4 Utiliser l'interface uniforme d'HTTP Page 
    16. 16. 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
    17. 17. <ul><li>POST crée une nouvelle ressource </li></ul><ul><li>C'est le serveur qui décide de l'URI de la nouvelle ressource </li></ul><ul><li>POST n'est pas idempotent ! </li></ul><ul><li>Crée une nouvelle URI </li></ul>Page  POST
    18. 18. <ul><li>PUT crée ou modifie une ressource </li></ul><ul><li>Dans le cas d'une création c'est le client qui décide de l'URI de la ressource </li></ul><ul><li>Change l'état d'une ressource PUT est idempotent </li></ul><ul><li>DELETE efface logiquement la ressource </li></ul><ul><li>DELETE est idempotent </li></ul>Page  PUT & DELETE
    19. 19. <ul><li>HEAD Obtenir uniquement les entêtes </li></ul><ul><li>OPTIONS Liste des méthodes supportées par une ressource </li></ul><ul><li>HTML 4 ne supporte que GET et POST </li></ul>Page  OPTION & HEAD
    20. 20. Page  Approche services RPC Calculatrice 4 opérations
    21. 21. 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
    22. 22. 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
    23. 23. Page  Calculatrice 4 opérations <ul><li>PUT /nombres/douze HTTP/1.1 Host: calc </li></ul><ul><ul><ul><ul><li><nombre> <dizaine> http://calc/chiffres/1 <dizaine> <unite> http://calc/chiffres/2 <unite> </nombre> </li></ul></ul></ul></ul><ul><ul><ul><ul><li>201 Created </li></ul></ul></ul></ul><ul><li>POST /calculs/ HTTP 1.1 Host: calc </li></ul><ul><ul><li><calcul> <nombre> http://calc/ nombres/douze </nombre> <operation> http://calc/operation/addition </operation> <nombre> http://calc/ nombres/cinq </nombre> <calcul> </li></ul></ul><ul><li>201 Created Location: http://calc/calculs/UID </li></ul><ul><ul><li><result>17</result> </li></ul></ul>Requête Réponse
    24. 24. 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>
    25. 25. Application RESTful <ul><li>1 Identifier les ressources </li></ul><ul><li>2 Définir les représentations </li></ul><ul><li>3 Relier les représentations par des liens </li></ul><ul><li>4 Utiliser l’interface uniforme </li></ul>
    26. 26. Page  Architecture Orientée Ressource
    27. 27. 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
    28. 28. Page  Affichage Construction des écrans Traitements métiers Données persistantes Données de sessions Mainframe / Client passif
    29. 29. Page  Interface ODBC/JDBC/... Poste client Base de données Client-serveur / Client lourd
    30. 30. 3 tiers / Client léger Page  Interface HTTP Navigateur Base de données Serveur d'applications Interface ODBC/JDBC/...
    31. 31. ROA / Client riche Page  Interface de services Ressources Client riche Serveur d'applications Base de données Interface ODBC/JDBC/...
    32. 32. Identifiant, ressource, représentation Page  Architecture of the World Wide Web, Volume One W3C Recommendation 15 December 2004 http://www.w3.org/TR/webarch/
    33. 33. <ul><li>Cool URI don't change </li></ul><ul><ul><li>L'URI fait partie de l'interface publique </li></ul></ul><ul><li>URI are opaque </li></ul><ul><li>Utiliser des URI logiques plutôt que physiques: </li></ul><ul><ul><li>http://dng.org/symposium/2007/sessions.html </li></ul></ul><ul><ul><li>=> Couplage faible </li></ul></ul><ul><ul><li>=> Evolutivité </li></ul></ul><ul><ul><li>=> Lisibilité </li></ul></ul>Cool URI don't change Page 
    34. 34. REST Page 
    35. 35. 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
    36. 36. Page  Representational State Transfer <ul><li>REST est un style d'architecture </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>REST capture les principes fondamentaux qui font le succès du Web. </li></ul><ul><li>REST décrit les contraintes qui permettent au web d'être simple, performant, fiable, scalable et évolutif </li></ul>
    37. 37. Envoyer un message sur le réseau Page 
    38. 38. Page  Principes d'architecture généraux
    39. 39. 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
    40. 40. 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é
    41. 41. Le débat: SOAP vs REST Page 
    42. 42. 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
    43. 43. Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans d’HTTP seul HTTP vs SOAP Technologies
    44. 44. <ul><ul><li>Web Services = SOAP + WSDL + UDDI +WS-* </li></ul></ul><ul><ul><li>Où est le Web dans ces Web Services ? </li></ul></ul><ul><ul><li>- Mauvaise utilisation du protocole HTTP </li></ul></ul><ul><ul><li>- Pas d'URI </li></ul></ul><ul><ul><li>Il faut trouver un autre nom </li></ul></ul><ul><ul><li>Big Web Services vs Light Web Services </li></ul></ul><ul><ul><li>Un service web léger est un site web navigable par les machines </li></ul></ul>Page  Web Services ?
    45. 45. Page  WS-* est trop complexe Ce sont les « big vendors » qui ont inventé et poussent SOAP / WS-*
    46. 46. 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.
    47. 47. Page  SOAP WSDL UDDI WS-* HTTP URI XML Les arguments des partisans de SOAP HTTP vs SOAP Technologies
    48. 48. Page  Fonctionnalités avancées
    49. 49. 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.
    50. 50. REST-ROA / SOA Page  Style d'architecture REST SOA Architecture ROA
    51. 51. REST-ROA / SOA Page  <ul><li>REST/ROA </li></ul><ul><ul><li>Un travail théorique de référence (thèse de Fielding)‏ </li></ul></ul><ul><ul><li>Une architecture: celle définie par le W3C </li></ul></ul><ul><ul><li>Une implémentation: le Web </li></ul></ul><ul><ul><li>Des principes et des contraintes d'architectures bien définis </li></ul></ul><ul><ul><li>Approche bottom-up </li></ul></ul><ul><ul><li>Hérite de la culture du Web </li></ul></ul><ul><li>SOA </li></ul><ul><ul><li>Englobe le style d'architecture et les architectures </li></ul></ul><ul><ul><li>Pas de contraintes d'architectures ou de principe universellement reconnus </li></ul></ul><ul><ul><li>Approche bottom-up </li></ul></ul><ul><li>Hérite de la culture Entreprise et RPC/CORBA/DCOM </li></ul>
    52. 52. Ressources et Services Page  Ressources Services
    53. 53. 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é
    54. 54. <ul><li>Accéder à une donnée avec un service? </li></ul><ul><ul><li>getFacture(Identifiant)‏ </li></ul></ul><ul><ul><li>serialization/deserialization XML </li></ul></ul><ul><li>Accéder à un traitement avec une ressource? </li></ul><ul><ul><li>Une ressource est une abstraction on peut mapper un traitement sur une ressource. </li></ul></ul><ul><ul><li>Ce n'est pas toujours pertinent (service de conversion de température)‏ </li></ul></ul><ul><ul><li>En mappant un traitement sur une ressource on lui donne une URI (utile pour retrouver une commande)‏ </li></ul></ul><ul><ul><li>Il faut faire de l'URI design nouvelle compétence </li></ul></ul>Ressources et Services Page 
    55. 55. Ressources et Services Page  Traitements Données Back end Front end Services SOA SOAP/WS-* Ressources REST HTTP
    56. 56. Softwares + Services + Ressources Page  procédural Objet Service Service procédural Objet procédural procédural Objet Ressource
    57. 57. Page  <ul><ul><li>“ 25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a Service d'ici 2011” </li></ul></ul><ul><ul><li>Fin du débat propriétaire VS open source </li></ul></ul><ul><ul><li>Importance du lock-in par les données. </li></ul></ul><ul><ul><li>L'important est/sera la portabilité des données </li></ul></ul><ul><ul><ul><ul><li>Open Data </li></ul></ul></ul></ul>Softwares + Services + Ressources
    58. 58. <ul><li>Intéropérabilité (HTTP + XML) + Adressabilité (URI)‏ </li></ul><ul><ul><li>Surface de contact plus grande avec les applications </li></ul></ul><ul><ul><li>Favorise la sérendipité ( serenpidity ) </li></ul></ul><ul><ul><ul><li>«  L'art de faire une découverte intéressante en cherchant autre chose  » </li></ul></ul></ul><ul><ul><li>Donc l'innovation </li></ul></ul>Innovation Page 
    59. 59. Restafarians ? Page 
    60. 60. La bible Page 
    61. 61. Le nouveau testament Page 
    62. 62. Les apôtres <ul><li>Pete Lacey http://wanderingbarque.com/nonintersecting/ </li></ul><ul><li>Stefan Tilkov http://www.innoq.com/blog/st/ </li></ul><ul><li>Bill de Hora http://dehora.net/journal/ </li></ul><ul><li>Mark Baker http://www.markbaker.ca </li></ul><ul><li>Steve Vinoski http://steve.vinoski.net/blog/ </li></ul><ul><li>Stuart Charlton http://www.stucharlton.com </li></ul><ul><li>... </li></ul><ul><li>YOU ? </li></ul>Page 
    63. 63. Conclusion Page  <ul><li>4ième génération d'architecture </li></ul><ul><li>Softwares + Services + Ressources </li></ul><ul><li>Open Data </li></ul><ul><li>L'approche orienté ressources + interface uniforme est l’un des moteurs de l'innovation sur le Web </li></ul>
    64. 64. <ul><li>- IstockPhoto pour les photos </li></ul><ul><li>- Le projet Crystal pour les icônes </li></ul><ul><li>- Mes collègues d'Atos Origin pour leurs retours critiques </li></ul>Remerciements
    65. 65. Page  Annexes
    66. 66. <ul><li>HTTP ne garanti pas la livraison d'un message </li></ul><ul><li>Mais GET/PUT/DELETE sont idempotent </li></ul><ul><ul><li>On peut renouveler l'appel jusqu'à obtenir une réponse </li></ul></ul><ul><li>Problème avec POST </li></ul><ul><ul><li>Utiliser une « ressource factory » pour obtenir une url pointant vers une ressource « vide » </li></ul></ul><ul><ul><li>Utiliser PUT </li></ul></ul>Page  Comment gérer la fiabilité en HTTP

    ×