Je ne comprend pas trop ce que tu entends par : des composants considérés comme des services et non des entités
Les Azuki bean ne sont pas destinés à encapsuler les données de la base de donnée (comme pour JDO, EJB entity et hibernate) mais simplement du code procédurale
qui peut être considéré comme un service, en ce sens que le code est generalement thread-safe et que les attributs du bean servent uniquement à son parametrage lors de son initialization.
Je ne suis pas particulièrement fan de spring, mais je trouve la config xml particulièrement bien foutue : je ne la troquerai certainement pas pour une interface graphique faisant la même chose.
A chacun sa methode. l'interface graphique ne fait que renseigner un fichier de config XML. L'utilsateur d'Azuki à le choix de modifier le fichier de tissage "manuellement" si il le souhaite.
L'utilisation de l'interface graphique permet de controler l'integrité du fichier de tissage et de fournir une aide à ceux qui ne maitrise pas encore parfaitement la notion de pointcut et d'aspect.
Ses differentes vues permettent de s'abstraire du fichier de tissage en donnant une vue d'ensemble de la structure de l'application.
Je crois que j'ai pas compris grand chose aux principes d'Azuki (faut dire j'ai pas tout lu), mais grosso modo quand est il intéressant de l'utiliser ?
Le framework est surtout destiné à créer des applications contenant un volume de code conséquent (par exemple un PGI) necessitant des adaptations fréquentes
et l'ajout de code spécifiques chez le client. Le decoupage de l'application sous forme de composant permet de substituer un composant 'standard" de l'application
par un autre 'specifique" en isolant les developpements specifiques.
Les larges organisations, éditrices de logiciels et autres intégrateurs on des équipes dédiées aux compétences distinctes (SoC) :
* Des spécialistes techniques maitrisant parfaitement la plate-forme de dev.
* Des developpeurs un peu moins pointus mais connaissant le métier du client.
*Des équipes projets chargé de déployer l'application.
Ces personnes ne se cotoient pas réellement et, dans une approche "classique" de developpement, travaillent pourtant sur les mêmes fichiers avec le risque de modifier du code qu'ils maitrisent mal.
Dans l'approche Azuki, les spécialistes techniques travaillent sur leur propres beans qui sont pour la plupart de type "Aspect". Les developpeurs produit codent les beans de type "Business Service". Les équipes projets tissent l'application finale qui sera installée chez le client en remplaçant certain "Business Service" par des beans spécifiques ou encore en ajoutant des connecteurs (également conçu sous forme de bean) sur les points d'entrée et de sortie de l'application (cf prochaine réponse).
Le but avoué du framework est de permettre à l'équipe projet (ou intégration) de pouvoir assembler et parametrer l'application, pour un client, sans avoir à se pencher
sur le code des composants qui doivent, idéalement, être vu comme des boîtes noires.
De même pour la partie du framework orientée event : qu'apporte t'elle ?
La partie orientée evenement du framework sert a plusieurs choses :
- Definir des points d'entrées et de sorties dans l'application.
Par exemple, on peut imaginer que le composant qui gere la reception des commandes ai été conçu afin d'envoyer le numero de cette commande reçue sous la forme d'un évenement.
Cet evenement n'est pas traité dans l'application standard mais sert de point de sortie afin de permettre lors de l'installation chez un client d'ajouter une fonction spécifique comme l'envoi
immédiat d'un courriel au service livraison suite à la reception de cette commande. il suffit donc d'abonner le composant chargé de cette tâche à la reception de l'evenement pour pouvoir chainé
les deux actions sans avoir à modifié le code du premier composant (pour y ajouter une fonction d'envoie de mail par exemple).
- Traitements parallèles et asynchrones :
Le framework possède qui pool de thread qu'il utilise pour exécuter les méthodes des composants. Dans l'exemple précédent l'envoie du mail sera traiter par un second thread de façon asynchrone de façon totalement transparente pour les composants. Il n'y a donc pas de surcout en temps de traitement pour le composant gérant la reception de commande.
- Ferme de traitements
En couplant ces evenements à des connecteurs vers des brokers de messages (tel que ceux livré avec le framework), il est aisé de mettre en place une ferme de traitement en répartissant les traitements sur differents serveurs et cela juste en changeant le tissage de l'application à l'aide du weaver.
- Chaîner des traitements en créant des points de synchronisation.... etc...
Le concept de "Context Objects" est intéressant, mais est il réellement utile ?
Il est utile et nous l'utilisons dans nos propres developpements.
Par exemple nous gerons la transaction avec la base de données au travers du context d'execution, cela permet par exemple de definir la base de données de travail en
fonction du programme qui a invoqué la methode de notre composant.
On peut egalement stocker dans le context d'execution des variables ayant un "scope" propre au traitement effectué sans avoir à les passer en paramètre et sans avoir recours
au variables globales (problème de collision de nom). En outre, le fait de ne pas avoir à passer ces variables en paramètres simplifie la réutilisation des composants.
L'avantage de ces objets est que leur cycle de vie est géré par le framework. On peut même définir si un object sera hérité par une second thread lors d'un "fork" (lancement
d'un traitement asynchrone).
L'utilisation d'objets contextuels (propre au thread en cours d'execution) permet de rendre le code d'un composant thread-safe, ce qu'il ne pourrait être si on devait modifier
ses attributs.
Merci de bien vouloir éclairer ma modeste lanterne, j'aime beaucoup essayer de nouveaux frameworks mais la j'ai vraiment du mal à en saisir l'intérêt ...
[^] # Reponses
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 10.
Les Azuki bean ne sont pas destinés à encapsuler les données de la base de donnée (comme pour JDO, EJB entity et hibernate) mais simplement du code procédurale
qui peut être considéré comme un service, en ce sens que le code est generalement thread-safe et que les attributs du bean servent uniquement à son parametrage lors de son initialization.
Je ne suis pas particulièrement fan de spring, mais je trouve la config xml particulièrement bien foutue : je ne la troquerai certainement pas pour une interface graphique faisant la même chose.
A chacun sa methode. l'interface graphique ne fait que renseigner un fichier de config XML. L'utilsateur d'Azuki à le choix de modifier le fichier de tissage "manuellement" si il le souhaite.
L'utilisation de l'interface graphique permet de controler l'integrité du fichier de tissage et de fournir une aide à ceux qui ne maitrise pas encore parfaitement la notion de pointcut et d'aspect.
Ses differentes vues permettent de s'abstraire du fichier de tissage en donnant une vue d'ensemble de la structure de l'application.
Je crois que j'ai pas compris grand chose aux principes d'Azuki (faut dire j'ai pas tout lu), mais grosso modo quand est il intéressant de l'utiliser ?
Le framework est surtout destiné à créer des applications contenant un volume de code conséquent (par exemple un PGI) necessitant des adaptations fréquentes
et l'ajout de code spécifiques chez le client. Le decoupage de l'application sous forme de composant permet de substituer un composant 'standard" de l'application
par un autre 'specifique" en isolant les developpements specifiques.
Les larges organisations, éditrices de logiciels et autres intégrateurs on des équipes dédiées aux compétences distinctes (SoC) :
* Des spécialistes techniques maitrisant parfaitement la plate-forme de dev.
* Des developpeurs un peu moins pointus mais connaissant le métier du client.
*Des équipes projets chargé de déployer l'application.
Ces personnes ne se cotoient pas réellement et, dans une approche "classique" de developpement, travaillent pourtant sur les mêmes fichiers avec le risque de modifier du code qu'ils maitrisent mal.
Dans l'approche Azuki, les spécialistes techniques travaillent sur leur propres beans qui sont pour la plupart de type "Aspect". Les developpeurs produit codent les beans de type "Business Service". Les équipes projets tissent l'application finale qui sera installée chez le client en remplaçant certain "Business Service" par des beans spécifiques ou encore en ajoutant des connecteurs (également conçu sous forme de bean) sur les points d'entrée et de sortie de l'application (cf prochaine réponse).
Le but avoué du framework est de permettre à l'équipe projet (ou intégration) de pouvoir assembler et parametrer l'application, pour un client, sans avoir à se pencher
sur le code des composants qui doivent, idéalement, être vu comme des boîtes noires.
De même pour la partie du framework orientée event : qu'apporte t'elle ?
La partie orientée evenement du framework sert a plusieurs choses :
- Definir des points d'entrées et de sorties dans l'application.
Par exemple, on peut imaginer que le composant qui gere la reception des commandes ai été conçu afin d'envoyer le numero de cette commande reçue sous la forme d'un évenement.
Cet evenement n'est pas traité dans l'application standard mais sert de point de sortie afin de permettre lors de l'installation chez un client d'ajouter une fonction spécifique comme l'envoi
immédiat d'un courriel au service livraison suite à la reception de cette commande. il suffit donc d'abonner le composant chargé de cette tâche à la reception de l'evenement pour pouvoir chainé
les deux actions sans avoir à modifié le code du premier composant (pour y ajouter une fonction d'envoie de mail par exemple).
- Traitements parallèles et asynchrones :
Le framework possède qui pool de thread qu'il utilise pour exécuter les méthodes des composants. Dans l'exemple précédent l'envoie du mail sera traiter par un second thread de façon asynchrone de façon totalement transparente pour les composants. Il n'y a donc pas de surcout en temps de traitement pour le composant gérant la reception de commande.
- Ferme de traitements
En couplant ces evenements à des connecteurs vers des brokers de messages (tel que ceux livré avec le framework), il est aisé de mettre en place une ferme de traitement en répartissant les traitements sur differents serveurs et cela juste en changeant le tissage de l'application à l'aide du weaver.
- Chaîner des traitements en créant des points de synchronisation.... etc...
Le concept de "Context Objects" est intéressant, mais est il réellement utile ?
Il est utile et nous l'utilisons dans nos propres developpements.
Par exemple nous gerons la transaction avec la base de données au travers du context d'execution, cela permet par exemple de definir la base de données de travail en
fonction du programme qui a invoqué la methode de notre composant.
On peut egalement stocker dans le context d'execution des variables ayant un "scope" propre au traitement effectué sans avoir à les passer en paramètre et sans avoir recours
au variables globales (problème de collision de nom). En outre, le fait de ne pas avoir à passer ces variables en paramètres simplifie la réutilisation des composants.
L'avantage de ces objets est que leur cycle de vie est géré par le framework. On peut même définir si un object sera hérité par une second thread lors d'un "fork" (lancement
d'un traitement asynchrone).
L'utilisation d'objets contextuels (propre au thread en cours d'execution) permet de rendre le code d'un composant thread-safe, ce qu'il ne pourrait être si on devait modifier
ses attributs.
Merci de bien vouloir éclairer ma modeste lanterne, j'aime beaucoup essayer de nouveaux frameworks mais la j'ai vraiment du mal à en saisir l'intérêt ...
Merci à toi, pour ces questions pertinentes.