Discussion :

[micka132]

Bonjour,
je me pose des questions et j'aimerai un avis sur mon idée.

Le probleme :
Une application bureau sous citrix doit communiquer avec une application Silverlight (ouverte depuis le navigateur de la machine physique).
Lors d'un click par exemple, l'applicatioon lourde envoie un message à wcf, et wcf le transmet a silverlight.

La question est donc comment savoir quel client silverlight est le même utilisateur que le desktop.

Mon idée est lors du premier appel depuis silverlight vers wcf ( par exemple Connexion() ) je recupere l'ID de l'utilisateur , le nom de sa machine ainsi que le GetCallBackChannel<MonService> du client que je met dans une collection.

Lors de l'appel depuis l'application desktop, je fournis la aussi le nom d'utilisateur et de machine, puis je parcours ma collection pour trouver le client correspondant. J'effectue alors mon callback sur le bon client.

Est-ce que je suis pas en train d'inventer la roue, et sinon est-ce que ca semble raisonnable?

Merci!

[cinemania]

il te faut un tiers serveur entre tes clients lourds et clients légers.

on n'envoie pas un message à WCF, on envoie un message par WCF... c'est pas tout à fait pareil, c'est d'ailleurs très différent sémantiquement parlant... WCF ne constitue pas un tiers de ton application n-tiers.
ce n'est pas ici une espèce de grosse boite commune à toutes les applis sur le réseau, dans laquelle tes appli envoie des messages.
WCF est un framework de communication que chaque tiers de ta solution utilise.
il faut donc des tiers serveurs et des tiers clients.

la communication ad-hocs n'est pas vraiment adapté à ce genre de technologie, même si elle reste possible, et je ne pense pas que silverlight ai une implantation suffisamment complète de WPF pour le faire directement.

Non il faut revoir ton architecture de façon à avoir cela :

client lourds (citrix) <----> serveur <----> clients légers (silverlight)

de plus il va falloir opter pour des binding WCF un peu particulier qui supporte le Full Duplex et la communication dans les deux sens.
bien que je pense qu'on puisse faire autrement avec certains binding plus standard, mais plus complexe comme WsHttpBinding, en utilisant la remontée d'évènements.

[micka132]

A priori la communication n'est que dans un sens, de citrix vers Siverlight.

client lourds (citrix) <----> serveur <----> clients légers (silverlight)

Je ne comprend pas bien le sens de ce shema, pourquoi wcf ne peut il pas être associer à un server?

Si je change l'ennoncé du problème : realiser un msn avec un client lourd et un léger. Une partie est donc en silverlight, l'autre en wpf. WCF n'est pas une solution pour s'envoyer des messages?

L'autre solution envisagé est de se limiter à silverlight out of browser, et de parler en COM...J'aimerai plutot eviter mais si j'ai rien d'autre a proposer que je puisse faire (non expert) ca sera malheusement le cas.

[cinemania]

non tu n'a visiblement pas compris.

Tel que ton énoncé était écrit, cela présupposait que tu considèrait WCF non pas comme un moyen, mais comme un serveur.

WCF est un framework de communication, il est donc fait pour que différentes applications communiques entre elles.
Ce n'est pas lui le serveur, c'est à toi de faire un tiers Server qui utilise WCF pour exposer des services WCF.

De là tu va dans tes clients lourd, et tes clients RIA Silverlight consommer ces services exposés par cet applicatif serveur.

Note que cet applicatif serveur peut être une simple librairie WCF (assembly) que tu va pouvoir faire héberger par IIS ou autre sur Windows Server.

Cela suppose quand même que tu va devoir développer toi même chaque tiers de ton application.

WCF ensuite permet divers méthodes de "branchement" de tes tiers, qui ne sont pas tous adaptés à chaque besoin. On choisi un binding "branchement" en fonction des contraintes réseaux que l'on a, et en fonction des contraintes communicationnelles de nos applications.

L'exemple que tu utilise comme MSN suppose que tu ait un serveur pour recevoir et mettre en communication les différents tiers.
En plus un RIA Silverlight ne peut pas exposer un service, il peut le consommer uniquement, et ce même en out of browser. Le but n'est pas de fonctionner en mode serveur. d'ou là nécessité d'un tiers entre ce petit monde, qui lui est un vrai serveur.

[micka132]

Merci, mais j'ai beaucoup de mal a comprendre ce qu'il devrait y avoir dans se fameux 3eme tier.
Le seul moyen que je connaisse pour communiquer avec silverlight s'il n'est pas Out of Browser, c'est WCF et son mode Duplex.( mis a part les sockets, mais apparement le wcf duplex est le sauveur de cette methode).
Si je crée un tier, c'est dans le but de parler à silverlight, et donc finalement passer par wcf. Quel est donc son utilité?