Resource Oriented Architecture

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

Slide 2: Qui ? uré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  2

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

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

Slide 5: D’un Web de pages

Slide 6: A un web de Ressources

Slide 7: Mash-up

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

Slide 9: Crée une application RESTful

Slide 10: 1 Donner un identifiant unique à toutes les choses intéressantes ou Donner une URI à toutes les ressources 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/ Page  10

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

Slide 12: 2 Permettre plusieurs représentations GET http://dng.org/symposium/2008/sessions/day1 Accept : application/xml <sessions> Représentation <date>11/02/2008</date> <session id="1"> <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> Page  12

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

Slide 14: 3 Mettre des liens dans les représentations <sessions> <date>11/02/2008</date> <session id="1"> <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="5" ref="http://dng.org/symposium/2008/sessions/roa"> <time>16:00 - 17:00</time> <name>Resource Oriented Architecture (ROA)</name> <summary></summary> <speaker ref="http://dng.org/symposium/2008/speakers/aurelien"> Aurélien Pelletier</speaker> </session> Page  14

Slide 15: 4 Utiliser l'interface uniforme d'HTTP Page  15

Slide 16: GET 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 Page  16

Slide 17: 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 Page  17

Slide 18: 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 Page  18

Slide 19: 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  19

Slide 20: Calculatrice 4 opérations Approche services RPC Page  20

Slide 21: Calculatrice 4 opérations 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 Approche ressources REST Page  21

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

Slide 23: Calculatrice 4 opérations PUT /nombres/douze HTTP/1.1 Host: calc Requête <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 Réponse Page  23 <result>17</result>

Slide 24: 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 ="http://calc/nombres/resultUID">17</result> <calcul> Page  24

Slide 25: 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

Slide 26: Architecture Orientée Ressource Page  26

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

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

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

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

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

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

Slide 33: Cool URI don't change 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é Page  33

Slide 34: REST Page  34

Slide 35: 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  35

Slide 36: 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 Page  36

Slide 37: Envoyer un message sur le réseau Page  37

Slide 38: Principes d'architecture généraux Page  38

Slide 39: 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 Page  39

Slide 40: Interface uniforme L’interface uniforme (principe de généricité) + Simplicité + Evolutivité - Efficacité 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

Slide 41: Le débat: SOAP vs REST Page  41

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

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

Slide 44: 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  44

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

Slide 46: Interopérabilité 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  46

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

Slide 48: Fonctionnalités avancées SOAP/WS-* HTTP Protocole d'interaction SOAP HTTP Protocole de transport HTTP ou autre HTTP Description des interfaces WSDL WADL WS-Security Sécurité WS-Truts SSL WS-SecureConversation Basic/Digest Auth ReliableMessaging WS-Reliability Idempotence Transaction distribuée WS-AtomicTransaction Policy WS-Policy YAGNI Business process BPEL Page  48

Slide 49: 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. Page  49

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

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

Slide 52: Ressources et Services Ressources Services Page  52

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

Slide 54: Ressources et Services 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 Page  54

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

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

Slide 57: 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 Page  57

Slide 58: Innovation 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 Page  58

Slide 59: Restafarians ? Page  59

Slide 60: La bible Page  60

Slide 61: Le nouveau testament Page  61

Slide 62: 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  62

Slide 63: Conclusion  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 Page  63

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

Slide 65: Annexes Page  65

Slide 66: 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 Page  66