[Tsp-devel] JTSP : Quelques nouveautés

[Stephane Galles]

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