Conception d'un format/procotole : les 7 clés du succès
Par Adam Bosworth

Le , par Erwy, Rédacteur
par Adam Bosworth

Adam Bosworth a été vice président d'une division de Google jusqu'à récemment. Il a été très impliqué dans la conception et l'implémentation de nombreux standards comme par exemples ODBC, OLE DB ou XML. Il a aussi participé à l'élaboration de XML Schema qu'il considère comme un semi-succès (échec).
De toutes ces expériences ,réussite comme échec, il a fait récemment le point.

Sur son blog, il refait le point sur les 7 clés du succès de conception d'un standard en format/protocole:

  1. Garder le standard aussi simple et « stupide » que possible:
    les probabilités d'échec sont au moins le carré du degré de complexité de la norme mais aussi le carré de la taille du comité de rédaction de la norme.
  2. Les données échangées doivent être lisibles et faciles à comprendre:
    les standards sont adoptés par des ingénieurs fabriquant du code pour les implémenter. Ils ne peuvent le réaliser que s'ils peuvent facilement le comprendre (voir point 1) et facilement le tester. C'est pourquoi, au cours des 15 dernières années, les normes basées sur du texte comme HTTP, HTML, XML, et ainsi de suite ont gagné.
  3. Les standards fonctionnent mieux quand ils sont «*ciblés*»:
    Une partie du génie du web, c'est que Tim Berners-Lee a correctement séparé le protocole (HTTP) de ce que le navigateur devrait afficher (HTML). C'est un peu comme la séparation d'une enveloppe et de la lettre à l'intérieur, elle est fondamentale et nécessaire. Les normes qui incluent tous les niveaux ou les couches entassés en un ensemble ont tendance à échouer.
  4. Les standards devraient utiliser des encoding précis:
    ODBC a été précis sur les types de données.
  5. Toujours avoir une implémentation pratique effectivement utilisée dans le cadre de conception de la norme:
    Il est difficile de savoir si quelque chose fonctionne réellement ou peut être modifié dans un but pratique jusqu'à ce que vous ayez réellement à le faire.
  6. Faire passer en Hystérésis (définition ) face à l'imprévu:
    C'est quelque chose que les formats web font particulièrement bien. S'il y a quelque chose dans HTTP que le récepteur ne comprend pas, il l'ignore. Il ne bloque pas. S'il y a quelque chose en HTML que le navigateur ne comprend pas, il l'ignore. Il ne bloque pas.
  7. Faire une publication libre et publique sur le Web avec de nombreux exemples sur le site même:
    Les ingénieurs sont seulement des êtres humains. Ils apprennent par l'exemple et si le standard est conforme aux points ci-dessus, les exemples seront clairs et précis.


Source
Adam Bosworth’s Weblog

Lire aussi

La rubrique XML/XSL et SOAP (actu, forum, tutos) de Développez

Et vous ?

Que pensez-vous de cette analyse ? Certains points vous paraissent superflus ou au contraire cette liste vous paraît-elle incomplète ?
Voyez-vous des exemples qui confirment ou infirment cette analyse ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de souviron34 souviron34 - Expert éminent sénior https://www.developpez.com
le 06/11/2009 à 16:44
Citation Envoyé par GrandFather  Voir le message
Tu peux être plus explicite concernant ces ruptures technologiques ? Parce que les normes ISO, IEEE ou les standards RFC (pour la plupart) ou OASIS, pour ne prendre que ces exemples, ont jusqu'ici été plus un facteur de pérennité et de compatibilité ascendante dans l'industrie informatique qu'un facteur d'instabilité, il me semble...

les anciennes, c'est exact..

Pour les nouvelles, ben justement les trucs HTML ... tout le paquet de choses ajoutées ou modifiés ne sont pas accompagnées de "règles de bonne conduite" disant qu'il est fortement recommandé d'être tout de même compatible avec les versions antérieures...

Pour ISO, c'est un peu pareil en ce qui concerne les méthodologies...

Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Je rappelle que l'un des points mentionnés parmi les 7 est la simplicité et la lisibilité.. Quand on a besoin d'un cours pour comprendre un protocole, c'est qu'il n'est pas simple (d'autant plus que l'autre règle est qu'il soit lisible...)
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 06/11/2009 à 16:51
Citation Envoyé par souviron34  Voir le message
Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Tu peux aussi parler des protocoles réseaux : téléphonie mobile, sans fil, ...

Les normes se suivent et ne se ressemblent pas.
Avatar de GrandFather GrandFather - Expert éminent https://www.developpez.com
le 07/11/2009 à 1:48
Citation Envoyé par souviron34  Voir le message
Mais je parlais plus de trucs comme XML, ou plutôt pour ce que je connais GML, et les choses comme ça..

Pour XML, depuis 1998 on commence à les discerner les bons usages, ainsi que les anti-patterns d'ailleurs puisque rien n'est parfait en ce bas monde, mon bon monsieur... XML n'a pas été vraiment une rupture, puisqu'il est issu de SGML, tout comme HTML. Il estcependant bien plus simple que son ancêtre (comme quoi les normes ne sont pas forcément de plus en plus complexes), et d'un usage bien plus large.
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 09/11/2009 à 9:44
Citation Envoyé par GrandFather  Voir le message
Pour XML, depuis 1998 on commence à les discerner les bons usages, ainsi que les anti-patterns d'ailleurs puisque rien n'est parfait en ce bas monde, mon bon monsieur... XML n'a pas été vraiment une rupture, puisqu'il est issu de SGML, tout comme HTML. Il estcependant bien plus simple que son ancêtre (comme quoi les normes ne sont pas forcément de plus en plus complexes), et d'un usage bien plus large.

Mouais... entre SOAP/REST ou XML/JSON, je pense qu'on commence a voir les limites du mantra "XML est la solution pour tout".
Avatar de Erwy Erwy - Rédacteur https://www.developpez.com
le 09/11/2009 à 10:04
XML sont but c'est l'interroperabilité et aussi la réutilisation de données dans un but qui peut être différents de celui voulu à l'origine.
REST et JSON sont spécialisé dans une tache et une technologie.Tant qu'on n'a pas besoin de faire autre chose ils sont parfaits, si on en sort , au mieux c'est l'usine à gaz au pire, on oublie.

Si XML avait atteint ses "limites", on verrait moins de standards basés dessus ou au moins moins d'implémentation . C'est exactement l'inverse depuis des années.

cela fait plus de 6 ans que je pratique ce type de techno et depuis mes débuts tout les mois je lis que XML "a atteint ces limites", j'ai même lu vers 2005-2006 (voir plus ancien, c'est le travers des archives du web , quand on dit une annerie, cela reste longtemps visible...) des messages de gens sérieux et fortement diplomé annonçant que XML était condamné à une fin rapide.....

Ceux qui portent ce type de jugement ont un point communs.Leur spécialité n'est pas la donnée et son traitement, et il ne comprennent généralement pas que les informations qu'ils utilisent dans leur domaine particulier, ou il est toujours facile de spécialisé et optimisé un format de donnée, peut être tout aussi utile ailleurs, mais ou ce format si "spécialisé et optimisé" oppose une fin de non recevoir
Avatar de GrandFather GrandFather - Expert éminent https://www.developpez.com
le 09/11/2009 à 11:05
Citation Envoyé par pseudocode  Voir le message
Mouais... entre SOAP/REST ou XML/JSON, je pense qu'on commence a voir les limites du mantra "XML est la solution pour tout".

Tu ne m'aurais pas un peu lu en diagonale, par hasard ?

C'est exactement mon propos : il a fallu du temps pour discerner à partir de la norme les usages où XML apportait une réelle plus-value de ceux où il n'en apportait pas, voire était contre-productif. Le fait qu'il soit extrêmement répandu dix ans après tendrait à prouver que la première catégorie supplante de loin la seconde.

Au passage, REST n'a pas supplanté SOAP, loin de là. Il en est par contre une alternative intéressante pour les catégories de problèmes qui ne feraient qu'une utilisation minimaliste des possibilités de SOAP. A noter également que SOAP (HTTP & SMTP) est plus indépendant du protocole que REST (HTTP uniquement).

Pour XML et JSON, il est vrai que JSON a remplacé XML, et avec profit, pour ce qui était de faire de l'AJAX. Maintenant, si tu souhaite récupérer ton flux de données pour le traiter dans un autre contexte, il faut que l'autre plate-forme dispose de fonctions de lecture et de décodage JSON, et qu'elles soient compatibles avec le résultat qu'on en attend... ce que XML permet « nativement ».

Franchement, en terme d'interopérabilité XML a parfaitement rempli son contrat.
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 09/11/2009 à 14:18
Citation Envoyé par GrandFather  Voir le message
Pour XML et JSON, il est vrai que JSON a remplacé XML, et avec profit, pour ce qui était de faire de l'AJAX. Maintenant, si tu souhaite récupérer ton flux de données pour le traiter dans un autre contexte, il faut que l'autre plate-forme dispose de fonctions de lecture et de décodage JSON, et qu'elles soient compatibles avec le résultat qu'on en attend... ce que XML permet « nativement ».

Franchement, en terme d'interopérabilité XML a parfaitement rempli son contrat.

Hum... l'interop via SOAP n'est pas vraiment une réussite pour ma part.

Exemple de la semaine dernière : appeler un web-service tomcat/axis depuis dotNet. Impossible de retourner/lire un objet avec un attribut "tableau d'entiers" Après lecture des specs, il apparait qu'il y a plusieurs moyens pour encoder un tableau en SOAP. Et bien sur, Axis et dotNet n'ont pas pris le même.

Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...
Avatar de Erwy Erwy - Rédacteur https://www.developpez.com
le 09/11/2009 à 14:47
Citation Envoyé par pseudocode  Voir le message
Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...

Je n'ai trouvé que la recommandation pour soap 1.2
http://www.w3.org/TR/2001/WD-soap12-...011002/#arrays
Je n'ai pas particulièrement vu 2 façon de faire.Maintenant cette spec date de 2007, ce qui peut être récent en terme d'implémentation,est ce qu'il n'y aurait pas plutot un problème de version de SOAP et non de spécification ?

Ce genre de problème existe bien, je le connais dans XML Schema ou pour un cas particulier il existe deux méthodes exclusives pour comprendre la spec et donc la réaliser.
XML Schema est d'ailleurs un des contre-exemples repris dans l'article sur ce qui peut causer le (semi-)echec d'une spécification.
Avatar de GrandFather GrandFather - Expert éminent https://www.developpez.com
le 09/11/2009 à 14:52
Citation Envoyé par pseudocode  Voir le message
Pour ma part, le fautif c'est la spec : 2 moyens de faire la même chose, c'est un de trop. Ce qui est dénoncé dans le point #4 de la liste. Et pourtant c'est un standard. Va comprendre...

On peut aussi y voir une faiblesse de l'implémentation qui, en allégeant le travail du développeur de la charge d'avoir à tout définir via le WSDL et en automatisant le maximum de choses, lui impose un cadre plus rigide que ce que permet la norme. A décharge, WSDL ne doit pas être, comme les W3C XML Schémas, ce qu'il y a de plus facile à implémenter...
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 09/11/2009 à 15:11
Citation Envoyé par Erwy  Voir le message
Je n'ai trouvé que la recommandation pour soap 1.2
http://www.w3.org/TR/2001/WD-soap12-...011002/#arrays
Je n'ai pas particulièrement vu 2 façon de faire.Maintenant cette spec date de 2007, ce qui peut être récent en terme d'implémentation,est ce qu'il n'y aurait pas plutot un problème de version de SOAP et non de spécification ?

Auquel cas, si la version est aussi importante pour un format d'interop, la spec devrait forcer un check et imposer de générer une erreur "Incompatible SOAP version". Mais en fait, non. Le problème c'est que l'un des 2 (axiz ou dotnet) a créé un type complexe intermédiaire (ArrayOfInt) alors que l'autre utilise directement "SOAP-ENC:arrayType".

Enfin, pour quitter SOAP et en revenir a la discussion, les standards ne suivent pas forcément les règles. Un format devient "un standard" lorsqu'il est adopté massivement, que ce soit grâce a sa "beauté" ou parce que c'est le seul disponible pour répondre à la problématique. Exemple: Flash.
Avatar de thelvin thelvin - Modérateur https://www.developpez.com
le 13/11/2009 à 18:46
Hmm, je suis très d'accord avec pratiquement tout ce qui se dit dans son article et qui se résume dans ce post.

Mais

Citation Envoyé par Erwy  Voir le message
[*] Faire passer en Hystérésis (définition ) face à l'imprévu:

Surtout pas malheureux !

Enfin, disons plutôt, il ne faut pas le dire comme ça.

Souvent la récupération d'erreur est une bonne chose. En effet, de nombreux formats le prouvent, comme http, html, et, au fond, pas mal de formats xml en partie aussi.

Mais pas toujours.

Cette décision ne doit pas être systématique. Elle doit être le résultat d'une étude du risque d'accepter des données incorrectes parce qu'on n'a rejeté que ce qui avait l'air incorrect. Il n'est pas toujours possible de protéger un protocole de cela. Et si le protocole peut servir à l'échange d'à peu près n'importe quoi, accepter la partie mais pas le tout peut avoir des conséquences graves.

Il est très important de choisir le juste milieu entre bloquer sur toute invalidité et ignorer tout ce qu'on "comprend pas." Au pire rejeter systématiquement est un choix assez sécurisant, mais qui provoquera des lourdeurs dans le format et défavorisera son adoption (sauf si c'est justement ce qu'on attend de lui.)

Surtout pas le dire comme ça.

Le reste de l'article, je l'ai lu en diagonale, mais il me semble que j'abonde dans son sens.
Offres d'emploi IT
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil