Discussion :

[butane]

Bonjour à tous,

Je dois réaliser une application qui met à jour l'affichage d'un client lourd swing en fonction de commandes que je recevrais à travers un web service.
Pour tout un tas de raison, j'ai décidé de réaliser cette application avec les techno J2EE, EJB3, ...
Jusqu'à présent, j'ai réalisé l'interface webservice grâce à une session annotée @WebService et mon client lourd swing que je distribue via JWS. Le tout est packagé dans un EAR.

Comment feriez-vous pour mettre à jour ce client lourd swing sur réception d'une commande sur l'interface web service ?

[Desboys]

Bonjour,

personnellement, j'ai dû mal à comprendre les échanges qui doivent s'établir avec le "client lourd".

Est-ce que ton application, dite "client lourd", et donc qui s'exécute sur un poste utilisateur, doit être contactée directement sur un port qui expose des opérations sous forme de webservice?
Si oui, alors il faut plutôt regarder du côté des Endpoints JAX-WS et leur publication ( même si je doute que ça soit la meilleure approche, ne serait-ce que pour des problématiques d'adressage/localisation ).

Sinon, je serai plutôt partisan d'une approche type MoM comme vecteur de communication entre un webservice hébergé dans un conteneur JEE et ton application "client lourd", avec consommation de messages sur Topic. J'irai potentiellement tirer du côté du JEE AppClient d'un point de vue "environnement managé" et déploiement.

Sans trop savoir quelles doivent être les actions menées entre le WS et le client, rien ne t'assure que ça soit le plus adapté.

Cordialement,
Sébastien

[butane]

Hello,

Merci pour ta réponse.

Les échanges entre le webservice et le client lourd sont des commandes du genre :
#afficher un flux vidéo
#arrêter l'affichage du flux courant
#...

Sinon, je serai plutôt partisan d'une approche type MoM comme vecteur de communication entre un webservice hébergé dans un conteneur JEE et ton application "client lourd", avec consommation de messages sur Topic. J'irai potentiellement tirer du côté du JEE AppClient d'un point de vue "environnement managé" et déploiement.

Ok, j'avais déjà retenu la solution JEE AppClient pour le client lourd .
Maintenant là où j'ai encore des doutes c'est la communication entre le webservice et le client lourd (sans te cacher que j'étais déjà en train de jeter un oeil à JMS).

D'autre idée ?

[manblaizo]

D'autre idée ?

Oui, faire comme pour de l'ajax, ton client ferait du poll du webservice à intervalle régulier, dans un thread séparé, et mettrait à jour l'affichage s'il y a quelque chose de nouveau à afficher...

Pas la peine de se compliquer la vie avec un broker de plus entre le client et le serveur.

[butane]

J'ai fait quelques tests avec JMS : J'en ai conclu que j'aurais besoins de 2 queues : une pour l'envoie de la commande du webservice à la GUI et d'une pour l'envoie de la réponse de la GUI au webservice ça devient un peu trop tricky...

Oui, faire comme pour de l'ajax, ton client ferait du poll du webservice à intervalle régulier, dans un thread séparé, et mettrait à jour l'affichage s'il y a quelque chose de nouveau à afficher...

Pas la peine de se compliquer la vie avec un broker de plus entre le client et le serveur.

Ok, j'avais aussi imaginée cette solution sauf que ça va augmenter les temps de latence entre 2 affichages de flux vidéo...

J'ai comme l'impression que dans mon cas, il serait plus judicieux de se passer du serveur d'application non ?