Sur le client, j'y accède de la facon suivante :
RemEmploye = Activator.GetObject(GetType(IAccueilClients.IEmploye),
"tcp://MyServeur:1234/GestionAccueilObjets")
Ca fonctionne bien...
Mais j'aimerais aussi accéder à cet objet depuis le serveur.
Actuellement sur le serveur j'y accède de la facon suivante :
Mais je me dit que comme cet objet sur le serveur est local, n'y a t'il pas
une autre facon de faire plus simple pour y accéder sans passer par
Activator.GetObject puisqu'il est en local ?!?!?
Mais j'aimerais aussi accéder à cet objet depuis le serveur. Actuellement sur le serveur j'y accède de la facon suivante :
LocEmploye = Activator.GetObject(GetType(IAccueilClients.IEmploye), "tcp://MyServeur:1234/GestionAccueilObjets") Mais je me dit que comme cet objet sur le serveur est local, n'y a t'il pas une autre facon de faire plus simple pour y accéder sans passer par Activator.GetObject puisqu'il est en local ?!?!?
Que veux tu dire par "serveur": l'application serveur qui publie ton objet ou la machine ou tourne l'appli serveur. Si tu veux acceder a ton objet depuis une autre appli qui tourne sur la meme machine que ton appli serveur, alors, non, y a pas moyen de faire autrement.
Si tu veux acceder a l'instance publié de ton objet Employe depuis ton appli qui le publie, alors oui il y a une autre solution: pour l'instant tu publie le type de ton objet et tu laisse Remoting s'occuper d'en créer une instance au premier appel d'un client. Tu pourrai a la place créer toi meme une instance d'Employe et publier cette instance:
Employe publishedEmploye = new Employe(); RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le .rem c'est juste une "best practice", c'est pas obligatoire)
Et apres tu fait ce que tu veux de ton objet publishedEmploye sur le serveur. Fait gaffe au fait que si le lease de ton objet publié expire, publishedEmploye risque de ne plus etre l'instance accédée par les clients (je ne suis pas trop sur de ce qui se passe en fait dans ce cas la quand on utilise RemotingServices.Marshal).
Salut
On Thu, 16 Dec 2004 18:28:28 +0100, MrChris wrote:
J'ai un objet Employe que j'enregistre sur le serveur pour pouvoir y acceder
à distance de la facon suivante :
Mais j'aimerais aussi accéder à cet objet depuis le serveur.
Actuellement sur le serveur j'y accède de la facon suivante :
LocEmploye = Activator.GetObject(GetType(IAccueilClients.IEmploye),
"tcp://MyServeur:1234/GestionAccueilObjets")
Mais je me dit que comme cet objet sur le serveur est local, n'y a t'il pas
une autre facon de faire plus simple pour y accéder sans passer par
Activator.GetObject puisqu'il est en local ?!?!?
Que veux tu dire par "serveur": l'application serveur qui publie ton objet
ou la machine ou tourne l'appli serveur. Si tu veux acceder a ton objet
depuis une autre appli qui tourne sur la meme machine que ton appli
serveur, alors, non, y a pas moyen de faire autrement.
Si tu veux acceder a l'instance publié de ton objet Employe depuis ton
appli qui le publie, alors oui il y a une autre solution: pour l'instant tu
publie le type de ton objet et tu laisse Remoting s'occuper d'en créer une
instance au premier appel d'un client. Tu pourrai a la place créer toi meme
une instance d'Employe et publier cette instance:
Employe publishedEmploye = new Employe();
RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le
.rem c'est juste une "best practice", c'est pas obligatoire)
Et apres tu fait ce que tu veux de ton objet publishedEmploye sur le
serveur. Fait gaffe au fait que si le lease de ton objet publié expire,
publishedEmploye risque de ne plus etre l'instance accédée par les clients
(je ne suis pas trop sur de ce qui se passe en fait dans ce cas la quand on
utilise RemotingServices.Marshal).
Mais j'aimerais aussi accéder à cet objet depuis le serveur. Actuellement sur le serveur j'y accède de la facon suivante :
LocEmploye = Activator.GetObject(GetType(IAccueilClients.IEmploye), "tcp://MyServeur:1234/GestionAccueilObjets") Mais je me dit que comme cet objet sur le serveur est local, n'y a t'il pas une autre facon de faire plus simple pour y accéder sans passer par Activator.GetObject puisqu'il est en local ?!?!?
Que veux tu dire par "serveur": l'application serveur qui publie ton objet ou la machine ou tourne l'appli serveur. Si tu veux acceder a ton objet depuis une autre appli qui tourne sur la meme machine que ton appli serveur, alors, non, y a pas moyen de faire autrement.
Si tu veux acceder a l'instance publié de ton objet Employe depuis ton appli qui le publie, alors oui il y a une autre solution: pour l'instant tu publie le type de ton objet et tu laisse Remoting s'occuper d'en créer une instance au premier appel d'un client. Tu pourrai a la place créer toi meme une instance d'Employe et publier cette instance:
Employe publishedEmploye = new Employe(); RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le .rem c'est juste une "best practice", c'est pas obligatoire)
Et apres tu fait ce que tu veux de ton objet publishedEmploye sur le serveur. Fait gaffe au fait que si le lease de ton objet publié expire, publishedEmploye risque de ne plus etre l'instance accédée par les clients (je ne suis pas trop sur de ce qui se passe en fait dans ce cas la quand on utilise RemotingServices.Marshal).
MrChris
Et ouais... je suis bien con desfois !!! C'est la deuxiemme solution que je veut faire !
Employe publishedEmploye = new Employe(); RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le .rem c'est juste une "best practice", c'est pas obligatoire)
Ok, je savais bien que c'etait tout bête !
Merci MrChris
Et ouais... je suis bien con desfois !!!
C'est la deuxiemme solution que je veut faire !
Employe publishedEmploye = new Employe();
RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le
.rem c'est juste une "best practice", c'est pas obligatoire)
Et ouais... je suis bien con desfois !!! C'est la deuxiemme solution que je veut faire !
Employe publishedEmploye = new Employe(); RemotingServices.Marshal(publishedEmploye,"GestionAccueilObjets.rem"); (le .rem c'est juste une "best practice", c'est pas obligatoire)
