Le gap sémantique et l’architecture orientée message
Quand on en vient à l’interaction entre des machines informationnelles, revient toujours et systématiquement la question du “semantic gap”, qui est une façon condensée de dire :
“comment deux machines peuvent-elles se comprendre sans se connaître a priori ?”
Je précise “sans se connaître a priori” car si un même concepteur doit interfacer deux systèmes, alors le gap sémantique est de facto résolu par le concepteur lui même : maîtrisant les deux machines dialoguantes, il ne fait finalement que se parler à lui-même au travers d’une répartition des tâches qu’il planifie entre deux composants logiciels.
La quasi totalité des Systèmes d’Information (SI) des organisations ne sont pas sensibles au gap sématique parce qu’il s’agit de leur SI, qui est en fait un espace d’écriture, d’échange et de publication privé et non ouvert ou public. Si l’organisation a un problème d’interopérabilité entre ses différents silos applicatifs il ne tient qu’à elle à résoudre ce problème qui est son problème.
La question est tout autre quand on ne parle plus d’un Système d’Information privé mais d’une architecture applicative étendue et publique comme l’est le web. De fait, la question du gap sémantique est très présence dans le web des machines qui souffre en permanence de la comparaison avec le web comme interaction entre les machines et les hommes, ces derniers prenant en charge les questions sémantiques puisque c’est l’utilisateur qui décide de son cheminement dans les ressources. Le gap sémantique est ce qui empêche que les machines puissent elles-mêmes décider de leur cheminement dans les ressources du web..
Les architectures applicatives clients/serveurs offrent des normalisations (protocoles applicatifs) qui assurent une certaine généricité des échanges. Mais ces protocoles ne disent rien de la manière dont les composants peuvent prendre des décisions.
Si je connais exactement l’enchaînement des séquences (des questions-réponses entre le client et le serveur) je peux très bien automatiser cela, car le processus ne nécessite pas de prise de décisions côté client (ses requêtes sont connues d’avances, elles sont pro-grammées).
Mais alors, comment faire pour que le client acquiert une plus grande autonomie dans la manière dont il va faire ses requêtes au serveur ?
Il n’y a qu’une façon réellement sérieuse de pouvoir répondre à cette question et elle consiste tout d’abord à renvoyer dos-à-dos ceux qui parlent du web uniquement à partir de la distinction entre client et serveur. D’ailleurs, dans le métier des Sociétés de Services Informatique on prend bien soin de distinguer ceux qui travaillent “côté serveur” et ceux qui travaillent “côté client”.
Le cliché veut que les premiers sont les vrais ingénieurs, les vrais développeurs, ceux qui sont du côté de la maîtrise à la fois des données mais aussi des processus métiers, là où les seconds sont des charlots parfois un peu trop créatifs qui bidouillent le HTML & CSS et se réunissent une fois l’an à Paris Web pour tergiverser sur l’accessibilité et s’émouvoir qu’une feuille de style puissent avoir un décalage de deux pixels entre le rendu sur Chrome et sur celui de Firefox.
C’est une vision assez réductrice des choses qui pourtant est très opérante sur le marché – aussi bien côté prestataires que commanditaires – et qui reproduit la veille distinction entre “back” et “front”.
Cette distinction perd heureusement de son sens à vitesse grand V d’une part à mesure que du code s’exécute dans les navigateurs web, côté client donc (merci JavaScript) et d’autre part parce qu’il y a des développement aussi bien côté serveur que côté client comme le voit avec les APIs. En effet, le client ne peut plus se résumer à un terminal de publication ne faisant qu’afficher les réponses aux requêtes décidées par l’utilisateur.
Si l’on refuse cette partition de plus en plus artificielle entre le monde côté serveur et le monde côté client il faut donc acter qu’il y a du code qui s’exécute aussi bien côté client (et pas seulement pour faire de l’affichage) que côté serveur ; et que donc le seul moyen de traiter la question du gap sémantique est de rester dans l’entre-deux. Et qui y a il dans l’entre deux ? Des messages qui s’échangent.
La seule chose qu’un serveur voit d’un client ce sont les messages de requête qu’il reçoit de lui ; et la seule chose qu’un client voit d’un serveur ce sont les messages de réponse qu’il reçoit de lui.
La seule façon de progresser dans la résolution du gap sémantique, et de faire que le client puisse prendre quelques décisions avec une certaine autonomie, est de mettre l’emphase sur l’architecture applicative en tant qu’elle est une architecture de messagerie. Le travail de conception est différent quand on part du message lui-même ; de ce message qui assure l’interface entre le client et le serveur.
En matière de conception d’API, le fait de ne pas travailler selon une “architecture orientée message” a une conséquence quasi immédiate et systématique, comme le dit avec humour David Larlet : l’API n’est alors qu’un autre nom donné à service de conversion de format de donnée.
@ChristianFaure you mean APIs are just another label for converting a flow of data from one format to another? 😉
— David Larlet (@davidbgk) September 30, 2013
Il faudrait effectivement pouvoir concevoir une API web autrement que comme un convertisseur de format. Pour cela il faut commencer par oublier les logiques focalisée client ou serveur, c’est d’abord cela se mettre dans l’état d’esprit d’une architecture orientée message.
Enfin, en parlant d’Architecture Orienté Message, je précise qu’ il ne s’agit pas de remettre à la mode les Middleware Orientés Message d’il y a 15 ans, qui existent encore dans les Systèmes d’Information des organisations et qui ont ensuite produit les EAI/SOA/ESB qui ne répondent nullement aux enjeux du gap semantique dans des architectures applicatives distribuées, ouvertes et publiques.
C’est finalement une approche très “philosophical engineering”, comme dirait Tim Berners Lee, que de dire que les termes d’une relation (ici client-serveur) ne préexistent pas à leur relation, mais bien au contraire que c’est la relation elle-même qui produit les termes qu’elle relie ( les clients et les serveurs). C’est une approche qui est presque devenue un lieu commun dans le champ philosophique depuis plusieurs décennies et qui aurait tout intérêt à être prise très au sérieux dans l’ingénierie logicielle.
Bonsoir,
Je vous remercie pour cet article, et souhaitai rebondir sur le dernier paragraphe : « les termes d’une relation (ici client-serveur) ne préexistent pas à leur relation, mais bien au contraire que c’est la relation elle-même qui produit les termes qu’elle relie ( les clients et les serveurs). »
Il ne faut pas oublier que le client web (une page web avec du javascript) est téléchargé depuis un serveur, auquel on a accordé notre confiance).
Du coup, la confiance dans le serveur est un présupposé à la relation client/serveur aujourd’hui, ce qui n’était pas forcément le cas aujourd’hui.
On voit des traces de ce présupposé dans les règles de sécurité (security policies) des navigateurs d’aujourd’hui. Par exemple, une erreur à laquelle j’ai été confrontée aujourd’hui :
« Images loaded in a canvas from a different domain will raise this error as currently implemented by every browser. »
http://stackoverflow.com/questions/14329493/canvas-todataurl-causing-a-security-error
Difficile d’assurer la sécurité, si on autorise aux pages web d’accéder sans contraintes à un autre domaine (« www.christian-faure.net » par exemple) que celui avec lequel on converse.
Aussi, même Skype a besoin par moment de faire passer les flux par des serveurs de confiance, plutôt que de client skype à client skype. Pour passer des coupes-feu d’entreprise par exemple.
[Reply]
Merci pour les charlots 🙂
Vous posez des bonnes questions, mais il y a aussi énormément de gens qui ne sont pas que des « gens du front » au sens obsédés du pixel, mais qui discutent d’architecture logicielle, d’optimisation, etc.
Au final le plus gros du travail reste encore pensé pour les humains, et ce biais force à des choix. Le fameux « pixel-perfect » répond à un besoin exprimé très fortement par un client, par exemple. On est en train, doucement, d’éduquer les clients.
On est en train, aussi, de leur montrer que plutôt qu’une fantaisie qui fait wahou, un site tient mieux debout quand il est pensé accessible et pour les moteurs de recherche (et avec eux, de tous les crawlers qu’on pourra imaginer). On travaille en loucedé à son interopérabilité, sa « parse-ability » si vous me permettez ce néologisme. Autrement dit le client devient l’heureux propriétaire d’un site progressivement de plus en plus interopérable, voir commentaire de Karl.
Les tergiversations (si tant est que c’en soient) sur l’accessibilité ne sont presque que le moment où l’on se repose, le plus gros du travail est moins visible et difficilement médiatisable dans le cadre d’une conférence de 45 minutes. Et malheureusement le combat pour l’accessibilité est toujours aussi difficile, et importe davantage et plus immédiatement à de vrais humains que la négociation entre deux serveurs (même si sans ce dernier, le premier est vain, je suis tout à fait d’accord).
(J’espère ne pas avoir l’air agacé, je crois réellement que vous posez des bonnes questions mais quant à moi je devrai sans doute laisser décanter encore quelques années avant d’arriver à quelque chose de construit.)
[Reply]
Attaché à cela il y a de nombreux problèmes intéressants sur l’interopérabilité face à l’extensibilité et aux erreurs. Pour résumer que se passe-t-il lorsque justement l’une des deux parties ne comprends pas le message échangé. Quelle est la stratégie en place pour continuer à communiquer. Récupération d’erreurs (parseur HTML, HTTP), échec strict (pas bien formé en XML), etc.
Tout dépend si l’on est intéressé par l’intégrité totale du message, ou bien si on désire continuer avec des décisions non bloquantes comme par exemple en CSS, le choix d’ignorer les propriétés invalides mais de continuer le processing. En HTML (en fait le DOM), le choix la plupart du temps de récupérer en renormalisant le message.
Voir notamment.
http://www.w3.org/2001/tag/2003/webarch-20031111/tim#ext-version
[Reply]