C’est typiquement le genre d’article qui nécessite des corrections, des remarques et peut-être un débat. Alors n’hésitez pas.

Code et data

Pas de code sans données, car le but d’un code est de tourner et de produire des résultats et, pour ce faire, le code doit “manger” des données.

On peut voir le code dans sa forme la plus abstraite comme un algorithme dont le rôle serait de produire des preuves. Mais on peut aussi voir le code comme un algorithme qui ne fait pas simplement que valider et prouver mais également qui produit des changements d’états et des évènements qui, au sens littéral du terme, changent le monde.

On a ici un parallèle avec les “speech acts” de Searle et Austin dont Henry Story avait parlé dans son intervention au MeetUp Semantic Web de Février 2011.

Quiconque écrit un programme s’attend en effet à “changer le monde”, ne serait-ce que pour écrire “Hello World” sur un terminal. Changer le monde avec des algorithmes et du code, Microsoft, Google,  Facebook et d’autres l’on fait, et l’ensemble des développements en Open Source peut-être plus encore.

Pas de code sans données donc.  Or ces données sont stockées dans des supports de mémoires différents selon qu’elles sont en mémoire vive, sur un système de fichier, ou dans une base de donnée. Et chaque support de mémoire utilise un modèle de données qui n’est pas forcément le même. Ce qui nous ramène à la difficile collaboration entre les développeurs et les gestionnaires de base de données.

Si les développeurs et les administrateurs de base de données doivent collaborer, la réalité est parfois toute autre : les développeurs ne comprennent pas toujours le SQL et les RDB (bases de données relationnelles), et les DBA (administrateurs de base de données) ne voient les développeurs que comme de dangereux cowboys qui veulent massacrer l’intégrité de leur données (“mon précieux …”).

Le DBA

Le développeur

“Impedance mismatch”

La réalité est que les modèles de données utilisés dans les langages développement et dans les systèmes de stockage des données ne sont pas les mêmes : modèle objet et modèle tableau.

C’est ce qu’écrivait Yves-Marie Pondaven, que je citais également dans mon intervention au MeetUp Semantic Web de Décembre 2010, et dont je reproduis ci-après le schéma qu’il avait fait et dans lequel on voit que l’on passe son temps à basculer du modèle relationnel au modèle objet puis au modèle document et inversement.

Aussi disais-je que la plupart des CPUs de la planète sont occupés à faire des transformation et re-transformation entre des modèles de données différents. On peut donc au moins dire que cela a un impact en terme de performance mais aussi en terme environnemental non négligeable (de l’ordre de l’impact carbone sur la planète de toute l’industrie du transport aérien).

Cette question des différences entre les modèles de données n’est pas nouvelle, et elle a d’ailleurs fait l’objet d’une discussion intéressante entre Michel Volle et Laurent Bloch. Plus généralement, elle fait référence à “l’impedance mismatch” de George Copeland & David Maier 1984:

The problem with having two languages is“impedance mismatch ” One mismatch is conceptual – the data language and the programming languages might support widely different programming paradigms. [...]

The other mismatch is structural -thelanguages don’t support the same data types, [...]

Objets versus Tables

Avec les travaux d’Erik Meijer, de chez Microsoft Research, on peut essayer d’aller plus loin dans l’analyse de la situation, et je vais suivre à présent son argumentation, telle qu’il a exposé lors du WebWorkers Camp parisien du 16 avril 2011, et en faisant référence au papier qu’il a publié en Mars 2011 : A co-Relational Model of Data for Large Shared Data Banks.

L’objet-graphe et le stockage par clé/valeur (Key/Value)

Tout commence par une citation de Donald Knuth :

“I do consider assignment statements and pointer variables to be among computer science’s most valuable treasures.”

Pourquoi Meijer souligne-t-il ainsi l’importance des pointeurs pour ensuite assimiler l’équivalence entre le modèle objet et le stockage par clé-valeur ? :

“In the rest of this article we conveniently confuse the words object (graph) and key-value store.”

Deux choses ici :

1. D’une part, l’équivalence entre objet et graphe.
2. D’autre part, l’assimilation du modèle objet au mécanismes de stockage par clé-valeur.

Si l’objet est assimilé à un graphe c’est parce qu’une des caractéristiques de l’objet est d’avoir la structure d’un graphe, à savoir que les objets sont reliés entre eux par des relations qui, en l’occurence, sont dirigées (d’où la flèche) :

Référons-nous à wikipedia (article sur Object Graph) pour comprendre l’assimilation de l’objet-graphe à un mécanisme de stockage des données clé-valeur :

“An object graph is a directed graph, which might be cyclic. When stored in RAM, objects occupy different segments of the memory with their attributes and function table, while relationships are represented by pointers or a different type of global handler in higher-level languages.”

Un Objet est donc stocké en mémoire en encapsulant avec lui avec tout ce qui le caractérise (attributs et fonctions). Si cet objet-graphe est stocké dans différentes parties – ou segments – de la mémoire, les relations entre ces différentes parties, elles, sont représentés par des pointeurs (ou par des mécanismes plus généraux embarqués dans les langages de plus haut niveaux). Les pointeurs étant des types de données dont la valeur est l’adresse vers un autre objet stocké en mémoire.

Paradoxalement, le concept de pointeur rebute souvent les étudiants en informatique alors que l’architecture du web qu’ils utilisent tous les jours en est exactement la mise en oeuvre avec des ressources stockées qui sont accessibles via des relations qui sont représentées par des adresses, les URLs.

Voilà donc pour le côté “stockage en mémoire” des objets manipulés par les programmes. Basiquement, il s’agit d’un mode de stockage de type Key -Value qui représente une part importante de l’utilisation des bases NoSQL et sur lequel, je l’ai dit, repose l’architecture du web (de là à justifier le NoSQL comme mouvement surdéterminé par l’architecture du web, comme son milieu technologique d’émergence, il n’a qu’un pas).

Le stockage de données par tables

Passons maintenant au modèle utilisé par les bases de données relationnelles, représenté non plus par des objets mais par des tables.

Par rapport au modèle objet, la table va fractionner les données pour les lier d’une manière différente du modèle avec pointeur utilisé pour l’objet-graphe.

Alors que la manipulation des donnés en mémoire sous forme de graphe était au plus proche de leur mode de stockage physique en RAM, le modèle relationnel va “plaquer” un mode de stockage et de requêtage qui repose sur le modèle des tables. D’ailleurs, la première chose que l’on fait pour créer une base de données c’est d’écrire :

CREATE TABLE.

Ici il n’y a plus seulement une adresse pour une valeur (Key-Value), mais une valeur ( la primary key) dans plusieurs lignes. C’est la raison pour laquelle le modèle relationnel est aussi appelé Primary/Foreign Key.

Les contournements du modèle relationnel

Le modèle relationnel n’est pas évident dans sa compréhension et dans son utilisation. Meijer souligne tout cela par un raccourcit ironique :

1. Le concepteur de base de données enlève la structure originairement hiérarchique et objet pour lui appliquer un modèle normalisé par Tables ;
2. Le développeur doit ensuite retrouver la forme objet-graphe originale pour son développement. On a ainsi eu une vague d’ORM (Mapping Objet/Relationnel) qui, comme leur nom l’indique ajoutent une sur-couche objet au modèle relationnel afin que le programmeur puisse utiliser le stockage relationnel sans en connaître toutes les subtilités ;
3. Même du côté de la base de données, celui qui l’implémente doit rajouter une couche de stockage objet-graphe et Clé-Valeur en construisant un index de la base de données, en marge du modèle par Tables, pour pré-calculer des réponses à des requêtes.

A croire que, dès qu’on veut utiliser les bases de données relationnelles, il faille changer de modèle de données pour en revenir au modèle objet-graphe et le stockage par Clé-Valeur.

Sortir de l’aporie

Jusqu’ici rien de bien nouveau dans le “dysfonctionnement relatif” entre modèle Objet et modèle Relationnel, si ce n’est la montée en puissance des base NoSQL. Mais celles-ci n’ont pas vraiment de modèle de requêtage très élaboré (pas de modèle mathématique) : en effet il y a plutôt des recettes de requêtage dans le monde NoSQL.

Là où Meijer est intéressant, c’est dans la manière dont il formule le problème pour dépasser la vision d’opposition entre SQL et NoSQL. De la logique d’opposition on bascule alors dans une logique de composition, et les choses deviennent beaucoup plus claires.

Meijer, tel Ménon, fait son petit schéma (fig. 6 pour le modèle objet, et fig.7 pour le modèle en tables) et constate que :

• le modèle objet est défini par intension
• le modèle table est défini par extension.
• et surtout, on voit bien sur le schéma que le sens des flèches est inversé.

Je rappelle brièvement qu’une définition par intension décrit la liste des propriétés qui doivent être vérifiées pour qu’un élément appartienne à l’ensemble ainsi défini. Dans la définition par extension c’est la liste des éléments qui définit l’identité de l’ensemble :

“Toute classe d’éléments peut être définie en extension (en nommant ou en désignant chaque individu qui en fait partie) ou en intension, par une description (spécification d’un certain nombre de prédicats) qui définit la classe. L’intension s’identifie ainsi au concept. »

Par exemple, la classe des rois de France peut être désigné extensionnellement en donnant une liste de noms, ou intensionnellement par le concept « roi de France » (c’est-à-dire le prédicat, la propriété « être un roi de France »).” Intension et Extension, Wikipedia.

En informatique, toute donnée doit être porteuse d’une identité qui la distingue de toute autre donnée. Toute donnée, c’est à dire toute information disponible pour un calcul, doit disposer d’une identité. Et celle-ci passe par un référent (par exemple un identifiant), qui n’est autre qu’une métadonnée (Cf. Sur les métadonnées).

Il se trouve qu’avec le modèle objet-graphe, la métadonnée qui sert de référent pour l’identité de l’objet n’est pas une valeur mais l’adresse d’une valeur (le pointeur). Alors qu’avec le modèle en Tables, la métadonnée est une valeur (c’est la clé primaire).

La métadonnée qui sert de référent peut donc être définie par intension ou part extension :

• par intension, on a une clé qui est une adresse
• par extension, on a une valeur (clé primaire) qui est présente dans toutes les lignes des tables qui constituent l’identité de l’objet.

On comprend aisément la forte contrainte d’intégrité requise pour les bases de données relationnelles : une modification doit se déployer sur l’ensemble du système, de manière extensive, pour en garantir l’intégrité. Avantage à la maîtrise des données mais difficultés à passer à l’échelle du web.

Mais avec son petit schéma, Meijer, remarque que le modèle Objet et le modèle Table sont fort similaires : ce sont des graphes orientés, mais avec une orientation inverse :

Ne manque plus qu’à Erik Meijer de chercher “Mathematics arrow reverse” dans Google pour tomber sur la page Wikipedia de la théorie mathématique des catégories.

Théorie mathématique des catégories et le concept de dualité : “NoSQL is CoSQL”

De la théorie mathématique des catégories, Meijer retient le concept de dualité, ou catégorie duale :

À partir d’une catégorie opposée ou duale, en prenant les mêmes objets, mais en inversant le sens des flèches.

Plus précisément :

Il est clair que la catégorie duale de la catégorie duale est la catégorie de départ :

Cette dualisation extrêmement simple permet de symétriser la plupart des énoncés, ce qui peut être douloureux pour les débutants…

Ce “détour” par les mathématiques permet finalement à Meijer d’affirmer que :

• SQL et NoSQL ne sont pas incommensurables et incompatibles ;
• NoSQL s’appuie en fait sur un modèle de donnée qui reléve d’une catégorie duale où l’on a les mêmes objets mais en inversant le sens des flèches ;
• Donc NoSQL est en fait CoSQL ;
• A partir de là, on peut fonder les modes de requêtes NoSQL sur une théorie mathématique, comme s’était le cas pour SQL, ce qui permettra non seulement de standardiser les requêtes pour différentes bases NoSQL mais aussi de fonctionner pour les bases SQL.

Le rôle d’une interface est précisément de faire cohabiter des modèles différents, qui ne sont certes pas opposé et incompatibles sans quoi l’existence même d’interface ne saurait être possible.

Avec son langage de requêtage “universel” LINK, Meijer ne fait rien d’autre que d’avoir trouvé, via le recours aux théories mathématiques, une interface entre des modèles qui étaient présentés comme apparemment opposés. L’interface est à ce tire une composition.

Bien qu’étant universel sur le papier, LINK reste toutefois implémenté dans le monde .NET. Il faudrait donc une implémentation de cette démarche pour chaque langage pour parler vraiment d’un langage de requête universel.

Langage fonctionnels purs et monades

On connaît l’implication de Meijer dans la valorisation, la promotion des langages fonctionnels et notamment de Haskell (je vous renvoie à mon article Apprendre Haskell dans lequel je donnais les liens vers les tutoriels video de Meijer sur Haskell).

En fait, l’approche qu’il a implémenté avec LINK lui a été soufflé par les monades en Haskell. Pourquoi celà ?

Rendre compatible ce qui est incompatible est précisément le rôle des monades en Haskell. Puisque le langage est pur et fonctionnel (aucun effet de bord et immutabilité) il ne peut interagir avec le monde et le changer, il faut définir un lieu d’où les effets de bord (comme l’impression sur un terminal) seront quand même possibles.

Les effets de bord sont souvent dûs à des erreurs du point de vue des Types des données manipulés. Par exemple la fonction qui affiche l’heure n’est pas pure car à chaque fois qu’on demande la valeur, la fonction produit un résultat différent (l’heure tourne). Donc, un travail sur le Type System peut contourner la difficulté en considérant que la fonction ne revoie pas un INT mais un CHAR : on a contourné l’effet de bord en maîtrisant la définition par intension de la fonction dans la configuration des types.

Pour bien comprendre l’intérêt de cette question, on peut y retrouver un usage dans les architectures RESTful. Ainsi « Idempotence » en REST signifie « Pureté » en langage fonctionnel : la valeur d’une fonction ne change pas dans le temps (pas d’effet de bord). Par où l’on voit que le style d’architecture REST est un style qui s’appuie sur une architecture fonctionnelle pure par défaut : POST n’est pas une fonction idempotente (pure) car elle va modifier l’état du système.

Mais toute approche fonctionnelle pure doit composer avec le non-pur. Les programmes sont faits pour changer les états de systèmes et pour changer le monde. Les monades sont faîtes pour effectuer cette composition en créant des Types qui vont décrire ces effets de bord (IO, Exception, Animation, Collection). Les exceptions sont intégrées et gérées par le système qui conserve ainsi sa pureté grâce à son Type System (il n’y a pas que Haskell qui utilise cette approche par monades, Java aussi avec “throws Exceptions”).

Les monades transforment ce qui est mutable en quelque chose d’immutable (mutable et immutable étant les termes informatiques anglais utilisés).

En fait, je me demande si la modification que l’on fait avec les monades ne consisterait pas à définir de nouveaux Types non plus par intension mais par extension.

SQL et CoSQL à la lumière du concept de métastabilité.

Meijer rapproche l’articulation, qui est composition, entre SQL et NoSQL à celle du Ying et du Yang chinois, l’un désignant l’ouvert et l’autre le fermé. Puis il expose la dualité, au sens mathématique du terme, entre SQL et CoSQL, entre le fermé et l’ouvert :

On reconnaît dans cette distinction celle que j’avais essayé de faire entre technologies de gestion et technologies relationnelles, c’est à dire entre stabilité et métastabilité (Cf. Les technologies relationnelles dans les systèmes d’information et Métastabilité et archtitectures logicielles )

Le sens des flèches : des flèches du web au PageRank de l’index de Google.

Ouverture et métastabilité du web.

J’ai déjà rappelé l’anecdote à propos de Tim Berners Lee qui n’avait pas trouvé d’investisseur lors du Symposium sur les systèmes hypertextes en venant présenter son invention : le web.
Ceux qui pensaient en matière de technologies de gestion et de système clos et stable ne comprenaient pas l’intérêt d’un système métastable comme le web qui ne garantissait pas l’intégrité du système. Par exemple on peut faire des liens vers des ressources qui n’existent pas et provoquer une erreur. Seulement voilà, cet effet de bord est prévu dans le web, c’est précisément l’erreur 404 que connaît et intègre le système (utilisation du principe de la monade) et qui fait qu’un lien brisé n’a jamais empêché le web de fonctionner.

Google : à rebrousse-poils du web

Le projet backrub, qui fut l’ancêtre de Google et du PageRank, prenait le web à rebrousse-poil en se proposant d’identifier les pages HMTL qui lient une page donnée (Cf. L’idée qui fonda Google). C’est prendre le web à rebrousse-poil car les liens HTML sont reconstitués à l’envers : dans un cas la page HTML est le “parent” qui contient les liens vers les pages “enfants”, dans l’autre c’est les pages “enfants” qui lient vers la page “parent” pour lui donner un poids (un ranking).

A ce titre, on peut dire que le modèle d’affaire de Google s’est constitué mathématiquement comme une dualité du web, selon la théorie des catégories : Google = Co(Web).

*

Il serait intéressant de rejouer ce raisonnement en y intégrant ce qu’écarte Meijer, à savoir les bases NoSQL qui ne sont pas sur le modèle document clé-valeur mais sous une forme d’un graphe typé. C’est à dire en prenant en compte les éléments de la présentation (slides) An Overview of Data Management Paradigms: Relational, Document, and Graph, de Marko Rodriguez.

Related posts:

1. Sens et enjeux des RIA Je suis donc intervenu au RIA 2008 d’Adobe en insistant...
2. Prendre soin des données Sur le blog d’Atos Origin je reviens sur les enjeux...
3. Les enjeux de la grammatisation des relations (Les illustrations sont de Pavel.K, dessinateur, caricaturiste et illustrateur, que...

L’emploi de ces deux synonymes que sont « transfert » et « transport » a attiré mon attention après avoir constaté que, même si parfois les deux termes sont utilisés de manière quasi interchangeable (« transfert ou transport »), il y avait aussi des cas d’usages dans lesquels prédominait l’utilisation d’un des termes plutôt que de l’autre.

Qu’en est-il donc ?

Les cas d’usages de « Transport » :

• Il semble y avoir prédominance du déplacement physique et matériel ;
• La logistique s’occupe de transport ;
• Déplacement entre deux lieux (dimension topologique) ;

Les cas d’usages de « Transfert » :

• Implique la notion de propriété, il y a l’idée de transfert de droit sur ce qui est potentiellement transporté.
• Le Littré dit ainsi que transfert est un  » terme de finance et de commerce. Acte par lequel on déclare transporter à un autre la propriété d’une rente sur l’État, d’une action, d’une marchandise en entrepôt. »
• Avec le transfert, on passe d’une sphère (d’influence, de pouvoir, de droit) à une autre, cela peut s’accompagner d’un transport (ie. physique), mais pas nécessairement.
  

Dans l’informatique et technologies en réseau, ces deux termes sont bien sûr très utilisés. Pourtant, je n’ai pas réussi à trouver, que ce soit à l’IETF ou au W3C, une définition explicite qui distinguerait les deux termes. Il sont parfois utilisés de manière équivalente mais, la plupart du temps, et selon le sujet évoqué, on constate que c’est un des termes qui prédomine. C’est donc qu’il y a à minima une distinction implicite.

Au niveau de la couche des protocoles applicatifs, on constate un primat du transfert sur le transport, on y parle exclusivement de transfert :

• Simple Mail Tranfer Protocol
• File Transfer Protocol
• Hypertext Transfert Protocol

Le terme de transport, quant à lui, n’est présent que sur la couche qui porte son nom, par exemple au niveau TCP/UDP :

Cette distinction d’usage, même s’il elle n’est jamais thématisée en tant que telle, nous conduirait à affirmer que là où les protocoles de transports transportent des données, les protocoles applicatifs transfèrent des représentations.

Ainsi, c’est parce qu’il y a une sémantique applicative qui est transférée que l’on parlera de transfert. Il apparaît alors que c’est le niveau de sémantique qui nous force à utiliser transfert plutôt que transport. C’est un transfert parce que il y a du sens, celui d’un langage applicatif avec des représentations spéficiques associées (des types de fichiers et de documents, mais aussi des actions sur ces représentations).

Je dis un « niveau » de sémantique car il y a toujours un langage, une sémantique, dans chaque couche, puisqu’on parle de protocole. Mais les protocoles de transport ne « discutent pas » avec le contenu qu’ils transfèrent ; le dialogue avec le contenu commence au niveau du protocole applicatif. Dans le transport, il est juste question d’émettre et de recevoir (SEND et RECEIVE), dans le transfert on écrit, on lit, on modifie, on ajoute : il y a une richesse des actions plus importante que dans un protocole de transport (sans dire pour autant que les protocoles de transport soient « simples »).

C’est le modèle en couche qui permet d’articuler le transfert et le transport : le protocole de niveau applicatif travaille sans avoir à gérer le transport des données. Du coup, on a bien toujours du transport là ou il y a du transfert : pas de transfert sans transport (sauf peut-être lorsque l’on fait appel à des données en cache).

Il se trouve que la psychanalyse utilise également le terme de transfert. On peut même dire que la psychanalyse se constitue autour de la question du transfert pour en faire la cheville ouvrière de l’analyse (ie. le transfert n’est pas simplement un obstacle à l’analyse, il doit lui-même faire l’objet d’une analyse pour constituer le discours psychanalytique).

Or ce sont des représentations qui sont transférées par l’analysé vers l’analysant. Et le transfert est également qualifié de projection : c’est l’analysé qui projette sur l’analysant des représentations.

En ce sens, on est frappé de voir à quel point le style d’architecture du web peut avoir de fortes similarités avec la théorie psychanalytique.

Related posts:

1. REST en image On a beau dire, parler de « Representational State Transfert » reste...
2. Le propre du transfert et le tranfert du propre (infrastructure studies) Transport et Transfert Parler d’infrastructure du numérique c’est toujours prendre...
3. La culpabilité du lecteur La lecture, en tant qu’activité, est toujours un peu suspecte....

On a beau dire, parler de « Representational State Transfert » reste souvent un terme auquel il est difficile d’associer une représentation imagée.

Pourquoi parle-t-on d’état ? De représentation ? Et de transfert ?

Cette image peut aider :

Related posts:

1. Re-designer le web : « back to http » Le web est une architecture de service. Pourtant, nous continuons...
2. Pour aider les indécis Pour aider les indécis, voici quelques raccourcis sur le choix...
3. Transfert ou transport ? L’emploi de ces deux synonymes que sont « transfert » et « transport »...

S’il y a un des mérites qu’il faut reconnaitre à la mode des architecture RESTful c’est bien celui d’avoir rappelé cette évidence : HTTP est un protocole applicatif, et donc que le web est une application.

Et à qui me demande aujourd’hui « qu’est ce que REST ? », je réponds simplement que c’est d’abord un principe d’architecture dans lequel les données et les informations ont des adresses (URI), ce qui est déjà énorme quand on doit traiter des problématiques d’accès à l’information et d’interopérabilité entre des systèmes d »informations. On peut donc faire beaucoup de choses dans un système d’information en considérant HTTP comme un véritable protocole applicatif, et pas seulement comme un protocole de transport.

Dans une architecture RESTful, la plupart des échanges via les APIs se font en utilisant des messages XML. On peut donc construire des Architectures RESTful pourvu que des APIs soient RESTful, c’est à dire qu’elles respectent un certain nombre de principes. On peut même enrichir la démarche en s’appuyant à la fois sur un vocabulaires XML, c’est que l’on fait en utilisant le vocabulaire XML ATOM, et en utilisant un protocole applicatif qui s’appuie sur – et respecte – HTTP, c’est ce que fait le protocole de publication Atom (ATOMPUB). Ainsi, au dessus de HTTP/XML on peut utilsier ATOMPUB/ATOM, tout en respectant les principes REST.

ATOMPUB permet de :

• constituer des collections : c’est à dire de constituer un ensemble de ressources, qui peuvent ensuite être récupérées en entier ou en partie ;
• offrir des services : pour découvrir et décrire des collections ;
• éditer : pour créer, modifier et supprimer des ressources.

De fait, ATOM est largement connu en tant que vocabulaire XML, puisque c’est celui qui est utilisé pour restituer les publications des blogs sous forme de fils ( feeds) auxquels on peut s’abonner.

Ce qu’apporte le protocole ATOMPUB, c’est une certaine façon de considérer – voire de reconsidérer – les stratégies d’intégration et d’inter-opérabilité au sein d’un système d’information. En l’occurrence, la stratégie repose sur un protocole universel de cataloguage temporel des ressources du système d’information, puisque le vocabulaire ATOM  permet de proposer des agrégations de ressources associées à des métadonnées dont une est le timestamp, une étiquette temporelle. Cette dernière autorisant une vision de l’ensemble des ressources de l’entreprise selon leur date de mise à jour et en fonction de qui a fait cette mise-à-jour. Je me permets de souligner le terme de cataloguage, car cela induit mécaniquement une vision documentaire du système d’information.
Ce que je suis en train de décrire, n’est rien d’autre que la panacée pour un moteur de recherche qui doit pouvoir collecter aisément des ressources structurées selon une vision informationnelle et documentaire des données du système d’information, et ceci au moins à triple titre :

• D’abord parce que les ressources sont exposées, elles ont une URI ;
• Ensuite parce que les APIs étant RESTFul elles doivent respecter le principe « d’hypermedia en tant que moteur de l’état des applications » qui facilite le travail du crawler du moteur de recherche ;
• Enfin parce que les métadonnées de collection et d’étiquette temporelle permettent à la fois de faciliter l’indexation incrémentale des ressources ainsi que la restitution structurée des réponses.

Dans la configuration ou les applications offrent des APIs ATOMPUB, chacun comprendra que la stratégie de moteur de recherche dans le système d’information prend une toute autre dimension.

Avec la mise en place d’APIs ATOMPUB RESTful, il s’agit ni plus ni moins que de proposer un fil de news universel du système d’information qui peut donc être utilisé pour la consultation ( notamment via le moteur de recherche ou via des lecteurs de flux ATOM), mais également pour l’écriture et la modification des ressources (et c’est là que les vertus d’intégration et d’interopérabilité d’ATOMPUB s’expriment).

Pour la partie implémentation technique on peut utiliser des framework comme Snaplogic , Twinsoft (pour les mainframe), Kapov, etc. Voire même utiliser un serveur ATOM grâce à AtomServer, qui utilise Abdera, le projet Apache d’implémentation du protocole AtomPub.

Pour ceux qui se disent « mais cela ressemble à WebDav, non ?  » je reprends les propos de Tim Bray qui précise que :

AtomPub is different from DAV in two key respects:

• The client doesn’t control where things go, the server does;
• It is allowed and expected that an AtomPub server will look at the incoming information and change it (generate ID, timestamps, sanitize HTML, etc.

Maintenant, si vous vous posez la question de savoir quand est-il intéressant de mettre en place une architecture ATOMPUB, je pense qu’il faut simplement regarder du côté du vocabulaire XML qu’est ATOM : si les données manipulées ont des titres, des auteurs, des localisations et des dates de mise à jour, alors vous avez votre réponse.

Related posts:

1. POWDER : Protocol for Web Description Resources Un nouveau groupe de travail vient de se créer au...
2. RESTful Web Services RESTful Web Services est peut-être l’ouvrage informatique de l’année. Je...
3. DataWare et MetaDataWare Nous sommes en train de vivre une quatrième révolution dans...

Dans son Post-scriptum sur les sociétés de contrôle (1990), Deleuze commence par rappeler le travail fait par Foucault qui a décrit l’avènement des sociétés de disciplinaires des 18° et 19° siècles, qui atteignent leur apogée au 20° siècle :

Elles [les sociétés disciplinaires] procèdent à l’organisation des grands milieux d’enfermement. L’individu ne cesse de passer d’un milieu clos à un autre, chacun ayant ses lois : d’abord la famille, puis l’école (« tu n’es plus dans ta famille »), puis la caserne (« tu n’es plus à l’école »), puis l’usine, de temps en temps l’hôpital, éventuellement la prison qui est le milieu d’enfermement par excellence.

Cette logique est à présent arrivée à terme et vit une importante période de crise:

Nous sommes dans une crise généralisée de tous les milieux d’enfermement, prison, hôpital, usine, école, famille. La famille est un « intérieur », en crise comme tout autre intérieur, scolaire, professionnel, etc. Les ministres compétents n’ont cessé d’annoncer des réformes supposées nécessaires. Réformer l’école, réformer l’industrie, l’hôpital, l’armée, la prison ; mais chacun sait que ces institutions sont finies, à plus ou moins longue échéance. Il s’agit seulement de gérer leur agonie et d’occuper les gens, jusqu’à l’installation de nouvelles forces qui frappent à la porte.

Ce qui frappe à la porte, c’est l’avènement des sociétés de contrôle :

Ce sont les sociétés de contrôle qui sont en train de remplacer les sociétés disciplinaires. « Contrôle », c’est le nom que Burroughs propose pour désigner le nouveau monstre, et que Foucault reconnaît comme notre proche avenir.

Le contrôle dont parle Deleuze n’est pas tant le fait d’une logique de la « manipulation » que d’une logique de « modulation ». Celle-ci passe par le protocole d’un réseau. Or, sur le réseau, comment se redéfinit la souveraineté ? Si le réseau est l’instrument d’un contrôle, comment s’exerce-t-il et par qui, maintenant que les frontières au sein des institutions des sociétés disciplinaires se délabrent et deviennent poreuses ?

On pourrait ici rappeler le titre du livre de Jeremy Rifkin sur l‘Âge de l’accès, car la souveraineté sur le réseau passe en partie par le contrôle de l’accès aux informations (en l’occurrence numériques). On peut être dans le réseau sans pour autant jouir de toutes les modalités d’accès et de navigation : il faut des passes, des logins et des passwords. Il faut s’identifier et être identifié pour qu’une topologie du réseau s’instancie pour nous, pour qu’une connexion s’établisse et qu’une porte s’ouvre.

Parlant de réseaux, il faut différencier certaines typologies de réseaux, et donc de protocoles. Une des spécificités du protocole web est sa topologie de milieu associé qui fait de lui le réseau sur lequel les logiques dissociées – qui continuent à exercer une forme de souveraineté sur des réseaux de distribution dissociés – sont inopérantes.

Cette longue introduction, et je m’en excuse, n’était là que pour tenter d’expliciter les motivations qui peuvent – inconsciemment ou non – pousser une entreprise à faire certains choix engageant en matière d’architecture de son système d’information. Par exemple en choisissant de faire un projet SOA (Service Oriented Archtitecture) en privilégiant une archtiecture technique s’appuyant sur SOAP et les Web Services plutôt que sur un style d’archtiecture REST.

Bien souvent le choix se portera sur SOAP si l’entreprise veut faire de son projet la (re)conquête d’une souveraineté : mettre au pas une organisation éclatée avec des processus différents, dans différentes branches ou différents pays. L’intérêt de l’architecture SOAP étant qu’elle propose une architecture distribuée tout en maintenant des règles strictes et centralisées d’accès et de diffusion des informations.

Dans le cas de SOAP on utilisera le protocole HTTP uniquement comme protocole de transport, c’est à dire que l’ensemble des méthodes et des informations seront placées dans des enveloppes remises au « facteur HTTP ». On se refuse donc à exploiter HTTP en tant que protocole applicatif (avec son interface uniforme), ce qu’il est pourtant, et qui est précisément ce sur quoi met l’emphase le style REST.

Que SOAP ne marche pas techniquement, qu’il soit une aberration architecturale puisqu’il utilise le protocole HTTP pour distribuer ses objets en traitant une ressource distante sur le réseau comme une ressource locale, bref tout les arguments techniques (et financiers) ne pèseront pas dans la balance. Le style REST ne sera pas retenu car il ouvre la porte à la totalité de la logique du protocole applicatif HTTP, c’est à dire à la logique d’un milieu associé dans lequel la gouvernance induit de penser à nouveau frais la question d’une souveraineté du système d’information. Celle-ci passera nécessairement par une politique basée sur la participation qui, de facto, impose que l’on croit en la possibilité d’une intelligence collective au sein de l’entreprise.

Maîtriser l’accès et la sécurité (en tout cas le croire), forcer des usages et imposer des pratiques sont infine les arguments explicites ou implicites qui persuadent les décideurs, et ce au moins autant que la viabilité technologique et la pertinence des solutions qu’ils doivent implémenter. Le web, peu d’entreprises en veulent vraiment derrière leur firewalls : on veut bien « webiser » des écrans d’applications, utiliser HTTP mais uniquement comme protocole de transport et se donner l’illusion que l’on fait du web parce que l’on a des « Web Services », mais accepter le web, le vrai, cela impliquerait de revoir ses conceptions de la souveraineté ainsi que la force avec laquelle on croit aux mots que l’on prononce lorsque l’on dit que « les salariés sont la première richesse de l’entreprise ».

Related posts:

1. Il faut plus qu’un homme et une femme pour faire un enfant La psychanalyse freudienne porte en elle une certaine vision dans...
2. Réponse à une objection sur « la prolétarisation dans les sociétés informatiques » Didier Girard, sur Application Servers , fait une remarque intéressante...
3. L’implicite et l’explicite dans les réseaux sociaux On peut dégager deux tendances dans la constitution des réseaux...

Dans tout projet d’intégration d’entreprise visant à agréger des services provenant de différents silos applicatifs, le serveur d’application centralisé semble être une évidence, et l’on parle alors de Portail d’Entreprise.

On écoutera patiemment les arguments des éditeurs de telles solutions ainsi que ceux des DSI qui vantent les qualités du portail d’entreprise comme point d’entrée centralisé (maîtrisé, personnalisable, sécurisé, etc.) pour l’ensemble d’un porte-feuille applicatif.

Allons donc !

• Un point d’accès centralisé ? Pas besoin, j’ai des bookmarks dans n’importe quel navigateur qui me permettent d’accéder aux applications (web ou « webisées ») avec lesquelles je travaille.
• Plusieurs écrans d’application en même temps ? A quoi bon puisque de toute manière je peux ouvrir une nouvelle fenêtre de navigateur ou un nouvel onglet pour avoir plusieurs interfaces d’applications.
• Un seul point d’authentification ? Un Active Directory ou n’importe quel LDAP fait cela tout aussi bien.
• Le portail offre des vues personnalisées ? Mais qui se sert de çà et qui en a besoin ?
• Une intégration applicative de haut niveau dans une seule page ? Mais qui *travaille* dans un portail ! Une simple page web personnalisée avec des widgets me donnera un bon petit tableau de bord personnalisé pour gérer mon activité, avant de basculer sur de pleines pages si nécessaire.

Un grand portail d’infrastructure d’entreprise n’a aujourd’hui plus aucun intérêt (s’il en a jamais eu) si les services applicatifs qu’il centralise sont des services web  : la mise en place de flux RSS et ATOM, plus quelques widgets ont beaucoup plus de valeur que ces projets de centralisation de l’accès à l’information et aux applications.

Ici avec le portail, mais comme avec l’ensemble des démarches d’intégration (SOA, MDM, ESB), il faut se poser la question : mais pourquoi vouloir tout centraliser ? Dans les démarches d’architecture des SI en entreprise, trop souvent le choix de centraliser l’architecture est un axiome, donc un a priori, rarement la conséquence d’un choix raisonné, d’une conception.

Je comprend que les grand éditeurs poussent l’idée de centralisation car plus le Système d’information devient centralisé, plus le pactole à ramasser est important (« bingo ! Untel a pris mon ESB, tout son SI repose sur mon produit »). Mais pour les DSI, et derrière eux les utilisateurs du SI, cela n’a aucun sens.

Related posts:

1. APIE : Agence Pour l’Incurie de l’État Créée en 2007, juste après la publication du rapport « Lévy-Jouyet »(PDF)...

Manue vient de publier quelques bons billets suite à sa participation à la 7ième conférence internationale sur le web sémantique (ISWC 2008).

Dans un de ces billets, intitulé ISWC 2008 (3) – être visible sur le Web : linked data, elle rappelle une règle de base pour publier ses données en RDF sur Linked Data :

Une consigne de base : mettre le plus possible de liens (je veux dire, d’URIs déréférençables) dans les triples, pour faciliter la navigation dans le Web of data.

Je pense que l’expression « URI déréférençables » est loin d’être évidente pour tout le monde. Qui plus est, derrière ses faux airs, le verbe déréférencer fait immanquablement penser à autre chose : notamment à l’action de supprimer une référence, ou de ne plus référencer, ce qu’il ne signifie pas du tout dans ce contexte.

Alors, avant que nos bibliothécaires ne se méprennent et commencent à enlever les références de leur catalogue pour faire du web sémantique, une petite clarification s’impose.

Comme le suggère Manue, la façon la plus courante de comprendre une URI déréférençable c’est de l’assimiler à un lien hypertexte. Ce n’est pas faux ; mais alors, pourquoi tout çà pour dire çà ?

Le terrain est miné par de sourdes polémiques (notamment entre HTTP et RDF) que je tenterai de masquer en m’en tenant à une présentation consensuelle.

En effet, l’expression de « deferencing an URI » n’est pas simple, elle est même au coeur d’une vive discussion lors des travaux préparatoire du Technical Architecture Group (TAG) du W3C pour la recommandation sur l’archtitecture du world wide web. Cette discussion (issue en anglais) a perduré pendant cinq années, de 2002 à 2007. Elle est référencé sous l’appellation : httpRange-14: What is the range of the HTTP dereference function? Elle a été soulevé par Tim Berners Lee dans un message de la mailing-list du TAG le 19 Mars 2002.

Les URIs sont utilisées selon différents schèmes. Le schème d’URI étant la syntaxe associée à un protocole de la couche « application » du modèle OSI : le plus connu étant le schème des URIs HTTP. Initialement,  le « déréférencement d’URI » était assimilé à la fonction HTTP GET, c’est à dire à la fonction qui permet de demander la représentation d’une ressource :

To dereference a URI means to request a representation of the resource designated by the URI. The dereference mechanism varies according to URI scheme and must be defined by each scheme where dereferencing is a goal. See « Guidelines for new URL Schemes » [RFC2718]. The dereference mechanism for the HTTP URI scheme is GET [TAG issue whenToUseGet-7].

Le déréférencement est donc l’action qui s’enquiert de la représentation (jpg, xml, html, RDF, etc.) d’une ressource.

Si les URIs référencent des représentations, il n’est pas pour autant nécessaire qu’elles impliquent systématiquement le déréférencement de cette URI. C’est d’ailleurs un des principes de l’architecture du web, en vertu duquel il y a lieu de ne pas systématiquement déréférencer les URIs car cela a un coût en calcul, en utilisation de la bande passante et potentiellement en sécurité. Donc, si toutes les ressources ont des représentations, toutes ne font pas de déréférencement des URIs, c’est à dire d’accès aux représentations :

Principle : Reference does not imply dereference

An application developer or specification author SHOULD NOT require networked retrieval of representations each time they are referenced.

Par la suite, le document de référérence sur l’architecture du world wide web stabilise et étend la définition de l’expression « déréférencer une URI » de la manière suivante :

Accéder à la représentation d’une ressource identifiée par une URI

Cette dernière définition élargie donc les toutes premières qui assimilaient l’action de déréférencer une URI à celle d’un agent performant un HTTP GET pour récupérer une représentation. Il y avait donc initialement un primat aux action des agents qui était en mode « Safe » et « Indempotent » (les méthodes GET et HEAD en HTTP) dans la compréhension du déréférencement. Ce primat a disparu puisque, désormais, l’utilisation de toutes les méthodes HTTP (GET, HEAD, POST, PUT, DELETE) relèvent pleinement du déréférencement d’URI.

On trouve l’embrion de de cette généralisation dans un message de Stuart Williams sur la mailing list du W3C en juillet 2002 dans lequel il précise :

URI Resolution:
The process of determining the access mechanism and
appropriate parameters necessary to dereference a
URI. e.g. in the case of an HTTP URI, this process
resolves the URI into an IP address, a port number,
a host name (possibly optional) and a request URI.

Resolution may require several iterations.

URI Dereference:
The process of using the access mechanism and
parameters generated by URI resolution to create,
inspect or modify resource state.

URI Retrieval:
The use of URI dereference to retrieve
representations of resource state.
[On the Web Retrival is always safe].

Je termine en rappelant les quatres règles pour produire des Linked Data proposées par Tim Berners Lee :

1. Utiliser les URIs pour nommer les choses ;
2. Utiliser le schéma des URIs HTTP ;
3. Faites en sorte que les URIs délivrent des informations : c’est ici que l’on parle donc d’URI déréférençables ;
4. Faites des liens ailleurs, vers d’autres corpus de données ;

Vous pouvez aller plus loin en consultant le document du W3C qui indique comment publier des données liées (Linked Data) sur le Web.

Signaler sur Twitter

Related posts:

1. Designez vos URIs en RDF Mon hypothèse : plutôt que d’encoder les données en RDF,...
2. Designez vos URIs en RDF (2) Suite à une petite discussion de couloir avec Got, je...
3. URI design Je regarde une note de Yves-Marie Pondaven dans laquelle il...

Invité comme conférencier à la réunion annuelle des directions informatiques du Ministère de l’Éducation Nationale qui se tenait à Cannes, j’ai pu mesurer – une fois de plus – le fossé qui se creuse entre d’une part la manière dont on parle des systèmes d’information, dont on vend des projets informatiques, et d’autre part la manière dont on réalise les projets informatiques.

Le conférencier externe qui me précédait lors de cet événement venait parler de la SOA (Service Oriented Architecture). Quant à moi, je parlais juste après lui des architectures ROA, de REST et du Cloud Computing. Autant dire que, sur beaucoup de points, nos discours étaient dissonants voire contradictoires pour l’auditoire.
Aussi, la question qui revenait au moment du déjeuner était :

« Mais alors, faut-il faire de la SOA ou pas ? »

Ma conviction est que la seule chose que propose une démarche SOA c’est un dessin, celui des sempiternels blocs qui s’agencent sur un socle EAI ou ESB, avec un moteur de règle magique qui traîne dans un coin. Ce dessin est une sorte de fantasme récurrent depuis plus d’une décennie dans le mode de l’informatique de gestion d’entreprise. L’illusion repose sur ce principe très simple que, pour masquer une complexité, il faut la mettre dans une boîte. Bien sûr, cela ne résout rien, mais cela repose l’œil de voir toutes ces petites cases qui s’agencent à merveille dans le format d’un slide de power point. A un tel point que je ne suis pas loin de penser que la SOA, qui n’est pas une architecture au sens strict, relève plutôt d’une « architecture power point » : comme si le support et le format de communication conditionnait l’avenir d’un système d’information.

Je suis donc de plus en plus convaincu que la SOA est finalement un style d’architecture, pour reprendre l’expression de Fielding, mais dont les contraintes qui s’expriment n’ont rien à voir avec la réalité d’un système d’information mais bien plutôt avec les contraintes du support de présentation qu’est le slide de power point.

Pour éclairer ce point, il faut jeter un regard en arrière sur les schèmes utilisés par les vendeurs de logiciels, et qui sont toujours utilisés, encore aujourd’hui.

Ainsi, lorsqu’il y a plusieurs années, les premiers éditeurs proposant des solutions d’EAI (Entreprise Application Integration) venaient présenter les bénéfices de leur logiciel aux Directions des Systèmes d’information, voici ci-après les schémas qu’ils utilisaient.

Tout d’abord ils présentaient les flux de données que s’échangent les applications entre elles :

Forcément, ce plat de spaghetti est le cauchemar des responsables des systèmes d’information : çà part de tous les côtés et, pour maintenir en état et gérer tous ces échanges, ce n’est pas une sinécure.
Mais tout çà c’était avant ! Avant que les solutions d’EAI (aujourd’hui marketée en ESB : Enterprise Service Bus, dans le cadre des démarches SOA) n’arrivent en vous présentant cette formidable image :

(j’ai pris ces images au hasard, il y en a des milliers similaires sur le Web)

Avec une telle représentation c’est le calme, l’apaisement et la rationnalité qui s’imposent enfin. Le bus d’entreprise (ESB) permet « simplement » de brancher (to plug, comme plug and play) chaque application du système d’information afin qu’elle puisse dialoguer simplement avec le reste du système d’information.

Le couple formé par ces deux images possède un pouvoir de conviction et d’adhésion qui me surprend toujours. Il semble inusable. Il a été décliné initialement avec Tuxedo pour les middleware orientés transactionnel, puis avec MQseries pour les Middleware orientés Message, puis avec les solutions d’EAI, et après par les Solutions de SOA, il est en train d’être repris au niveau des données avec les démarches de Master Data Management, on le retrouve dans l’UIMA de IBM pour le Text Mining et, pour finir, Google vient de nous le resservir avec son API (pas) OPEN Social :

Mais, en vérité, le fondement de l’interopérabilité, dans un système d’information, ce n’est pas tant que les applications ou les services se parlent, c’est que les données soient ouvertes. Si les données n’étaient pas encapsulées dans les applications, l’image magique du Bus et des démarches orientées services perdraient tout leur intérêt.

Le principe de ce schéma est toujours le même : placer à la périphérie les éléments du système d’informations (applications, services, données, réseaux sociaux, etc), puis poser la pièce maîtresse au centre, le rouage ultime, qui va permettre d’articuler tout ce petite monde. En cela le schéma va plonger dans notre subconscient, reproduisant ici le système solaire, ou là le moyeux la roue. Parfois aussi le temple ou la pyramide, quand on fait appel à des modèles non concentriques.

Mais ce que ne dit pas ce schème de représentation, c’est précisément ce qu’il exclut :

• il ne dit pas que la solution est loin d’être magique : à défaut de « solution » on a plutôt une boîte à outil qui permet de relier les fils entre eux, mais il faut se taper tout le boulot.
• il ne dit pas qu’il exclut de facto tout ce qui n’est pas relié au bus. En reliant des applications au service, on enferme encore plus ses applications, ce qui rend le système d’information endogène : l’intégration interne se paye par une exclusion de l’entreprise aux données et aux services externes.

Mon sentiment peut paraître surprenant mais, eu égard à ces schémas de représentations, je pense que le schéma des spaghetti n’est pas une mauvaise chose en soi. Voilà pourquoi :

• parce qu’on ne voit que les machines et pas les acteurs et les utilisateurs dans ce schéma. Ou sont les utilisateurs ?
• on cherche à faire parler toutes les applications avec toutes les autres applications, mais pourquoi donc ? C’est comme si l’on s’épuisait à imaginer tout le champ des possibles en s’imposant cette contrainte un peu folle de vouloir tout connecter avec tout.
• les données échangées ne sont comprises qu’au niveau des serveurs et pas au niveau des clients, la logique des mash-up, qui marche, permet les échanges au niveau des postes clients et pas au niveau des serveurs et des applications elles-mêmes. Les clients légers ou riches des architectures actuelles sont purement absents.

Ce qui se dégage de toute cette histoire c’est que le Business Model du software est très souvent un modèle qui consiste à identifier une douleur dans le Système d’Information  pour proposer une solution logicielle à cette douleur. Le logiciel joue ici son rôle de pharmakon, de médicament. Et son périmètre dans le système d’information est proportionnel à la taille de la tumeur qu’il est sensé traiter. Il est généralement vendu et « marketé » comme une boîte noire avec en entrée les problèmes et en sortie les solutions. Mais entre ? Que se passe-t-il ? Ouvrons le capot et regardons : que voit-on ? Tout d’abord que la source du mal n’a pas été éradiquée, elle est toujours là. On ne soigne que les symptômes du mal, pas le mal lui-même.

A force de reproduire ce schéma depuis des années, les grands systèmes d’information deviennent, bien souvent, proprement monstrueux. Car plus de logiciel demande toujours plus de logiciel : le code appelle le code. Mais qu’est ce qui a accéléré ce mouvement ? Un défaut initial , ou une négligence d’encodage des données manipulées par le code, c’est à dire un défaut d’architecture des données, de la on assiste à une excroissance du code : comme une huître faisant sa perle autour d’une poussière, mais malheureusement la perle en question est ici une tumeur.

Ceux qui prônent les démarches SOA ne sont pas idiots pour autant : ils reconnaissent qu’il n’y a pas vraiment de références significatives sur la mise en oeuvre d’une telle démarche, prennent d’infinies précautions en instant sur le fait qu’une telle démarche prend, à minima, une décennie avant d’aboutir réellement, et admettent que la plupart des projets SOA sont des échecs.

Ce qu’il y a d’intéressant dans leurs discours, c’est qu’ils soutiennent qu’il y a une « SOA de surface », celle qui consiste à croire qu’un logiciel miracle va orchestrer les services web pour « aligner l’IT sur le métier », qui est la cause de la plupart des échecs en matière de SOA. Comment donc appréhender une démarche de SOA afin d’éviter cet écueil ?

« Il ne faut pas commencer par les process et les services mais par les données, disent-ils. La SOA est une chaine de valeur qui commence avec la qualité des données, si ce maillon ne donne pas satisfaction il est illusoire qu’une SOA puisse se mettre en place ».

Étonnante rhétorique pour une démarche d’architecture orientée services qui affirme qu’il faut d’abord commencer par une architecture orienté ressources et données pour arriver à sortir quelque chose qui tient la route ! Pourquoi ne pas commencer directement par la ROA (Architecture Orientée Ressource) comme démarche d’architecture dérivée du style d’architecture REST ?

La raison vient de ce que la finalité des démarches SOA se place toujours sous l’injonction « d’aligner l’IT sur le Business », la SOA est comme prisonnière de ce slogan. Ce qui n’est pas le cas de la ROA dont l’ambition est beaucoup plus pragmatique puisqu’il s’agit simplement d’aligner l’IT sur le Web : ses architectures, ses normes ainsi que ces usages et ses pratiques.

Quand on voit que ce sont essentiellement le secteur des banques et assurances qui s’essaient à ce type de démarche, je suis tenté de penser que la SOA est à l’IT ce que les subprimes ont été à la finance. Et la SOA serait finalement une démarche de titrisation de la piètre qualité des données dans les systèmes d’information pour valoriser des approches abracadabrantesques. Pourquoi vend-on de la SOA finalement, et pourquoi – parfois – çà marche ? Parce que c’est énorme et, comme pour les mensonges, plus c’est énorme et plus çà a de chances de passer.
Cela éclaire également la remarque de Fielding que j’évoquais récemment et que je traduirais volontiers de la manière suivante :

« La conclusion raisonnable de ceci est que la SOA n’est ni style ni une architecture, mais un ensemble d’objectifs qui peuvent être vendus à des DSI dépassés eut égard aux architectures qui seront réellement implémentées. »

In fine, là où je me désolidarise de Fielding c’est que je crois que la SOA est bien un style d’architecture, c’est le style d’architecture documentaire du power point. Certes, cela n’a plus grand chose à voir avec l’informatique, celle qu’on aime, celle qui marche et qui nous donne satisfaction.

Related posts:

1. La vérité sur la SOA Roy Fielding, a propos des SOA, des « Service Oriented Architecture »...
2. C’est quel éditeur qui fait çà ? Je croise un consultant qui travaille sur les architectures de...
3. Une certaine conception de la souveraineté s’exprime aussi dans les choix d’architecture Dans son Post-scriptum sur les sociétés de contrôle (1990), Deleuze...

Roy Fielding, a propos des SOA, des « Service Oriented Architecture » sur la liste de discussion REST :

The reasonable conclusion is that SOA is neither an architecture nor a style, but rather a set of goals that can be sold to overmatched CIOs regardless of the corresponding architecture or implementation.

Related posts:

1. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
2. Le profilage collaboratif sur Twitter Les listes de twitter vous renvoient à présent des mots...
3. Le style d’architecture SOA Invité comme conférencier à la réunion annuelle des directions informatiques...

La nouvelle a vite fait le tour de la blogosphère : Adobe, Yahoo et Google ont signé un partenariat pour indexer les fichiers flash.
Les premières réactions que j’ai pu lire sont plutôt positives. Mais je reste dubitatif devant cette initiative, et ce pour certaines raisons :

• d’abord sur le contenu : j’imagine (à tort ?) que la plupart des contenus en flash ne sont pas les textes les plus passionnants du web ; beaucoup de communication marketing me semble-t-il, non ? Ou en tout cas des textes très fragmenté.

• ensuite, ce contenu, s’il s’avère être de piètre qualité, va énormément rajouter de bruit dans les réponses des moteurs de recherche : quel intérêt pour l’utilisateur de voir les messages publicitaires et marketing contenus dans les flashs se retrouver dans ses résultats de requête ?

• la logique d’un site en flash n’est pas la même que celle d’un site en HTML, dans le premier elle est événementielle et souvent scénarisée, alors qu’il n’y a pas cette logique d’enchaînement scénarisé dans le HTML. Qui plus est, un évenement sous Flash (car Flash c’est surtout une programmation évenementielle), n’est pas forcément un clic de souris alors que le clic reste le seul moteur hypermedia du web en HTML. Deux logiques d’architecture de l’information et de politique éditoriale différentes donc.

• donc, comment ces deux logiques de contenu éditorial et d’architecture de l’information vont elles cohabiter dans l’index des moteurs de recherche et les pages de résultats ?

Au dela des contraintes techniques, il y a donc eu un partenariat. Mais pourquoi ce partenariat et pourquoi maintenant ?
L’intérêt d’Adobe semble de prime abord évident : c’est une reconnaissance pour leur format de fichier que de passer à la moulinette de l’indexation des moteurs de recherche. Les documents des interfaces riches vont rejoindre la masse des autres documents qui sont rentrés dans l’économie des moteurs de recherche.

Mais pour Google : pourquoi choisir d’indexer les fichiers Flash et de prendre ainsi le risque de perturber le modèle même de son fonctionnement ?

Google trouve-t-il son intérêt directement dans l’indexation, ou indirectement ? Dit autrement : font-il çà pour quelque chose ou contre quelque chose (ou quelqu’un) ? Vu sous cet angle c’est encore Microsoft le premier visé (décidément). Un Microsoft qui risque de se retrouver à être le seul moteur qui indexe ses interfaces riches en Silverlight.

Mais ce qui m’embête le plus dans cette annnonce, c’est que les architectures orientés ressources, qui sont les architectures de prédilection des trois interfaces riches (GWT, Flex et Silverligth), vont devenir moins incontournables : en effet, pourquoi faire les choses proprement avec une architecture orientée ressource si je peux avoir mon site indexé directement en Flash ? Cette annonce lève à mes yeux une contrainte qui avait du bon et qui avait le mérite de rendre cohérente, et vertueuse, une démarche d’architecture de l’information (et applicative) couplée avec des interfaces riches.

Certes, il est toujours possible – et souhaitable – de faire des architectures orientées ressrources, mais la contrainte de l’indexation étant maintenant partiellement levée, tout cela risque de ralentir la progression de certaines bonnes pratiques.
Autre hyppothèse pour expliquer ce partenariat : Google préfèrerait-il garder le web dans un certain « bordel ambiant » pour rester celui qui l’organise et le monétise pour nous ?
Et je termine avec cette dernière hypothèse : Google souhaite-til indexer les fichiers Flash non pas comme des documents, mais bien comme des applications, c’est à dire avec une logique d’indexation et de restitution bien spécifique (et donc monétisable de manière plus fine et mieux adaptée).

Sur ce sujet, je vous invite à lire deux billets intéressants sur le blog de François Le Droff, puis de consulter une très bonne synthèse d’Aurélien Pelletier sur les technologies RIA.

Vos avis sont les bienvenus pour confronter mes tergiversations à votre vision de la compréhension et des conséquences de cet accord Google / Yahoo! / Adobe sur l’indexation du Flash

Related posts:

1. Google Video for Business Google vient de rajouter la video dans son Offre Google...
2. Jouir de l’avenir Dans sa Vie du lettré aux éditions de minuit, William...
3. Plus loin avec Google Apps Saviez-vous qu’avec Google Spreadsheet vous disposez de quelques fonctionnalités bien...