DataWare et MetaDataWare

by Christian on 1 juin, 2008

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é ?

Print Friendly
Signaler sur Twitter

{ 4 comments… read them below or add one }

Got juin 1, 2008 à 11:03

Merci de mettre le doigt sur ce qui me gênait dans REST, je n’ai jamais réussi à comprendre quelle était l’évolution apportée au niveau des données elles-mêmes (je ne remets pas en cause l’apport au niveau protocole et architecture, j’en suis incapable).

Quant à ta dernière question, j’aurais bien une réponse, mais on va finir par penser que c’est une idée fixe. Pas grave : je pense que l’architecture dont tu parles existe, c’est SPARQL, SPARQL et SPARQL, à savoir SPARQL, le langage de requêtes, SPARQL, le protocole et SPARQL, le format XML. Et, le tout est normalisé. Pas belle la vie 😉

Mais, pour réussir à mettre en place cette architecture, il faudra que les DSI et autres SSI comprennent qu’à côté des architectes logiciels et des architectes fonctionnelles, il est absolument nécessaire de disposer d’architectes des données.

Répondre

Christian juin 1, 2008 à 11:17

Merci de rappeler que SPARQL est aussi un protocole !
Bien vu.

Répondre

Aurélien juin 3, 2008 à 10:52

L’informatique est le traitement automatique des informations ou des données. Mais il faut bien avouer que jusqu’à aujourd’hui et pour longtemps encore l’informatique c’est surtout le traitement manuel de problèmes hard-ware, soft-ware ou net-ware.

Il me semble que le PC (en cluster) avec de la virtualisation apporte un bon niveau de réponse aux problématique hardware. Pour le software, la conception objet, le language UML, les méthodes agiles ou le modèle open source ont prouvés leur efficacités. Pour les problèmes réseaux je pense que REST en tan style d’architecture pour système hypermedia distribué apporte à son tour des réponses libératrices.

Donc oui, comme tu le fait remarquer REST traite plutôt de la couche la réseau, de l’accès à la donnée plus que de la donnée elle-même. Mais en étant suffisamment affranchi des problèmes hard, soft et net on peut commencer à penser l’informatique dans son sens premier: le traitement de la donnée. L’architecture orienté ressource, reste elle entièrement à définir.

Au sens REST une ressource est identifiée par une URI, a des représentations et des méta-données

Comment concevoir ces URIs, quelles représentations retenir (XML, RSS, JSON, RDF, microformat, …) quels méta-datas (auteurs, date, type-mime, ..) Voilà les questions auxquelles doit répondre ta metadataware architecture si elle s’appuie sur REST.

Répondre

vincent juin 19, 2008 à 5:35

S’il est important de mettre en oeuvre une chaine d’échange d’information contenant des propriété ou des comportenant intrassect à la données.
La compréhension de la données est le plus important.
On veut souvent échanger sans comprendre la signification des données échangées. Quelques sont le mode de stockage, traitement ou visualisation de la données mise à disposition, l’aspect fonctionnelle de l’information doit être le point le plus critique avec également sa qualité.
Une architecture 3 tiers distribué via le Web (HTTP, AJAX, …) doit garantir une orientation qualitative et une réponse à un besoin réel.
REST ou pas …

Répondre

Leave a Comment

{ 5 trackbacks }

Previous post:

Next post: