Re: [Tsp-devel] Sondage : vos idées pour un 'consumer-server Web TSP'

[NOULARD Eric]

Salut le Caribou(t en train),

Ben oui tu étais seul le Week-End dernier,
mais je sens que ma réponse va être mise en attente
jusque l'année prochaine donc...

Quoiqu'il en soit avant un départ non mérité pour passer
le 31-->1 à Chartres je donne mon avis à 2 euros avant
d'aller me coucher.

D'abord j'applaudis des 2 mains vus que dans ce que tu décris
un certain volume de boulot.

Côté pratique je rappelle qu'actuellement il n'y a dans
'jstp' que le côté consumer mais pour ton affaire ça
devrait suffir.

Le schéma que tu décris n'est pas débile du tout.
En revanche concernant l'utilisation de MySQL pour stocker le flux
effectivement reçu j'emmettrais certains doutes.
Personnellement je serais plutôt tenté de stocker un "vrai"
fichier dans un WebFolder (Microsoft) 
de l'utilisateur via les possibilités
WebDAV d'Apache.

L'utilisation de MySQL peut toutefois être très intéressantes
pour gérer les méta-données de l'enregistrement 
(date,heure,utilisateurs,droits de regards/consultation, provider
 utilisé,...) 

Le débat 'enregistreur rapide' côté serveur ou côté client est
uniquement un problème de débit max entre le consumer et le provider
donc ton idée n'est pas redondante.

Toutefois tu supposes si je comprends bien que la machine hébergeant ton
consumer-serveur-WEB voit sans problème (de firewall) les providers TSP.

En ce qui concerne le débat d'un TSP firewall-friendly, le canal de 
commande SOAP seul n'est effectivement pas suffisant et ta solution me
semble très élégante même si elle contourne un peu le problème.
Ca ne veut pas dire qu'on ne pourrait pas passer le canal de données
sur SSL. Dans tous les cas les 2 solutions ont leur intérêt et donc
ta proposition n'est pas redondante avec un consumer distribué qui
passe les firewall, surtout si tu ajoutes à ton serveur Web une BD
qui te permet de faire de la gestion des données d'essais.

D'ailleurs dans le même ordre d'idées si tu pouvais t'arranger
pour que l'on puisse utiliser ta conf apache et ton joli tsp consumer-
serveur-Web avec HTTPS (au lieu de HTTP) ça pourrait être carrement
plus 'vendeur' pour offrir des accès de types 'extranet' à ce serveur.

Donc en ce qui me concerne vas-y fonce, prends une bonne réserve
de Caribou séché et code nous ça, ça sera génial.

Bon j'arrête là,
Sauf pour une anecdote qui est que bien que n'ayant pas chassé le
Caribou ce week-end j'ai quand même fais des raquettes 
(certes à Font-Romeu et pas dans le grand nord Canadien) na !))

Sinon bonne et heureuse année à tous.

Eric


Le dim 28/12/2003 à 13:25, Stephane Galles a écrit :
> Ayant eu le temps de repenser à cette histoire de  'consumer-server Web 
> TSP'
> (j'ai un peu l'impression de parler tout seul ce weekend...),
> je vous propose un peu de science fiction pour se fixer les idées sur ce 
> que j'avais en tête,
> 
> le tout étant de savoir si cela sert à quelque chose en pratique...  (sic)
> 
> - Ce matin Monsieur Yves D. (j'ai masqué les noms pour protéger les 
> innocents), n'est pas
> sur son site de travail favori mais il aimerai bien savoir comment se 
> passe son test qui est
> en train de tourner dans un autre batiment.
> - Il demander à un collègue de lui prêter un PC et se connecte via 
> l'intranet au 'consumer-server Web TSP'
> (cette machine est sur un autre sous-réseau protégées par un FireWall, 
> mais celui-ci laisse passer
> les connexions Web, si parceque...parque j'en ai décidé ainsi !)
> - Monsieur D. entre son nom d'utilisateur et mot de passe sur le site du 
> 'consumer-server Web TSP'
> (pour deux raisons : 1 parceque c'est pas la peine que toute 
> l'entreprise joue avec le serveur, et
> 2 pour une autre raison que j'aborderai plus loin).
> - Monsieur D. obtient alors la liste des provider TSP sur la machine à 
> laquelle le
> 'consumer-server Web TSP'  a ete lié lors de sa configuration (comme il 
> se doit, il a été choisi
> de ne pas mettre le serveur Web sur la machine du consumer pour ne pas 
> dégrader les
> performances du test)
> - Monsieur D. choisit le provider, la liste des variables qu'il veut 
> sampler, phase et période
> et durée d'enregistrement. Il lance le test. Il arrive sur une page Web 
> qui lui dit de patienter
> jusqu'à la fin de l'enregistrement.
> - Les donnés sont enregistrées dans une base de données, ajoutées aux 
> autres enregistrements qu'il a avait réalisé
> ces dernieres semaines. Ces enregistrements ne sont pas mélangés à ceux 
> des autres utilisateurs du serveur,
> puisque monsieur D. avait entré son nom d'utilisateur et mot de passe.
> - L'enregistrement étant terminé, monsieur D. clique sur le lien de la 
> page de consultation des
> enregistrements. Il retrouve ses anciens enregistrements, ainsi que 
> celui qu'il vient de créer.
> Il consulte ce dernier, les courbes des différentes variables 
> s'affichent. Par la même occasion
> cela lui permet de montrer l'enregistrement à monsieur Eric N. qui était 
> dans ce batiment
> mais qui n'avais vraiment pas le temps de passer jusqu'au PC de monsieur 
> D. qui était
> le seul à avoir un Consumer TSP GTK. Et puis de toute façon le PC est 
> sous Windows,
> donc pour l'instant il n'était pas question d'installer un consumer 
> (oui, je vous voie
> venir avec le consumer en JAVA...mais bon...lisez la phrase suivante :). 
> Et puis en plus le réseau sur lequel
> se trouve le PC n'a pas un débit suffisant, d'ou l'intéret dans ce cas 
> de ne pas faire
> transiter les données de test.
> - Monsieur D. décide que ce test est vraiment trés interessant. De 
> retour sur son propre
> PC, il se connecte de nouveau au Serveur Web TSP, et décide d'exporter 
> cet enregistrement vers un fichier RES.
> Il se log au serveur Web TSP, retrouve l'enregistrement qui est toujours 
> resté stocké dans la base, puis
> Il clique sur le lien 'Export d'enregistrement au format RES' et entre 
> un nom de fichier local à son PC.
> Le serveur effectue la conversion BD --> RES et le téléchargement FTP 
> automatique place le fichier RES
> résultant sur son PC.
> 
> Bon heu... voila... sachant que encore une fois :
> - Je tourne en boucle dans mon coin alors que vous aller peut etre me dire
> que c'est redondant avec la faculté à un consumer d'être distribué, et 
> que cela
> n'a donc aucun intéret.
> - Ce système est peu etre redondant avec la notion de Recorder TSP local 
> au provider
> - Je ne sais pas vraiment si cela tiendrai les perfos pour faire des 
> enregistrements
> violents  (néanmoins une base MySQL est trés rapide et avait été pensée 
> au départ pour
> pouvoir mettre beaucoup d'entrée dans les tables et rapidement).
> 
> Voila, quelqu'un voit - il dans cette petite histoire des cas 
> d'utilisation intéressants ?
> 
> Bien, sinon, je vais arreter de parler tout seul pour le Weekend.
> 
> Re - joyeuses Fetes.
> 
> Stephane 'Trappeur' G.
> 
> 
> 
> Stephane Galles wrote:
> 
> > Bonjour,
> >
> > Je cherche actuellement un sujet de développement pour améliorer mes 
> > compétences
> > en techno Web (pour l'anecdote Apache, Tomcat, JSP, Servlet, Struts,
> > Hibernate, MySQL, XDoclets, WebServices)
> >
> > Hors, en y réfléchissant bien, il pourrait y avoir un intéret à accéder
> > à un serveur TSP en distant via du HTTP.  Sans avoir besoin de configurer
> > quoi que ce soit sur une machine, ni sur son réseau.
> >
> > Hors, TSP n'est absolument pas 'firewall friendly'. Et soyons clairs, il
> > ne pourra jamais l'être (même si le canal de commande est implémenté en
> > SOAP, il y aura toujours le problème du canal de données).
> >
> > D'où l'idée d'avoir un 'client léger' pour monitorer des données. Quand
> > je dis client léger, c'est vraiment léger, pur HTTP. Pas d'applets, 
> > car on retomberait dans
> > la cas du 'firewall-pas-friendly'.
> >
> > Autrement dit, il faut un  'consumer-server Web TSP' .
> >
> > Bien sur, dans ce cas il ne pourra pas y avoir de courbe qui 'bougent' 
> > en temps réel.
> >
> > Par contre on peut imaginer un refresh de courbes à la demande (refresh
> > du navigateur), la possibilité de choisir ses symboles, etc...
> >
> > Je me dis également qu'une base de données type MySQL peut etre utile 
> > également, mais
> > là je ne vois pas encore trés bien pour quoi faire (j'ai peur 
> > d'empiéter sur la notion
> > de recorder disk TSP dont on ne sait pas encore s'il a sa place dans 
> > un client ou bien
> > dans le serveur, et de toute façon j'ai l'impression de mélanger les 
> > responsabilités
> > logicielles là).
> >
> > L'idée etant évidemment d'implémenter tout cela grace au code JAVA 
> > d'Eric.
> > On touille le tout, et on obtient un gros fichier .WAR (pour les 
> > connaisseurs)
> > full JAVA, extrement facile à installer dans TomCat sur toute 
> > plateforme où
> > tourne Tomcat (là où il y a une JDK en somme). Si on veut plus 
> > robuste, on peut
> > evidemment faire Apache + Tomcat.
> >
> > Donc que vous inspire tout cela ? Entourer le réponse :
> > a) - "C'est génial et j'ai des idées d'applications !"
> > b) - "Bof, bof..."
> > c) - "Mouais..."
> > d) - "Hum..."
> > e) - "C'est nawak"
> > f) - "T'es vraiment un blatte avec des grosses pattes, et tu nous 
> > ennuis avec tes idioties."
> >
> > J'attend vos réactions/idée/insultes.
> >
> > Stephane 'Trappeur' G.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> >
> >
> 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
-- 
Eric NOULARD
E-mail: address@hidden