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...

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...

Nous sommes en train de vivre une quatrième révolution dans l’architecture des systèmes d’information et des technologies de l’information. Il y a ainsi eu les vagues suivantes (merci à Aurélien Pelletier qui m’a bien martelé la chose) :

• le Hardware, représenté par IBM et le Mainframe (client passif)
• le Software, représenté par Microsoft  et le client-serveur (client lourd)
• le Netware, représenté par Sun et l’architecture 3 tiers (client léger)
• enfin, ce que je nomme DataWare avec l’architecture orienté ressource (client riche)

Le « ware » de chaque vague d’architecture vient du vieil écossais qui signifie « objet de soin ». Chaque période architecturale a donc eu son objet de soin et d’attention ; ce qui ne signifie nullement que le hard où le soft aient aujourd’hui disparus, mais simplement qu’une attention toute particulière est accordée à autre chose. En l’occurrence aux data.

Roy Fielding, dans sa thèse Architectural Styles and the Design of Network-based Software Architectures, rappelle que la plupart des premières études sur l’architecture logicielle s’attardaient sur les composants et les outils de développement mais très peu sur les données manipulées elles-mêmes. Roy Fieldling termine ainsi le premier chapitre de sa thèse en écrivant :

« much of the prior research on architecture excludes data as a important architectural element » p. 23

A vrai dire Roy Fielding met en avant l’importance des data dans l’architecture des logiciels selon un point de vue en particulier, à savoir dans une vision réticulaire, c’est à dire en réseaux, de ces données. Il laisse de fait la question de l’architecture des data elles même en suspend.
La question du stockage et de l’encodage des données est ainsi laissée de côté. Pour lui RDF n’est qu’une représentation, comme HTML, JPG ou XML.
Dit autrement, son architecture REST est orientée données en ce sens que les données sont accessibles sur le web, et je le soupçonne donc de ne pas aller jusqu’au bout de la logique Dataware, c’est à dire qu’il met en avant l’aspect connexion de l’architecture (plus que l’aspect Data), et pour être plus précis la manière dont le protocole HTTP accède aux données (aussi appelées ressources).

Je pense que Roy serait tout à fait d’accord pour reconnaître cette tendance dans sa thèse puisqu’il a part la suite songé à la mise en place d’un nouveau protocole dénommé WAKA, censé enrichir/remplacer HTTP en conférant aux ressources disponibles sur le web des propriétés sémantiques et dynamiques. En 2006, dans un podcast avec Jon Udell, Roy présentait brièvement ce nouveau protocole en ces termes :

 » Waka is a binary token based replacement protocol for HTTP. The goal is to create a language independent mechanism for exchanging data oriented messages using the ReST architectural style – the principals and design.
An application protocol that is efficient as any custom protocol yet generally applicable like HTTP. The difference is that we get rid of HTTP syntax, make it possible to interleave meta-data with data in independent streams/frames. Doing this in a way that is efficient as possible without being entirely generic i.e. Waka is not attempting to replace TCP. This means Waka would be suitable to application integration inside the firewall and well as outside. »

Dans une architecture orientée ressource comme l’est l’architecture du Web qui s’affirme au travers de la tendance Web 2.0,  l’importance des data vous « saute au visage » car ces données sont exposées et accessibles via des APIs, notamment car chaque datum, chaque ressource, dispose d’un identifiant (URL).
A titre de comparaison, combien de data dans les systèmes d’information des entreprises sont accessibles directement sans faire et refaire du développement spécifique ?

Pourtant, ce qui manque au Dataware, compris à partir notamment des architectures orientées ressources, c’est  une vision qui corrèle la localisation des data, ou leur modalité d’accès (car cela influe effectivement sur le style d’architecture logicielle) avec la structuration des données elles-même, et entre elles.

J’appelle MetaDataWare ce complément au DataWare et, bien évidemment, l’un n’efface pas l’autre, puisqu’il s’agit d’articuler une architecture logicielle REST avec une architecture des data en RDF.

Plus les données sont structurées entre-elles, moins il y aura de lignes de codes. Ce qui signifie que ce que Roy Fielding nomme les « composants », qui reçoivent et traitent de l’information dans une architecture logicielle, sont amenés à être beaucoup plus légers, ce qui implique qu’ils seront plus faciles à maintenir et à faire évoluer.
Quand Fielding écrit que « hypermedia is the engine of application state », cela indique que la richesse du lien (le hypermedia) est le vecteur de puissance du style d’architecture REST car c’est dans la ressource (plus précisément dans ses représentations) qu’est puisée les potentialités logicielles (plus que dans le composant/code qui traite l’information).

Articuler REST et RDF est une de mes principales préoccupations (malheureusement pas ma principale occupation), avec la sensation que la prise en considération des spécificités de RDF devrait introduire un style d’architecture que ne sera plus vraiment REST, mais autre chose.
Ce qui m’amène a dire que, contrairement aux apparences, je ne vois pas en quoi REST est un style d’architecture orientée ressource, c’est à mes yeux un style d’architecture orienté protocole de connexion (HTTP) et accès aux ressources, plus que ressource ou data à proprement parlé.
Aussi je crois qu’une vraie architecture orientée ressource reste à venir pour passer du DataWare au MetaDataWare.

Etes vous d’accord ? Et comment vous imaginez-vous le style d’architecture qui serait réellement orienté metadata ? REST serait-il toujours approprié ?

Related posts:

1. La vérité sur la SOA Roy Fielding, a propos des SOA, des « Service Oriented Architecture »...
2. REST en image On a beau dire, parler de « Representational State Transfert » reste...
3. Activation de compte en mode REST Voici la traduction d’une partie d’une note de Seth Ladd....

Mon hypothèse : plutôt que d’encoder les données en RDF, mieux vaut encoder les URIs en RDF.

Dans la phase de design d’une architecture RESTful, les ressources clés sont identifiées puis on donne à chacune une URI.

Par défaut, quand on pense URI ou URL, c’est la représentation de l’arborescence d’un site web qui nous vient à l’esprit, et cela implique souvent un certain design des URIs qui en découlera (une taxinomie).
Mais si on appréhende les URIs non comme des branches, mais plutôt dans le cadre de la théorie des graphes, alors des opportunités plus intéressantes peuvent se présenter.

Toute la richesse de RDF peut être mise à profit pour décrire l’environnement constitué par les liens entre vos ressources. Mais les ressources elles-mêmes ne sont pas nécessairement encodées en RDF.

Cette positon a le mérite de contourner deux obstacles auxquels le web sémantique doit actuellement faire face :

• le manque de scalabilité des entrepôts RDF (avec les données en RDF donc).
• le système de requêtage des graphes en SPARQL est puissant mais c’est essentiellement un langage d’interrogation et non d’écriture (c’est bon si vous voulez faire un catalogue en RDF, mais si c’est pour faire une application avec un nombre important d’écriture, çà a des chances de ne pas tenir).

Ce débat existe-t-il ?
Votre avis ?

Related posts:

1. Designez vos URIs en RDF (2) Suite à une petite discussion de couloir avec Got, je...
2. Le vocabulaire HTTP en RDF Un groupe de travail du W3C a produit un Working...
3. De la temporalité des ontologies Cela fait un petit moment que je voulais ajouter des...

C’est quand on est au pied du mur, dans une impasse, que l’on est bien souvent prêt à écouter des conseils qu’on n’aurait pas entendu dans d’autres circonstances. C’est dans ces moments que l’on est prêt à reconsidérer ses positions et où l’on accepte de prendre des chemins que l’on jugeait inopportuns quelques temps auparavant.

Un projet s’enfonce et s’enlise ? Et si l’on vous dit à ce moment là que l’on peut le réaliser deux fois plus vite et pour deux fois moins cher, forcément on est tout ouïe. Et vous n’allez pas objecter que c’est du REST, du web 2.0 ou quoi que ce soit d’autre, c’est devenu le dernier de vos soucis pourvu que vous puissiez sortir par le haut de cette impasse.
Méthodes Agiles, architectures REST, projets Web 2.0, solutions SaaS, rien de mieux pour concrétiser ces démarches que d’avoir une entreprise qui a pris un bon mur de face (ou de dos car ne le voyant pas venir) pour entrevoir les choses différemment.

Je ne cherche plus à convaincre une entreprise que son système d’information devient endémique – comme dirait Nicolas Hulot – et donc qu’il faut adopter le web au travers de ses normes, de ses architectures, de ses pratiques et de ses usages.
Il suffit juste d’attendre l’impact avec le mur pour que la raison et le bon sens reprennent leur droits, comme par enchantement.

Je me demande parfois si les démarches d’Entreprise 2.0 ne sont pas un remède, et si je ne devrais pas plutôt ouvrir une pharmacie 2.0.
Que dis-je, Hôpital 2.0 serait bien mieux approprié, tant les maux dont souffrent les systèmes d’informations sont vastes et profonds.

Related posts:

1. Manifestations contre le Contrat Première Embauche La question est : est-ce que les jeunes des émeutes...
2. You ? Vous êtes convaincu que le web est la plateforme ?...

J’ai pu avoir un avant goût de la présentation que fera Aurélien Pelletier aux Techdays 2008 de Microsoft en février prochain.

Si vous êtes sur Paris c’est quelque chose à voir : des principes d’architectures RESTfuls à la mise oeuvre d’architectures techniques orientées ressources, l’évidence des architectures web vous sera révélée.

On peut s’inscrire dès à présent.

Related posts:

1. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
2. Précieuses ressources Ensmedia, la base de ressources audiovisuelles et multimedia de l’ENS...
3. C’est clair, non ? Le site twitteradar vous tient informé de l’actualité du service...