Roger Sessions poste quelques articles intéressants, même si je ne suis souvent pas d'accord avec ses prises de position. Récemment, j'ai reçu par sa "mailing list" un renvoi sur sa méthodologie SIP. Cet article est intéressant car il traite de la complexité du SI et de l'architecture comme moyen de maîtrise de cette complexité.
Roger donne la définition de la complexité d'un système comme étant le nombre total d'état que peut prendre un système. Ma vision de la complexité est proche mais différente et sera exposée dans un futur billet.
Néanmoins, ce qui est intéressant est l'explication basée sur des fondements mathématiques pourquoi sa méthodologie SIP (pour Simple Iterative Partioning) est un moyen de réduire cette complexité. Mais en fait ce qui est amusant est que son explication est fausse.
En effet, le nombre d'état total de 2 sous-systèmes indépendants n'est pas la somme de 2 sous-systèmes, mais bien le produit. Par exemple: soit 2 dés à jouer. Chaque dé peut être dans un de ses 6 états. Le nombre total d'états est de 36 et non pas 12.
La complexité du système total n'a pas changé : que j'ai 2 dés ou un dé à 36 faces, le problème est le même. Par contre, le fait de savoir partitionner en 2 entités indépendantes permet une meilleure maîtrise de cette complexité, car il permet de réfléchir sur un sous-domaine autonome.
Toute la difficulté est le découpage en entités indépendantes... Ce que propose Roger est un partitionnement sur la dépendance réflexive entre fonctions. Le risque que je vois est l'oubli assez facile des données dans ce périmètre qui peut mener à un partitionnement différent.
Thibault Ducray (ex-collègue) a écrit il ya quelques temps un article exprimant son point de vue sur le bon et le mauvais XML. Cet article est intéressant, mais pour ma part, le problème de taille du XML, sa verbosité, ne nécessite pas d'inviter un nouveau langage simplifié déclaratif.
Aujourd'hui, le problème principal dans le traitement de l'information n'est pas ni le stockage (un disque dur de 500 Gigaoctets vaut moins de 150€), ni le temps de traitement (processeurs > 2000 Mhz, processeur multicoeurs, etc...), mais les entrées-sorties. Pour résoudre la verbosité d'XML qui est donc un problème pour les échanges, il suffit de le compresser et décompresser à la volée avec par exemples des algorithmes sans perte type Lempel-Ziv et autres.
La bonne nouvelle est que ceux-ci (zip, gzip) sont directement supportés par tous les OS et même les échanges HTTP. Le coût de compression/décompression par le CPU reste négligeable par rapport au cout de transfert I/O, particulièrement à partir/vers le réseau.
Il est d'ailleurs souvent "gratuit", car sinon le CPU est de toute façon bloqué en attente des I/O. C'est moins vrai sur les serveurs, mais ce surcoût est largement compensé par le hardware et la loi de Moore.
Le principal défaut d'XML est qu'il ne sait véritablement transmettre de l'information que sous forme d'arbre. Dans la plupart des cas, il est donc nécessaire de transformer l'information métier en une projection arborescente forcément réductrice.
C'est décidé, je me lance. Après avoir beaucoup hésité, je me retrouve dans la BlogSphère. L'idée de ce blog est de partager idées et concepts sur un de mes domaines actuels de prédilection, qui se cache derrière les buzzwords comme :
