[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tsp-devel] JTSP : Quelques nouveautés
From: |
Stephane Galles |
Subject: |
[Tsp-devel] JTSP : Quelques nouveautés |
Date: |
Sun, 10 Apr 2005 02:14:04 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319 |
Bonjour,
le JCDFWriter n'est pas encore codé mais il a déjà fait quelques petits...
En fait, j'ai codé avant les quelques couches d'abstraction qui me manquait
pour faire le JCDFWriter, et tant qu'à faire, j'ai préféré coder ces couches
pour qu'elles soient réutilisables. C'est pour cela que le JCDFWriter en
tant que
tel n'est pas encore commencé :)
Donc, sont apparus dans le CVS JTSP depuis quelques jours :
1) - tsp/core/consumer/simple : L'API consumer Simple
2) - tsp/consumer/util/aggregator : Une API consumer Aggregator
s'appuyant sur (1)
3) - tsp/util/xml/objmapper : des routines générique de chargement
d'objet à partir de fichiers XML
4) - tsp/consumer/util/configuration : Une 1er implémentation du
chargement des
fichiers XML de sampling s'appuyant sur (3)
5) - tsp/consumer/util/configuration/decorator : Une surcouche à (4)
pour aider au chargement
des config de sampling pour initialiser (2)
Je vais détailler tout cela, mais je tiens à dire déjà que si les choix
des package ne conviennent pas,
tout cela est évidemment modifiable à volonté.
1) tsp/core/consumer/simple : L'API consumer Simple
On en a déjà parlé. C'est une surcouche de l'API "Spec TSP" développée
par Eric
2) - tsp/consumer/util/aggregator : Une API consumer Aggregator
s'appuyant sur (1)
C'est une surcouche de l'API simple. Je l'ai développé car suite à nos
discussions, il
semblait intéressant de développer un JCDFWriter multiprovider. Le
besoin semblait
générique. Néanmoins, comme décidé, l'aggregation ne tente pas de
synchroniser les
timestamp. La seule manipulation que l'API fait est qu'elle fournie à 0 les
timestamp de tous les providers su début du sampling, et aprés elle
laisse les timestamp
vivre leur vie.
L'API aggregator, propose en fait un Consumer Aggregator. On peut
l'initialiser avec une liste
d'URL. Par URL on doit également lui préciser un namespace.
Lorsque une session est ouverte sur un consumer Aggregator, plusieurs
sessions sont ouvertes sur
les URL initialement fournies.
Si le client demande la liste des symboles gérés, l'API Aggregator
renvoie une liste
qui est la somme de toutes les listes des symboles de tous les
providers. Une manipulation est faite
sur le nom des symboles pour ajouter les namespace fournis avec les URL,
de plus les index
sont manipulés à la vollée pour pourvoir gérer une liste unifiée.
En pratique, si j'ouvre avec l'API Aggregator :
URL1=//Host1/ NAMESPACE1=Stub1, qui gére les symboles aaa et bbb
URL1=//Host2/ NAMESPACE1=Stub2, qui gère les symboles ccc et ddd
Via l'API aggregator, on a l'impression de voir un seul provider qui
gére les symboles
Stub1::aaa
Stub1::bbb
Stub2::ccc
Stub2::ddd
Vous voyez le principe. Cerise sur le gateau, Les classes Consumer et
Session Aggregator
implémentent les même interfaces que l'API Simple. En pratique, cela
signifie qu'un
consumer ecrit pour l'API Simple fonctionne sans modification, ou trés
peu, pour l'API
Aggregator
Deuxième cerise sur le gateau, on peut initialiser un consumer
Aggregator, à partir de consumer
Simple déjà instanciés (et non plus à partir des URL). De coup, je ne
sais pas si cela sert à
quelque chose, mais on peut théoriquement initialiser un consumer
Aggregator à partir
d'autres consumers Aggregator, puisque un consumer Aggregator est
également un consumer Simple
(vous êtes toujours avec moi ?).
Je n'ai pas encore écrit de consumer qui utilise cette API, pour
l'instant je n'ai que les tests unitaires
qui utilisent des MockObjects, mais je pense qu'elle est prête pour le
JCDFWriter !
3) - tsp/util/xml/objmapper : des routines générique de chargement
d'objet à partir de fichiers XML
C'est un framework de 2 ou 3 classes qui permet à peu de frais de mapper
nimporte quel fichier XML à nimporte
quel structure de donnés, via un parser SAX, et cela donne du code de
mapping qui reste maintenable
4) - tsp/consumer/util/configuration : Une 1er implémentation du
chargement des fichiers XML de
sampling s'appuyant sur (3)
J'ai pris l'exemple de config de sampling XML d'Eric et je l'ai
implementé tel quel via (3)
Je sait que le format du fichier va changer, mais pour l'instant c'était
déjà trés utilisable et je voulais
une vrai conf pour le JCDFWriter
A noter que j'ai placé dans src/tsp/provider/app/stub un fichier de
config XML d'exemple pour
sampler quelques symboles du stub_server C. L'idée est que ce fichier
XML sera embarqué dans
le jtsp-tools.jar et comme le code de (3) sait aller chercher des XML de
conf dans le classpath, pour une demonstration
du JCDFWriter avec le stub_server, il suffira de donner le chemin de
conf suivant :
classpath:/tsp/provider/app/stub/stub_sampling_exemple.xml
et hop le JCDFWriter démarrera avec la conf d'exemple fournie dans le
jar sans fichier XML
externe à distribuer
5) - tsp/consumer/util/configuration/decorator : Une surcouche à (4)
pour aider au chargement
des config de sampling pour initialiser (2)
Les structure de données de l'API de chargement des conf XML sont propre
à cette API et n'utilise
pas, volontairement, les structure TSP, Donc j'ai fait une API toute
simple qui permet de directement
produire les structures nécessaires à l'initialisation de l'API
Aggregator (il manque celle de l'API Simple,
mais je pense que cela peut être la même).De plus, le chargement des
symboles du fichier de conf de sampling
se fait en ajoutant le nom du provider en tant que namespace
Voila. Les morceaux sont là. Il ne me reste plus qu'à les coller pour
faire le JCDFWriter. Tres bientot.
A noter que toutes ces parties sont trés fortemement découplées. En
particulier, on peut modifier
sans problèmes l'API consumer n-1, ainsi que la conf XML de sampling,
les modif ne remonterons pas
trés haut. On peut même utiliser JTSP comme laboratoire pour affiner la
conf de sampling XML
avant de l'utiliser pour la partie C (modifier le mapping en Java se
fera toujours plus rapidement
qu'en C)
Ces développement m'ont ammené à me poser deux questions sur la spec TSP
- Dans le cas de l 'API Aggregator, comme les time_stamp des divers
providers
ne sont pas synchronisés,il y a de fortes chances que du point de vue du
client
de l'API, les timestamp des TspSamples qui sont récupérés jouent les
montagnes
russes, genre : 0, 0, 0, 1, 0 , 1, 2, 1, 1, 1, 1, 2, 1, 2, 3, 3, 2, 3,
3, 4 .... est ce que du point de vue de la
spec c'est un problème ? Est ce qu'un client de l'API consumer doit
savoir gérer cela ? (le JCDFWriter
le gérera bien sur, mais c'est pour savoir si la spec dit quelque chose
la dessus).
- Ou en est la modification du provider C que Eric voulait faire pour
gérer le cas ou des symboles sont demandés,
mais ou certains n'existent pas, et pour savoir quel étaient les
symboles erronés ? C'est juste pour
savoir comment le JCDFWriter devra réagir si le problème se pose.
Merci
Steph
- [Tsp-devel] JTSP : Quelques nouveautés,
Stephane Galles <=