We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
Aurelien:
tu peux expliquer comment HTTP est “aware of latency, …, and take into account issues of concurrency and partial failure”.
Ca serait pas en demandant a l’utilisateur de pousser le “submit” bouton jusqu’a ce ca marche? ou de retaper l’URL quand y-a un petit time-out? ou de payer un article 2 fois au cas ou en fait quand tu as pousse 2 fois sur le “submit” boutton, on t’a debit effectivement 2 fois.
HTTP c’est super.
Attention, en reprenant cette citation tu as tronqué l’essentiel: c’est le développeur qui doit être “aware” des problèmes liés au réseau pas juste la machine.
Pour que le développeur soit “aware” il peut soit
– Regarder les film de JCVD
– Utiliser des outils et un paradigme de programmation qui ne fasse pas abstraction du réseau
Un outil de choix, comme tu le fait remarquer, est bien sûr HTTP, le paradigme ce sont les ressources à la mode RESTful.
Ce texte de référence a 14 ans et pourtant l’industrie informatique a construit SOAP un protocole de communication pour faire du traitement distribué qui est indépendant de la couche transport, du réseau ! Quelle erreur.
Maintenant pour répondre à ta question oui HTTP permet et prévoit les cas d’utilisations que tu décrit notamment grâce au concept d’interface uniforme qui permet de spécialiser chacune des opérations.
=> En utilisant GET correctement on a gratuitement du cache, utile sur un réseau.
=> L’idempotence des opérations GET, PUT et DELETE permet effectivement de rejouer une requête jusqu’à obtenir le résultat voulu.
Reste (sans jeu de mot) le cas du POST, quand le développeur fait un POST il sait qu’il va aller modifier une ressource quelque part sur le réseau sur laquelle il n’a la main. Il sait qu’il doit faire attention aux problèmes d’accès concurrent ou de panne d’un élément du réseau… HTTP fournit là aussi des outils pour aider le développeur, les codes de status; Par exemple HTTP 412 Precondition failed qu’on peut utiliser pour signaler une collision, ou encore les codes 300 pour les redirections.
Un site web qui te débite deux fois parce que tu as clické deux fois sur le bouton submit est un site web codé avec les pieds.
Ouais, je vois, tu connais bien la lecon ca debite comme du saussisson,
HTTP fait une abstraction complete du reseau. C’est le reseau qui ne fait pas abstraction de HTTP. HTTP ne sais pas faire de la “concurrency” (tu as deja essayer d’avoir plein de sockets ouvertes qui essaient d’acceder a la meme resource dans le back-end…manifestement non), HTTP est un protocol incapable de livrer des message de maniere ordonnee, “reliable” (on est sur que le message a ete traité) ou “durable” (on est sur que le message est entre de bonnes bain et on n’a plus a s’en soucier).
Un developpeur va devoir reimplementer tous les patterns qui lui permettrait de gerer: latency, concurrency et partial failure a chaque fois car il ou elle n’a pas l’ombre d’un support adequat dans le protocole de communication.
Ca c’est sur “aware” ils ont vraiment interet a l’etre. Le but de la stack WS-* c’est precisement de faciliter la tache du developpeur pour gerer ces problemes tout en utilisant HTTP.
Construire des systemes distribues avec seulement HTTP, c’est comme marcher sur la tete.
On peut aussi dire que construire des systèmes distribués avec SOAP/WS-* c’est comme courir sans avoir appris à marcher.