Merci à toi. Toute contribution est la bienvenue d'autant qu'Il n'est pas necessaire de connaitre toutes les fonctionnalités du framework et de maîtriser l'AOP pour apporter quelquechose à la plate-forme. Il suffit d'avoir l'idée d'un bean utile et de vouloir le partager.
Cordialement.
Si je comprends bien, ce concept de bean permet (à la manière de Spring, désolé si je me répète mais c'est à peu près tout ce que je connait en la matière :) ) de rendre disponible un objet pour d'autres objets ? Apporte t'il quelque chose en plus ? De plus, tu fais référence aux EJB, JDO et hibernate, peut on les intégrer facilement ? »
Spring n'a inventé ni le bean ni l'AOP, personnellement je me suis initié à l'AOP avec le très bon livre de Renaud Pawlak , Jean-Philippe Retaillé & Lionel Seinturier : Programmation orientée aspect pour Java / J2EE.
N'ayant jamais utilisé Spring, je peux pas te faire une comparaison exhaustive des différences, car de mon point de vue, il n'apporte rien de nouveau (cependant j'avoue mon ignorance sur le sujet)
J'espère que parmi nos lecteurs ceux connaissant les deux environnements, pourront donner leur avis sur les avantages et inconvénients de chacun (de façon argumenté, pas de troll SVP) .
Mon but ici, n'est pas de démontrer la supériorité d'une approche par rapport à une autre, mais de proposer une alternative au développeur afin de l'amener à confronter les approches, à se poser les bonnes questions et enfin à éclairer d'un autre jour ses connaissances en programmation .
Nous avons un composant Hibernate fourni avec le framework permettant de récupérer une session. Nous avons fait des tests concluants de mise a jour de base de donné il y a plus d'un an, mais le bean est un peu en stand-by car nous n'avons pas les ressources suffisantes pour mener tous les projets de front. C'est pour cela que nous recherchons des contributeurs, y compris pour reprendre le projet/bean hibernate.... à bon entendeur....
Enfin, rien n'empêche les concepteurs de bean Azuki d'utiliser Spring au sein de leur composants (même si cela peut paraître bizzare). Ils peuvent ainsi utiliser Spring pour l'IoC ou l'integration avec les autres API et profiter egalement du framework Azuki (par exemple : la gestion avancé des threads et les evenements).
« Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup ! »
Tout a fait d'accord :-) Surtout que dans la réalité, le code AOP ne constitue qu'un minorité du code généré pour une application et l'on ne doit pas forcer l'ensemble des développeurs à maîtriser des concepts qui leur sont inutiles pour développer leur business service.
ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
Tout à fait, cela est paramétrable via le weaver (ou directement dans le fichier de config azuki.xml)
« Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ). »
C'est plus simple dans le sens que nous souhaitons que l'intégrateur ne s'occupe pas de l'implémentation du code mais seulement de la documentation et des annotations fourni avec les composants pour réaliser son tissage. Notre approche est que le composant doit rester une boite noire.
« Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;) »
Par exemple : Un composant peu initier deux traitements qui s'exécutent en parallèle, suite à la génération d'un événement par exemple. Le framework permet de créer un point de synchronisation, CaD de ne lancer l'exécution d'une troisième méthode que lorsque les deux précédentes sont terminées.
La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
Encore une fois, rien ne t'empêche de continuer à utiliser Spring avec Azuki.
« PS: hors sujet, mais quelqu'un connaîtrait il un bon framework javascript en remplacement de dojo ? »
Nous utilisons pour nos dev une librairie basé sur GWT de google. Notre lib apporte quelques fonctions supplémentaires comme la gestion des Datasets et des tableaux de données coté client. Elle sera fournie à la rentrée (octobre?) avec la version 1.1 d'Azuki --> pas si hors sujet que cela ! :-)
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 ...
Les différences sont nombreuses, mais les points les plus importants :
- Une approche pragmatique et simple de la programmation avec des composants considérés comme des services et non des entités.
- L'encapsulation de toutes les fonctions du composant (code s'executant sur le serveur, éditeur de paramètre, fichier d'aide , monitoring...) au sein d'une même archive re-livrable, tel un plug-in.
- Une gestion intégré et évolué du pool de thread et des queues de traitements sur l'acces au composant.
- La programmation événementielle
- etc ... (j'en passe).
Certes, je ne connais pas très bien Spring et sans doute est-il possible d'arriver au même résultat, mais certainement pas avec la même facilité : il faut essayer l'exemple du tutoriel pour bien s'en rendre compte.
Pour ne considèrer que l'AOP et l'injection de dépendance, ce qui frappe le plus par rapport à Spring c'est la simplicité du tissage qui se fait par simple glisser-déposer dans l'éditeur graphique a comparer avec le fichier de config XML de l'IoC de Spring...
[^] # Re: Reponses
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 1.
Cordialement.
[^] # Atari ST ..
Posté par Robert Bakic . En réponse au journal La fin de Thunderbird ?. Évalué à 6.
[^] # Re: Reponses
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 5.
Spring n'a inventé ni le bean ni l'AOP, personnellement je me suis initié à l'AOP avec le très bon livre de Renaud Pawlak , Jean-Philippe Retaillé & Lionel Seinturier : Programmation orientée aspect pour Java / J2EE.
N'ayant jamais utilisé Spring, je peux pas te faire une comparaison exhaustive des différences, car de mon point de vue, il n'apporte rien de nouveau (cependant j'avoue mon ignorance sur le sujet)
J'espère que parmi nos lecteurs ceux connaissant les deux environnements, pourront donner leur avis sur les avantages et inconvénients de chacun (de façon argumenté, pas de troll SVP) .
Mon but ici, n'est pas de démontrer la supériorité d'une approche par rapport à une autre, mais de proposer une alternative au développeur afin de l'amener à confronter les approches, à se poser les bonnes questions et enfin à éclairer d'un autre jour ses connaissances en programmation .
Nous avons un composant Hibernate fourni avec le framework permettant de récupérer une session. Nous avons fait des tests concluants de mise a jour de base de donné il y a plus d'un an, mais le bean est un peu en stand-by car nous n'avons pas les ressources suffisantes pour mener tous les projets de front. C'est pour cela que nous recherchons des contributeurs, y compris pour reprendre le projet/bean hibernate.... à bon entendeur....
Enfin, rien n'empêche les concepteurs de bean Azuki d'utiliser Spring au sein de leur composants (même si cela peut paraître bizzare). Ils peuvent ainsi utiliser Spring pour l'IoC ou l'integration avec les autres API et profiter egalement du framework Azuki (par exemple : la gestion avancé des threads et les evenements).
« Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup ! »
Tout a fait d'accord :-) Surtout que dans la réalité, le code AOP ne constitue qu'un minorité du code généré pour une application et l'on ne doit pas forcer l'ensemble des développeurs à maîtriser des concepts qui leur sont inutiles pour développer leur business service.
ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
Tout à fait, cela est paramétrable via le weaver (ou directement dans le fichier de config azuki.xml)
« Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ). »
C'est plus simple dans le sens que nous souhaitons que l'intégrateur ne s'occupe pas de l'implémentation du code mais seulement de la documentation et des annotations fourni avec les composants pour réaliser son tissage. Notre approche est que le composant doit rester une boite noire.
« Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;) »
Par exemple : Un composant peu initier deux traitements qui s'exécutent en parallèle, suite à la génération d'un événement par exemple. Le framework permet de créer un point de synchronisation, CaD de ne lancer l'exécution d'une troisième méthode que lorsque les deux précédentes sont terminées.
La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
Encore une fois, rien ne t'empêche de continuer à utiliser Spring avec Azuki.
« PS: hors sujet, mais quelqu'un connaîtrait il un bon framework javascript en remplacement de dojo ? »
Nous utilisons pour nos dev une librairie basé sur GWT de google. Notre lib apporte quelques fonctions supplémentaires comme la gestion des Datasets et des tableaux de données coté client. Elle sera fournie à la rentrée (octobre?) avec la version 1.1 d'Azuki --> pas si hors sujet que cela ! :-)
[^] # Re: Spring
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 1.
L'AOP ne pose de pb de maintenance dans Azuki car le code n'est pas intrusif, l'AOP est effectué à l'aide de design-pattern très simple a appréhender.
Je connais pas la Qt est donc ne peux te répondre.
[^] # 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.
[^] # Re: Spring
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 2.
- Une approche pragmatique et simple de la programmation avec des composants considérés comme des services et non des entités.
- L'encapsulation de toutes les fonctions du composant (code s'executant sur le serveur, éditeur de paramètre, fichier d'aide , monitoring...) au sein d'une même archive re-livrable, tel un plug-in.
- Une gestion intégré et évolué du pool de thread et des queues de traitements sur l'acces au composant.
- La programmation événementielle
- etc ... (j'en passe).
Certes, je ne connais pas très bien Spring et sans doute est-il possible d'arriver au même résultat, mais certainement pas avec la même facilité : il faut essayer l'exemple du tutoriel pour bien s'en rendre compte.
Pour ne considèrer que l'AOP et l'injection de dépendance, ce qui frappe le plus par rapport à Spring c'est la simplicité du tissage qui se fait par simple glisser-déposer dans l'éditeur graphique a comparer avec le fichier de config XML de l'IoC de Spring...