Sylvain Berthu

Imaginez le concept : une collection de micro objets contenant chacun des méthodes très simples et aux traitements très atomiques et très génériques (tri, calcul de tva, envoi de mail, ...). Il est important de concevoir ces méthodes sans paramètres (donc sans contexte de lancement) et aux résultats (effets de bord) inconnus pour les autres classes (sans paramètres de retour). Grosso modo, le terme "action" est plus adapté au terme "méthode" et la classe nous permet de les regrouper par affinité (on évitera les outils de la POO comme l'héritage). Au final on a du code très simple, sans aucune interdépendance, bref, une collection d'outils.

De l'autre côté, on a un fichier XML qui va nous permettre de planifier les exécutions séquentielles ou parallèles (d'où le XML) des méthode atomiques. Un moteur (Moteur de Synchro) va donc parcourir l'arbre XML et lancer les actions les unes après les autres ou en même temps (suivant la branche de l'arbre).
Un contexte de lancement sera transmit à chaque action ; contexte qui contient l'objet DOM de l'arbre, une collection de variables nommées et typées. Les méthodes pourront donc aller piocher les variables intéressantes dans la collection et générer un ou plusieurs résultats au format nom/type/valeur stockés à leur tour dans la collection.
Si le paramètre attendu n'est pas encore présent dans la collection, l'objet peut rendre la main au MS ou l'attendre (n'oublions pas que nous sommes dans un contexte multi-thread). Un objet a aussi la possibilité de modifier l'arbre XML de traitement (gestion d'erreur, exception, aiguillage, itération fonctionnelle, ...).
Enfin, une entrée XML peut avoir un ou plusieurs attributs conditionnels (contexte de lancement) permettant au MS d'exécuter ou non la branche en question (genre de switch/case). Le MS continue ainsi de lancer les méthodes jusqu'à la fin du fichier XML.

Avantages :

• La programmation revient à modifier l'arbre XML, les classes et méthodes invoquées étant suffisamment génériques pour ne pas être modifiées.
• L'arbre XML peut changer au cours de l'exécution et donc le système "apprend"
• Les traitements conditionnels sont rendus plus clair ; plus de if/endif mais des branches XML parallèles
• La programmation est très contextuelle

Inconvénients :

• Difficile d'élaborer ces classe génériques sans tomber dans la composition d'un macro langage. Les méthodes doivent rester des actions atomiques qui font du processus métier et non devenir des métas instructions de code.
• Le contrôle du programme peut devenir justement incontrôlable !
• Difficile à déboguer, mais ceci est l'intérêt de la programmation parallèle

A votre avis, c'est viable ou il faut que j'arrête le café ?

Il semblerait que l'émergence des architectures davantage orientées service (je ne parle pas de SOA, mais seulement de l'ouverture service) pousse la couche présentation de plus en plus loin, voir carrément chez le client.
Qu'en est-il des clients riches (ou lourds ?) à l'heure actuelle ?
C'est vrai que l'on entend de plus de plus des termes comme ajax, xul, Xaml voir même flex (ou java bien sûr) mais qu'en est-il de l'expérience sur le terrain ?
Une solution Web-services d'un côté consommée par un client lourd est-elle viable aujourd'hui, en 2006 (oui, je prends de l'avance ;)) ?