Tag Archives: framework

Linux on AIR

La technologie AIR d’Adobe est désormais disponible en alpha sous Linux.

linuxair.jpgPlus je regarde, plus je suis séduit par cette techno. Seul bémol, à vouloir dépasser les limites du navigateur ne risque t’on pas d’y perdre l’essentiel, à savoir la puissance des URI et du modèle d’architecture orienté ressource? Heureusement il y a des signaux positifs de ce côté là:

Est-ce qu’Adobe va réussir à faire avec Flex/Air ce que Sun a fait avec Java? Java s’est développé pour répondre à un nouveau besoin: le développement d’application client léger. Un nouveau besoin existe aujourd’hui: le développement d’application client riche, Adobe est bien positionné pour y répondre. Evidemment la concurrence est rude, les applications sur le poste de travail c’est la chasse gardée de Microsoft.
On en reparle bientôt, je serais mercredi au onAIR tour à Paris.

Comment font-ils?

Depuis 2, 3 ans google a recruté tout ce que le monde java compte comme star.

Depuis 2 ans google nous épate régulièrement avec des applis client riche en ajax incroyable (Google mail, calendar, maps, notebook,…)

Mais comment font-ils pour coder ces merveilles?

La réponse vient d’être dévoilée aujourd’hui: Google Web Toolkit

Google code l’interface de ses applis web en java puis utilise un compilateur pour générer du javascript de l’AJAX… Il fallait oser, ils l’ont fait et comme ils disent: “We’re biased, but we think it works pretty darn well”
Développer en javascript est très penible, c’est quasiment impossible à débugguer, alors que yahoo débug en affichant des messages dans un div, google peut se servir de toute la puissance d’un débugguer java…
Derrière ça vous mettez le google cluster, le google file system et mapreduce… Ils peuvent donner ce toolkit en open source, ils ont encore de la marge avant que la concurrence ne les rattrape.

Java, Php et Ruby sont dans un bateau…

Après son best seller “Better, Faster, Lighter Java” (il est dans la liste) Bruce Tate fait beaucoup parler de lui. Son interview déchaîne les passions sur theserverside.

En tout cas cette interview contient pas mal de remarques qui m’ont paru très pertinentes et synthétiques.

The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases.

Si j’y réfléchi deux secondes c’est effectivement ce que je fais depuis que je travaille. Il poursuit en expliquant que java a résolu le problème d’une manière “slow & clean” alors que d’autre langage le font d’une manière “quick & dirty”, je pense à php, Tim Bray aussi.

Avec Ruby On Rails Bruce Tate pense avoir trouvé une manière “quick & clean” le meilleur des deux mondes. La preuve? Un projet java non fini au bout de 4 mois a été bouclé en une grosse semaine avec ROR. J’ai fait passer le “10 minutes test” à ROR. Les 10 minutes se sont transformée en 2 heures mais j’ai effectivement pu réaliser une appli toute bête avec un formulaire CRUD. Et l’appli et effectivement clean quelqu’un qui connaît ROR n’aura aucune difficulté à comprendre ce qu’elle fait et à la maintenir.

Ca ne veut pas dire que ROR est une solution miracle, sur certain point la plateforme java reste incomparablement meilleure. Il donne les exemples des problèmes de two-phase commit et d’intégration avec beaucoup de système legacy.

Il met ensuite le doigt sur une des faiblesses de java:

Java doesn’t express data very well. While Java can declare structures that hold data, it doesn’t express the data itself well. And, that’s a big reason we’re seeing a lot of XML being bolted on to Java frameworks

Et effectivement je code de plus en plus en xml… Mais depuis quand xml est-il un langage de programmation?? Est-ce que les annotations sont la réponse à ce problème?

Enfin il traite du problème du “design by committee

Sometimes, the JCP seems to say ‘Find a problem. Build the standard. And, lastly, gather the experience.’ To me, that’s wrong.

C’est ce qui conduit a des specs comme EJB 1 et 2, WS-*… A l’opposé l’approche qui consiste à implémenter en premier puis à spécifier ce marche a produit par exemple Spring et Hibernate (ATTENTION on parle du processus pour créer un standard pas un application métier). C’est aussi l’approche que recommande l’IETF pour la définition des standards qui font tourner l’Internet, ça leur a plutôt réussi, non?

Jrules

Je viens de passer quelques mois à travailler avec le produit Jrules. Le sujet des moteurs de règles me semble intéressant je vous livre donc mes réflexions…

Sur son site web Ilog parle de Jrules ainsi:

“ILOG JRules 5.1 makes it easy for business users to manage rules “

“Grâce à ILOG JRules, les utilisateurs métier des sociétés de placement et de courtage pourront modifier eux-mêmes les règles régissant la conformité.”

Le message est très séduisant et passe très bien en présentation powerpoint auprès des décideurs… Mais en réalité ça donne quoi?

Que faut-il pour pouvoir écrire des règles?

L’exécution des règles dans Jrules repose sur un modèle objet. Avant de pouvoir écrire une règle il faut définir le BOM ou Business Object Model. Le BOM défini une sorte de modèle sémantique qui va permettre d’écrire les règles en langage naturel. Pour chaque objet et méthode on donne une traduction en langage naturel. L’écriture des règles se fait à partir du BOM.

Que faut-il pour pouvoir écrire de bonnes règles?
La qualité des règles dépend donc directement de la qualité du BOM qui lui même dépend du modèle objet.
Définir le BOM c’est fabriquer une sorte de Domain Specific Language: si le langage est trop pauvre: l’utilisateur sera trop limité. Si le langage est trop riche: l’écriture des règles sera trop compliqué. Il faut trouver l’équilibre.

Peut-on arriver à écrire de bonnes règles?
L’un des risques est que les utilisateurs se servent du prétexte Jrules pour ne pas spécifier précisément leur besoin, ça se traduit dans les documents de spécifications par des phrases du type “sera traité par des règles Jrules.” dès que ça devient un peu compliqué. C’est une recette pour une catastrophe.

Je pense qu’il est possible d’atteindre l’objectif initial: “permettre aux utilisateurs de modifier leurs règles sans intervention du service informatique”. Mais uniquement si les utilisateurs maîtrisent extrêmement bien leur domaine fonctionnel. Ils doivent être capable de définir entre quelle borne et quelle borne leurs règles métiers vont varier. C’est à cette seule condition qu’on peut définir un BOM solide qui permettra d’écrire des règles en langage naturel qui seront facilement modifiables.

=> La phase d’analyse et de modélisation est capitale, encore plus que pour un projet traditionnel.
=> La phase de définition du BOM ne l’est pas moins. C’est là ou réside en plus du coût des licences le surcoût d’un projet Jrules.

Peut-on faire des économies avec un moteur de règles?
On peut donc modifier des règles ou en ajouter facilement mais uniquement dans la limite de ce qui a été prévu. Si vous désirez ajouter des données il faut mettre à jour le modèle objet donc le BOM ce qui a parfois tendance à caser les règles existantes. De toute façon vous êtes bon pour repasser par la casse équipe informatique… Adieu les économies.

L’utilisation d’un moteur de règles ne dispense d’aucune des tâches d’un développement classique par contre on trouve en plus la phase de définition du BOM qu’il ne faut pas sous-estimer. La phase de développement initial est donc forcément plus coûteuse avec Jrules que sans. Le ROI ne vient qu’après avoir modifié de nombreuses fois les règles sans faire appel au service informatique.
J’ai pu constater que même après une semaine de formation il est difficile de s’en sortir dès que l’on sort des cas standards sans l’aide des consultants d’Ilog heureusement ceux avec qui j’ai travaillé était très compétent.
Un autre problème est la question du débugguage des règles. Bien que le produit d’Ilog fournisse des outils pour le débugguage ils sont très limités dès qu’il s’agit de travailler avec un modèle un tan soit peu conséquent. Nous avons été obligé de réaliser des développements spécifiques pour pouvoir tester et débuguer les règles dans de bonnes conditions.

Les performances?
C’est l’une des questions qui revient souvent à propos des moteurs de règle, qu’en est-il des performances? En fait il y a rarement de problème de performance provenant directement du moteur de règles. Celui de Jrules implémente l’algorithme Rete qui lui évite d’exécuter toutes les règles à chaque fois. C’est à ce jour la meilleure optimisation connue pour ce type de problème et elle semble donner satisfaction. Et l’on peut toujours aider le moteur en lui indiquant dans quel ordre il doit éxécuter les régles pour éliminer le plus grand nombre de cas dès le départ.

Mais utiliser un moteur de règles ne nous affranchi pas des problèmes de performance classique que l’on rencontre dans toute application. En premier lieu le problème de l’accès aux données. Jrules est très très orienté objet, lors de l’exécution des règles le graphe objet peut être parcouru de manière intense… Comme les données sont souvent stockée dans des bases de données relationnel le problème du mapping objet/relationnel, “l’impedance mismatch” peut devenir très important.

Les alternatives?
En discutant avec d’autres personnes utilisant ou souhaitant utiliser un moteur de règle on constate que bien souvent ce ne seront pas les utilisateurs fonctionnels qui modifieront les règles mais bien les équipes informatiques. Dans ce cas utiliser un langage de script tel que jruby ou jpython apportera les mêmes bénéfices que Jrules en terme de souplesse sans les inconvénients (définition du BOM par exemple). Par contre avec une telle solution on ne bénéficie pas des avantages de l’utilisation de l’algorithme Rete, à moins de le recoder soit même…

Il existe d’ailleurs un produit open source qui fait cela: Drools. Je ne le connais pas, si quelqu’un à un avis?

Conclusions
Les promesses de Jrules ne sont pas impossible à atteindre mais les conditions pour y parvenir me semblent difficiles à réunir. (non non je ne fairais aucun lien vers un dessin de Dilbert!!)

Si vous voulez creuser un peu la question des moteurs de règles je vous recommande ce rapport:

Service Oriented Business Rules Management Systems.

Ainsi que ces animations pour comprendre la magie de l’algorithme Rete.

RIALTO Rich Internet Application Toolkit

J’allais publier ce billet au moment du crash de blogs.a19s.com… Mais il reste d’actualité.

Rialto avait été présenté en avant première lors du Symposium DNG, depuis quelques jours tout le monde peut baver sur la démo en ligne et télécharger le code source.

Rialto est un framework javascript indépendant de la technologie côté serveur. Il permet de mettre à jour une partie de la page sans la recharger en entier (à la gmail, Ajax…). Il est destiné à la création d’application de gestion et est disponible sous la licence apache 2.0.

Vous allez me dire encore un framework Ajax, c’est à la mode en ce moment. Il n’y qu’à voir la liste des frameworks Ajax existant. Personnellement je pense que ces solutions de type ajax représentent le futur des applications de gestion. Si vous développez des applications de gestion vous avez déjà du faire face à cette situation: un client qui souhaite que vous portiez en client léger (web) une application client lourd. Et là il faut lui expliquer que ce n’est pas forcément possible… Normal, à la base le web a été conçu pour accéder à des ressources statiques à l’aide de liens hypertextes. Tout le reste, tout ce que l’on fait avec le client léger c’est du patch, des utilisations détournées du protocole http et du langage html. Le meilleur exemple étant la problématique du rechargement entier de la page alors que 90% des cas d’utilisation d’une application de gestion ne demande que la mise à jour d’une petite partie de la page. La solution des iframes cachées ou de xmlhttprequest existe depuis longtemps mais peu de personnes faisaient confiance à ce type de solution. Sans doute à juste titre: maintenir du javascript est un cauchemar. Pourtant avec gmail ou maps, google a démontré l’intérêt et la viabilité de ce type de solution. Ok tout le monde n’est pas google, mais je considère que le concept de Single page interface (SPI) qui repose sur l’utilisation de requête asynchrones et la non mise à jour de toute la page est un pas dans la bonne direction pour les applications de gestion.

Au milieu de tous ces frameworks Ajax pourquoi Rialto retient-il plus particulièrement mon attention qu’un autre projet?
Si vous ne l’avez pas déjà fait, visitez la démo de rialto. Elle répond parfaitement et uniquement aux problématiques que l’on rencontre dans des applications de gestion. Remplir un formulaire, faire une recherche, parcourir une liste paginées, utiliser des tabulations. Bref on sent que ce framework répond à un vrai besoin utilisateur. Il n’existe pas juste pour faire “web2.0”. Derrière il y a des utilisateurs avec des besoins et une équipe de développement qui y a répondu sans chercher à aller plus loin. En général c’est en cherchant à répondre à plus que le besoin initial que les framework deviennent des usines à gaz.

Reste malgré tout le problème de la maintenance du javascript et de la maintenance d’un framework tout court. En allant d’un client à l’autre on découvre toute sorte de frameworks “maison”: couche de présentation, moteur transactionnel et le fin du fin: le moteur de persistance mappeur objet/relationnel… La plupart du temps ces frameworks sont mauvais, parfois correct, rarement bon et jamais à la hauteur de leur équivalent open-source. Mais surtout ils sont une calamité à maintenir et il est impossible de trouver des personnes extérieures à la société ayant de l’expérience avec ces frameworks. Par rapport à ce problème je trouve la démarche de l’IGR (qui est à l’origine de rialto) excellente. Ils ont un bon framework développé en interne. En l’ouvrant à la communauté open source ils font dans un premier temps un joli cadeau et dans un 2eme temps si l’ouverture du projet est un succès ils ont une chance de régler ce problème de maintenance et de compétences.

Le chemin pour que ce projet réussisse est sans doute encore long:
– Quelle courbe d’apprentissage pour se l’approprier en tant qu’utilisateur?
– Et en tant que contributeur?
– La documentation sera t’elle à la hauteur? C’est un point capital dans la réussite d’un projet open source.
– Quelle facilité pour changer le look, “skinner” une application?
 Et au final quelle sera la “vigueur” de la communauté qui émergera autour du projet?

En tout cas la mailing list de Rialto commence à s’animer et plus de 140 personnes ont taggé rialto dans del.icio.us .