Web Oriented Architecture

Je discutais l’autre jour des objets communicants l’autre jour avec Christian Fauré.

J’imaginais plutôt l’avenir avec des objets collaboratifs.

Un objet qui communique a une puce RFID ou équivalente pour pouvoir tracer le passage des objets devant un capteur et on peut lire et écrire des informations.
C’est bien pour la distribution … mais cela manque terriblement d’ambition.

Pour moi les objets doivent devenir collaboratif en utilisant les standards de l’Internet (ipV6, Http…).

Cela pouvait apparaitre comme une folie douce… et voila le plus petit serveur Web au monde ( http://linuxfr.org/2009/10/18/26038.html ).

On peut donc imaginer de mettre des serveurs Web dans les objets ce qui décuple les usages, les objets peuvent alors communiquer entre eux, on peut leur pousser des informations, on peut aussi en récupérer. Les usages sont sans limites.

Donnons nous quelques perspectives …

j’accede a au serveur web de la télévision : web.tv.mamaison.orange.fr
Je déclare les url des différents composants : le disque SAN, le lecteur DVD… pour que la télévision puisse piloter directement ces périphériques. Le pilotage est simple car il suffit d’un browser web simplifié pour que la télévision permette de surfer sur le paramétrage du lecteur DVD vu qu’il en connait l’url.
Je peux programmer une télécommande pour automatiser des opérations entre le lecteur DVD et la télévision. La télécommande peut lire des données pour savoir si le lecteur DVD est déjà en fonctionnement ou non …

Je peux accéder aux serveurs Web de mes vêtements qui retournent l’état probable du vêtement … (ça peut sembler fou mais rien n’empêche de mettre des capteurs pour compter le nombre de lavages…). Je peux donc me faire un tableau de bord sur l’état de mes vêtements…

Les électriciens font aujourd’hui de mauvais choix pour les compteurs électriques car ils se basent sur des protocoles propriétaires alors qu’ils avaient l’occasion de faire passerelle entre les appareils électriques et les réseaux ip et d’accéder en ip à son compteur pour avoir en temps réel sa consommation électrique, de pouvoir couper ou non des périphériques…
Ils auraient ainsi pu envoyer directement un mail pour recommander de baisser sa consommation avec un lien vers son tableau de bord pour savoir ce qui consomme le plus…

Des interactions entre son téléphone et sa voiture se simplifie comme dans cet exemple : http://fr.news.yahoo.com/16/20091117/ttc-ouvrez-fermez-et-localisez-votre-mer-c2f7783.html

Ces objets pourraient grâce a ipv6, c’est à dire une communication simple entre tous les appareils avec une pile ip, d’être intégré dans des services sur Internet qui restent a inventer.

Bien sur au départ par des protocoles propriétaires fait par leurs inventeurs pour résoudre un problème et a terme une standardisation progressive des échanges permettra d’étendre encore les services proposés sur Internet de pilotage, reporting…

On peut déjà apercevoir un monde ou les objets étant sur Internet ils peuvent communiquer entre eux, communiquer avec leurs utilisateurs et permettant de réelles interactions.

Google vient de sortir un nouveau protocole pour remplacer http.
Je reste assez dubitatif sur son intérêt, pour compresser les entêtes http je trouve ca risible vu l’overhead généré.

Pour traiter des cas complexes, il me semble plus simple d’ajouter une classe tcp (voir udp) en javascript pour émettre directement des connections puis des paquets… et de pouvoir se mettre en attente d’une réception de paquets dans le browser… ca permet de traiter proprement et sans overhead un protocole comme XMPP dans une page web sans inventer un nouveau protocole…
Ca me semble bien plus simple et moins impactant.
pour le multiplexage… ca existe déjà avec http 1.1.

J’avais fait un billet sur la develocratie, pour ceux que ca intéresse, voici une page qui détaille tous les problèmes théoriques soulevés par le mapping objet relationnel.

Ces problèmes théoriques devenant au final du temps de développement et des problèmes de performances…

Un billet également sur les problèmes des scripts versus langages a typage fort est disponible via une analyse de GWT. Jaime beaucoup ce juste commentaire :

Why is it we always get the “you never worked on a big project” argument every time you suggest scripting. Scripting projects are not smaller because they won’t work on big problems, they are smaller because they solve problems with less effort. I’ve never seen a newbie step into a spring application without shell-shock. The motives for spring are misguided, and the results are spaghetti code. If you have to open 25 files and sort through a 100 line stack trace for a single page view, then you are most definitely doing something WRONG. I would argue that is more unmaintainable than a decently constructed project in Ruby, where DI and IOC are basically free, if you every wanted them for some reason (no interface code required, and objects can much more easily be assembled in a dynamically typed language).