Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
PS : je me suis basé sur l'exemple de Cohen Shwartz Oren
URL : http://www.codeproject.com/csharp/PathRemotingArticle.asp
Merci d'avance d'eclairer ma lenterne...
Gislain.
Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
PS : je me suis basé sur l'exemple de Cohen Shwartz Oren
URL : http://www.codeproject.com/csharp/PathRemotingArticle.asp
Merci d'avance d'eclairer ma lenterne...
Gislain.
Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
PS : je me suis basé sur l'exemple de Cohen Shwartz Oren
URL : http://www.codeproject.com/csharp/PathRemotingArticle.asp
Merci d'avance d'eclairer ma lenterne...
Gislain.
Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin qu'il
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé de
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les évènements
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin qu'il
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé de
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les évènements
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
Bonjour,
Je viens enfin de faire fonctionner (enfin) un objet en remoting afin qu'il
me retourne un évènement, mais je ne comprend pas pourquoi je suis obligé de
le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
Si j'enregistre mon object en WellKnownObjectMode.SingleCall les évènements
ne sont pas remontés à l'appelant.
Quelqu'un peut-il m'expliquer pourqoui ?
PS : Je cherche donc le moyen d'avoir un objet en SingleCall qui puisse
renvoyer les evt car plusieurs clients doivent pouvoir lancer le même
traitement sur le serveur et être informés lorsque le process est terminé.
Comment faire .. ??? ....
PS : Je cherche donc le moyen d'avoir un objet en SingleCall qui puisse
renvoyer les evt car plusieurs clients doivent pouvoir lancer le même
traitement sur le serveur et être informés lorsque le process est terminé.
Comment faire .. ??? ....
PS : Je cherche donc le moyen d'avoir un objet en SingleCall qui puisse
renvoyer les evt car plusieurs clients doivent pouvoir lancer le même
traitement sur le serveur et être informés lorsque le process est terminé.
Comment faire .. ??? ....
On Sat, 27 Nov 2004 08:49:03 +0100, Gislain wrote:
> Bonjour,
Salut,
> Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
> me retourne un évènement, mais je ne comprend pas pourquoi je suis
> le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
> Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
> ne sont pas remontés à l'appelant.
>
> Quelqu'un peut-il m'expliquer pourqoui ?
J'imagine que c'est a cause du fait qu'un objet single call n'est utilisé
qu'une fois puis détruit.
Plus clairement: lorsque tu expose un objet en single call et qu'un client
appele une méthode de cet objet, le framework crée une instance de cet
objet, execute la méthode demandée puis détruit l'objet. C'est le principe
du single call. Il n'y a pas persistence de l'état de l'objet. Ca
fonctionne en fait exactement comme une méthode d'un service web ou comme
une page web. Le serveur ne se souvient pas de ce qu'il c'est passé avant,
il exécute les methodes a la demande puis oublie tout. C'est sans doute
pour cela que si un client s'inscrit a un évenement de ton object single
call, l'évenement n'est jamais levé car l'object distant est immédiatement
détruit.
Si ton objet est singleton, alors la, c'est différent. Un objet singleton
est instancié la premiere fois qu'un client appelle une de ses méthodes.
Puis il reste en mémoire (techniquement parlant on va dire qu'il y a
persistance de l'état de l'object). A chaque fois que le client, ou un
autre client, appele une méthode de cet object, elle est executée sur ce
meme object. Tout les client ont donc accés a la meme instance de ton
object. Cet object ne sera détruit qu'une fois son "lease" (durée de vie,
fixée par défaut a 5 minutes) aura expiré. Si des client s'inscrivent a un
évenement de cet object, ils le recevront tant que cet objet n'aura pas
détruit (donc gaffe a la durée de vie de ton object, c'est souvent une
source de bugs incompréhensibles pour les débutant en .NET Remoting).
On Sat, 27 Nov 2004 08:49:03 +0100, Gislain wrote:
> Bonjour,
Salut,
> Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
> me retourne un évènement, mais je ne comprend pas pourquoi je suis
> le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
> Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
> ne sont pas remontés à l'appelant.
>
> Quelqu'un peut-il m'expliquer pourqoui ?
J'imagine que c'est a cause du fait qu'un objet single call n'est utilisé
qu'une fois puis détruit.
Plus clairement: lorsque tu expose un objet en single call et qu'un client
appele une méthode de cet objet, le framework crée une instance de cet
objet, execute la méthode demandée puis détruit l'objet. C'est le principe
du single call. Il n'y a pas persistence de l'état de l'objet. Ca
fonctionne en fait exactement comme une méthode d'un service web ou comme
une page web. Le serveur ne se souvient pas de ce qu'il c'est passé avant,
il exécute les methodes a la demande puis oublie tout. C'est sans doute
pour cela que si un client s'inscrit a un évenement de ton object single
call, l'évenement n'est jamais levé car l'object distant est immédiatement
détruit.
Si ton objet est singleton, alors la, c'est différent. Un objet singleton
est instancié la premiere fois qu'un client appelle une de ses méthodes.
Puis il reste en mémoire (techniquement parlant on va dire qu'il y a
persistance de l'état de l'object). A chaque fois que le client, ou un
autre client, appele une méthode de cet object, elle est executée sur ce
meme object. Tout les client ont donc accés a la meme instance de ton
object. Cet object ne sera détruit qu'une fois son "lease" (durée de vie,
fixée par défaut a 5 minutes) aura expiré. Si des client s'inscrivent a un
évenement de cet object, ils le recevront tant que cet objet n'aura pas
détruit (donc gaffe a la durée de vie de ton object, c'est souvent une
source de bugs incompréhensibles pour les débutant en .NET Remoting).
On Sat, 27 Nov 2004 08:49:03 +0100, Gislain wrote:
> Bonjour,
Salut,
> Je viens enfin de faire fonctionner (enfin) un objet en remoting afin
> me retourne un évènement, mais je ne comprend pas pourquoi je suis
> le déclarer en WellKnownObjectMode.Singleton pour que cela fonctionne.
> Si j'enregistre mon object en WellKnownObjectMode.SingleCall les
> ne sont pas remontés à l'appelant.
>
> Quelqu'un peut-il m'expliquer pourqoui ?
J'imagine que c'est a cause du fait qu'un objet single call n'est utilisé
qu'une fois puis détruit.
Plus clairement: lorsque tu expose un objet en single call et qu'un client
appele une méthode de cet objet, le framework crée une instance de cet
objet, execute la méthode demandée puis détruit l'objet. C'est le principe
du single call. Il n'y a pas persistence de l'état de l'objet. Ca
fonctionne en fait exactement comme une méthode d'un service web ou comme
une page web. Le serveur ne se souvient pas de ce qu'il c'est passé avant,
il exécute les methodes a la demande puis oublie tout. C'est sans doute
pour cela que si un client s'inscrit a un évenement de ton object single
call, l'évenement n'est jamais levé car l'object distant est immédiatement
détruit.
Si ton objet est singleton, alors la, c'est différent. Un objet singleton
est instancié la premiere fois qu'un client appelle une de ses méthodes.
Puis il reste en mémoire (techniquement parlant on va dire qu'il y a
persistance de l'état de l'object). A chaque fois que le client, ou un
autre client, appele une méthode de cet object, elle est executée sur ce
meme object. Tout les client ont donc accés a la meme instance de ton
object. Cet object ne sera détruit qu'une fois son "lease" (durée de vie,
fixée par défaut a 5 minutes) aura expiré. Si des client s'inscrivent a un
évenement de cet object, ils le recevront tant que cet objet n'aura pas
détruit (donc gaffe a la durée de vie de ton object, c'est souvent une
source de bugs incompréhensibles pour les débutant en .NET Remoting).
Merci Elp pour tes 2 messages
Sachant que je suis effectivement un débutant en .Net Remoting, cela me
laisse présager de nombreuses heures de reflexions pour la suite.
Merci pour tes explications.
Merci Elp pour tes 2 messages
Sachant que je suis effectivement un débutant en .Net Remoting, cela me
laisse présager de nombreuses heures de reflexions pour la suite.
Merci pour tes explications.
Merci Elp pour tes 2 messages
Sachant que je suis effectivement un débutant en .Net Remoting, cela me
laisse présager de nombreuses heures de reflexions pour la suite.
Merci pour tes explications.
On Sat, 27 Nov 2004 18:30:23 +0100, Gislain wrote:
> Merci Elp pour tes 2 messages
>
> Sachant que je suis effectivement un débutant en .Net Remoting, cela me
> laisse présager de nombreuses heures de reflexions pour la suite.
> Merci pour tes explications.
.NET Remoting est tres simple a utiliser (enfin a partir du moment que tu
cherche a faire des choses pas trop pointues bien sur) mais peux devenir
une horreur si tu te lance dedans tete baissée sans prendre le temps
d'acquérir les bases (c'est comme tout, rien n'set magique...). Donc, lit
la doc, comprends bien tout ce qui se passe dans les exemples simples qui
fourmillent sur le Web et si tu lit l'anglais et que .NET Remoting est
important pour ton projet, achete cet excellent bouquin: Advanced .NET
Remoting par Ingo Rammer (il y a une edition VB et une C#). Malgré son
titre il est aussi bien adapté aux parfaits débutants qu'aux utilisateurs
avancés et surtout tres clair et bien illustré (d'exemples pas d'images
bien sur:-). Le site web de l'auteur est une bonne source d'infos
également: http://www.thinktecture.com/Resources/default.html. Jette un
oeil a la faq.
On Sat, 27 Nov 2004 18:30:23 +0100, Gislain wrote:
> Merci Elp pour tes 2 messages
>
> Sachant que je suis effectivement un débutant en .Net Remoting, cela me
> laisse présager de nombreuses heures de reflexions pour la suite.
> Merci pour tes explications.
.NET Remoting est tres simple a utiliser (enfin a partir du moment que tu
cherche a faire des choses pas trop pointues bien sur) mais peux devenir
une horreur si tu te lance dedans tete baissée sans prendre le temps
d'acquérir les bases (c'est comme tout, rien n'set magique...). Donc, lit
la doc, comprends bien tout ce qui se passe dans les exemples simples qui
fourmillent sur le Web et si tu lit l'anglais et que .NET Remoting est
important pour ton projet, achete cet excellent bouquin: Advanced .NET
Remoting par Ingo Rammer (il y a une edition VB et une C#). Malgré son
titre il est aussi bien adapté aux parfaits débutants qu'aux utilisateurs
avancés et surtout tres clair et bien illustré (d'exemples pas d'images
bien sur:-). Le site web de l'auteur est une bonne source d'infos
également: http://www.thinktecture.com/Resources/default.html. Jette un
oeil a la faq.
On Sat, 27 Nov 2004 18:30:23 +0100, Gislain wrote:
> Merci Elp pour tes 2 messages
>
> Sachant que je suis effectivement un débutant en .Net Remoting, cela me
> laisse présager de nombreuses heures de reflexions pour la suite.
> Merci pour tes explications.
.NET Remoting est tres simple a utiliser (enfin a partir du moment que tu
cherche a faire des choses pas trop pointues bien sur) mais peux devenir
une horreur si tu te lance dedans tete baissée sans prendre le temps
d'acquérir les bases (c'est comme tout, rien n'set magique...). Donc, lit
la doc, comprends bien tout ce qui se passe dans les exemples simples qui
fourmillent sur le Web et si tu lit l'anglais et que .NET Remoting est
important pour ton projet, achete cet excellent bouquin: Advanced .NET
Remoting par Ingo Rammer (il y a une edition VB et une C#). Malgré son
titre il est aussi bien adapté aux parfaits débutants qu'aux utilisateurs
avancés et surtout tres clair et bien illustré (d'exemples pas d'images
bien sur:-). Le site web de l'auteur est une bonne source d'infos
également: http://www.thinktecture.com/Resources/default.html. Jette un
oeil a la faq.
Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
moyen d'informer le client en asynchrone que le job était terminé (d'une
manière simple et clean).
Est-ce possible, au même titre que les évènements en .Net Remoting ?
Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
moyen d'informer le client en asynchrone que le job était terminé (d'une
manière simple et clean).
Est-ce possible, au même titre que les évènements en .Net Remoting ?
Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
moyen d'informer le client en asynchrone que le job était terminé (d'une
manière simple et clean).
Est-ce possible, au même titre que les évènements en .Net Remoting ?
On Sun, 28 Nov 2004 10:28:56 +0100, Gislain wrote:
> Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
> moyen d'informer le client en asynchrone que le job était terminé (d'une
> manière simple et clean).
> Est-ce possible, au même titre que les évènements en .Net Remoting ?
Aucune idée, je ne connais pas MSMQ. Je suis un peu étonné que personne
d'autre n'ai répondu a ton post original car je suis sur que d'autre ici
doivent avoir de meilleures idée pour résoudre ton probleme. En tout cas,
pour toutes les questions .NET Remoting, tu peux tenter ta chance ici:
microsoft.public.dotnet.framework.remoting
Ils y a d'excellents contributeurs sur ce forum et c'est sans doute la que
tu trouvera la meilleure solution pour ton probleme.
a+
On Sun, 28 Nov 2004 10:28:56 +0100, Gislain wrote:
> Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
> moyen d'informer le client en asynchrone que le job était terminé (d'une
> manière simple et clean).
> Est-ce possible, au même titre que les évènements en .Net Remoting ?
Aucune idée, je ne connais pas MSMQ. Je suis un peu étonné que personne
d'autre n'ai répondu a ton post original car je suis sur que d'autre ici
doivent avoir de meilleures idée pour résoudre ton probleme. En tout cas,
pour toutes les questions .NET Remoting, tu peux tenter ta chance ici:
microsoft.public.dotnet.framework.remoting
Ils y a d'excellents contributeurs sur ce forum et c'est sans doute la que
tu trouvera la meilleure solution pour ton probleme.
a+
On Sun, 28 Nov 2004 10:28:56 +0100, Gislain wrote:
> Exception faite de MSMQ pour envoyer des job, mais je n'ai pas trouvé le
> moyen d'informer le client en asynchrone que le job était terminé (d'une
> manière simple et clean).
> Est-ce possible, au même titre que les évènements en .Net Remoting ?
Aucune idée, je ne connais pas MSMQ. Je suis un peu étonné que personne
d'autre n'ai répondu a ton post original car je suis sur que d'autre ici
doivent avoir de meilleures idée pour résoudre ton probleme. En tout cas,
pour toutes les questions .NET Remoting, tu peux tenter ta chance ici:
microsoft.public.dotnet.framework.remoting
Ils y a d'excellents contributeurs sur ce forum et c'est sans doute la que
tu trouvera la meilleure solution pour ton probleme.
a+
