Commentaires sur : CITCON Paris 2009 http://blog.xebia.fr/2009/09/21/citcon-paris-2009/ J2EE, Agilité et SOA Thu, 09 Feb 2012 15:43:24 +0000 hourly 1 http://wordpress.org/?v= Par : Bobhttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15266 Bob Tue, 22 Sep 2009 13:35:56 +0000 http://blog.xebia.fr/?p=2865#comment-15266 Emmanuel, pour répondre à ta question, tu peux te reporter à http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperProgrammers.html#sc_ZooKeeperAccessControl Encore une fois, je n'essaye pas de "vendre" cette solution car je n'ai pas de retour d'expérience sur le sujet. Mais le concept me semble intéressant. Emmanuel, pour répondre à ta question, tu peux te reporter à http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperProgrammers.html#sc_ZooKeeperAccessControl

Encore une fois, je n’essaye pas de « vendre » cette solution car je n’ai pas de retour d’expérience sur le sujet. Mais le concept me semble intéressant.

]]> Par : Emmanuel Serventhttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15257 Emmanuel Servent Tue, 22 Sep 2009 09:02:15 +0000 http://blog.xebia.fr/?p=2865#comment-15257 Effectivement, je n'ai pas tellement insisté sur ce point, mais l'avantage d'Escape (et de Zookeeper !) est de centraliser toutes les valeurs des propriétés à l'extérieur des applications. On peut évidememnt les partager entre plusieurs d'entre elles, mais rien ne l'y oblige. Bob, je suis d'accord avec toi sur les faiblesses d'architecture d'Escape comparé à Zookeeper, mais le besoin n'est pas exactement le même. Escape ne nécessite pas une architecture aussi complexe, car il est surtout utilisé au démarrage des applications et peu en cours d'utilisation. D'autre part, son point fort, pour moi, c'est sa simplicité de mise en oeuvre. ZooKeeper est plus complexe, il propose, par exemple, une fonctionnalité de notifications de changement d'une valeur. Ca va beaucoup plus loin qu'un simple CMDB. Et l'autre point important, c'est la protection et l'encryption des données. Je n'ai pas lu que ZooKeeper sécurisait ses données. Est-ce le cas? De mon point de vue, on ne peut pas considérer ZooKeeper comme un CMDB, ce n'est pas sa fonction principale alors qu'Escape se positionne complètement dans ce rôle. Effectivement, je n’ai pas tellement insisté sur ce point, mais l’avantage d’Escape (et de Zookeeper !) est de centraliser toutes les valeurs des propriétés à l’extérieur des applications. On peut évidememnt les partager entre plusieurs d’entre elles, mais rien ne l’y oblige.

Bob, je suis d’accord avec toi sur les faiblesses d’architecture d’Escape comparé à Zookeeper, mais le besoin n’est pas exactement le même. Escape ne nécessite pas une architecture aussi complexe, car il est surtout utilisé au démarrage des applications et peu en cours d’utilisation.

D’autre part, son point fort, pour moi, c’est sa simplicité de mise en oeuvre. ZooKeeper est plus complexe, il propose, par exemple, une fonctionnalité de notifications de changement d’une valeur. Ca va beaucoup plus loin qu’un simple CMDB.
Et l’autre point important, c’est la protection et l’encryption des données. Je n’ai pas lu que ZooKeeper sécurisait ses données. Est-ce le cas?

De mon point de vue, on ne peut pas considérer ZooKeeper comme un CMDB, ce n’est pas sa fonction principale alors qu’Escape se positionne complètement dans ce rôle.

]]> Par : Frédérichttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15250 Frédéric Tue, 22 Sep 2009 07:26:34 +0000 http://blog.xebia.fr/?p=2865#comment-15250 Dac je saisis mieux la problématique => je suis à coté avec le pattern évoqué précédemment ;-) Dac je saisis mieux la problématique => je suis à coté avec le pattern évoqué précédemment ;-)

]]> Par : Bobhttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15247 Bob Tue, 22 Sep 2009 06:38:17 +0000 http://blog.xebia.fr/?p=2865#comment-15247 Zookeeper présente un intérêt dans un environnement où plusieurs centaines d'applications partagent certaines propriétés communes (comme une adresse IP) que l'on veut pouvoir gérer de façon centralisée, puis pouvoir propager la configuration sur chacun des serveurs sans intervention manuelle. Evidemment, Zookeeper ne s'adresse pas à une problématique dans laquelle seules quelques applications sont en jeu. Zookeeper présente un intérêt dans un environnement où plusieurs centaines d’applications partagent certaines propriétés communes (comme une adresse IP) que l’on veut pouvoir gérer de façon centralisée, puis pouvoir propager la configuration sur chacun des serveurs sans intervention manuelle.

Evidemment, Zookeeper ne s’adresse pas à une problématique dans laquelle seules quelques applications sont en jeu.

]]> Par : Frédérichttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15236 Frédéric Mon, 21 Sep 2009 20:46:55 +0000 http://blog.xebia.fr/?p=2865#comment-15236 Ces deux solutions (Escape et Zookeeper) me paraissent bien compliquées pour répondre à une problématique pourtant simple : "des valeurs de propriétés pour des environnements différents" Sur le projet liferay, un pattern très pratique est mis en place : le "chaînage" de fichiers properties. Le principe est simple : ils utilisent un PropertiesPlaceHolder (spring ... mais le principe n'a pas besoin de se reposer sur spring) maison qui va charger un fichier properties. Si, dans ce fichier, il trouve une clef "magique" (ex: "include-and-override"), il tentera de charger le fichier pointé par cette clef dans le classpath et mergera son contenu avec les propriétés déjà chargées (et ainsi de suite..) Exemple : Fichier exemple.default.properties -déclaré systématiquement dans le classpath : contient la configuration "par défaut" de l'appli- include-and-override=exemple.recette.properties log.level=INFO Fichier exemple.recette.properties -à rajouter lors du packaging de recette, contiendra la conf de recette- include-and-override=exemple.prod.properties log.level=DEBUG Fichier exemple.prod.properties -à rajouter lors du packaging de prod, en plus du exemple.recette.properties ci-dessus- log.level=ERROR Lorsque le développeur récupère ce qu'il y a sur le référentiel, "out of the box" le niveau de log est en INFO. Eventuellement il peut customiser son niveau de log en DEBUG en rajoutant (sans le commiter) un exemple.recette.properties dans son classpath En recette, exemple.default.properties et exemple.recette.properties sont packagés pour un log "final" en DEBUG Enfin, pour la prod, exemple.default.properties, exemple.recette.properties et exemple.prod.properties sont packagés pour un log final en ERROR => Qu'en pensez-vous ? Frédéric Ces deux solutions (Escape et Zookeeper) me paraissent bien compliquées pour répondre à une problématique pourtant simple : « des valeurs de propriétés pour des environnements différents »

Sur le projet liferay, un pattern très pratique est mis en place : le « chaînage » de fichiers properties.

Le principe est simple : ils utilisent un PropertiesPlaceHolder (spring … mais le principe n’a pas besoin de se reposer sur spring) maison qui va charger un fichier properties.
Si, dans ce fichier, il trouve une clef « magique » (ex: « include-and-override »), il tentera de charger le fichier pointé par cette clef dans le classpath et mergera son contenu avec les propriétés déjà chargées (et ainsi de suite..)

Exemple :
Fichier exemple.default.properties -déclaré systématiquement dans le classpath : contient la configuration « par défaut » de l’appli-
include-and-override=exemple.recette.properties
log.level=INFO

Fichier exemple.recette.properties -à rajouter lors du packaging de recette, contiendra la conf de recette-
include-and-override=exemple.prod.properties
log.level=DEBUG

Fichier exemple.prod.properties -à rajouter lors du packaging de prod, en plus du exemple.recette.properties ci-dessus-
log.level=ERROR

Lorsque le développeur récupère ce qu’il y a sur le référentiel, « out of the box » le niveau de log est en INFO.
Eventuellement il peut customiser son niveau de log en DEBUG en rajoutant (sans le commiter) un exemple.recette.properties dans son classpath

En recette, exemple.default.properties et exemple.recette.properties sont packagés pour un log « final » en DEBUG
Enfin, pour la prod, exemple.default.properties, exemple.recette.properties et exemple.prod.properties sont packagés pour un log final en ERROR

=> Qu’en pensez-vous ?

Frédéric

]]> Par : Bobhttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15230 Bob Mon, 21 Sep 2009 19:28:10 +0000 http://blog.xebia.fr/?p=2865#comment-15230 Escape me laisse tout à fait perplexe, il me semble qu'il a tout d'un bon candidat pour être le point de faiblesse d'une architecture (single point of failure). Dans ma boîte, nous regardons avec attention Zookeeper (http://hadoop.apache.org/zookeeper/) qui a les mêmes avantages de centralisation de Escape, mais avec en plus la FIABILITE. Je n'ai pas encore de retour du terrain de la part de Zookeeper, mais il est sûr que Escape ne fait pas un bon candidat. ThoughtWorks nous avait habitué à mieux. Escape me laisse tout à fait perplexe, il me semble qu’il a tout d’un bon candidat pour être le point de faiblesse d’une architecture (single point of failure). Dans ma boîte, nous regardons avec attention Zookeeper (http://hadoop.apache.org/zookeeper/) qui a les mêmes avantages de centralisation de Escape, mais avec en plus la FIABILITE.

Je n’ai pas encore de retour du terrain de la part de Zookeeper, mais il est sûr que Escape ne fait pas un bon candidat. ThoughtWorks nous avait habitué à mieux.

]]> Par : Dominique De Vitohttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15223 Dominique De Vito Mon, 21 Sep 2009 15:35:36 +0000 http://blog.xebia.fr/?p=2865#comment-15223 OK, merci de la précision. Intéressant. Cela rejoint (un peu) mon idée, modulo l'accès web/REST. OK, merci de la précision. Intéressant.

Cela rejoint (un peu) mon idée, modulo l’accès web/REST.

]]> Par : Emmanuel Serventhttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15222 Emmanuel Servent Mon, 21 Sep 2009 14:56:21 +0000 http://blog.xebia.fr/?p=2865#comment-15222 La présentation d'Escape a pris le cas de l'initialisation des variables au niveau applicatif, ie lorsque l'application démarre ou lors de la première utilisation de la propriété. Mais on peut très bien envisager de récupérer les valeurs avant le packaging et de les stocker directement dans les fichiers de propriétés. Avec la commande _curl_ sous Unix, on peut retrouver une valeur sans pour autant être dans du code Java, Python ou autres. Les auteurs du produit ne le limitent pas à un rôle donné. Escape ne fait que servir une information à la demande et c'est plutôt au projet de choisir à quel moment on veut l'interroger. La présentation d’Escape a pris le cas de l’initialisation des variables au niveau applicatif, ie lorsque l’application démarre ou lors de la première utilisation de la propriété.
Mais on peut très bien envisager de récupérer les valeurs avant le packaging et de les stocker directement dans les fichiers de propriétés. Avec la commande _curl_ sous Unix, on peut retrouver une valeur sans pour autant être dans du code Java, Python ou autres.

Les auteurs du produit ne le limitent pas à un rôle donné. Escape ne fait que servir une information à la demande et c’est plutôt au projet de choisir à quel moment on veut l’interroger.

]]> Par : Dominique De Vitohttp://blog.xebia.fr/2009/09/21/citcon-paris-2009/#comment-15220 Dominique De Vito Mon, 21 Sep 2009 13:54:29 +0000 http://blog.xebia.fr/?p=2865#comment-15220 Perso, au niveau applicatif, ma proposition pour stocker les propriétés utilisées par une application : utiliser une base de données orientée objet (qui peut avoir un accès web) : http://www.jroller.com/dmdevito/entry/and_now_something_completely_different Coté application, soit on lirait ces propriétés au vol, soit on les utiliserait pour initialiser une variable, statique par ex, soit l'initialisation sera rendue implicite via un binding par annotation Java. Cela ressemble un peu à ce qui est proposé là (sauf que j'ai du mal à identifier à quel stade Escape joue son rôle ? au niveau de la CI ? du packaging ? et/ou au niveau applicatif ?), modulo le fait que Escape propose un accès web/REST. Perso, au niveau applicatif, ma proposition pour stocker les propriétés utilisées par une application : utiliser une base de données orientée objet (qui peut avoir un accès web) : http://www.jroller.com/dmdevito/entry/and_now_something_completely_different

Coté application, soit on lirait ces propriétés au vol, soit on les utiliserait pour initialiser une variable, statique par ex, soit l’initialisation sera rendue implicite via un binding par annotation Java.

Cela ressemble un peu à ce qui est proposé là (sauf que j’ai du mal à identifier à quel stade Escape joue son rôle ? au niveau de la CI ? du packaging ? et/ou au niveau applicatif ?), modulo le fait que Escape propose un accès web/REST.

]]>