Arnaud CLERET wrote:Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
Arnaud CLERET wrote:
Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
Arnaud CLERET wrote:Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
Je suis d'accord sur le fait que Remoting est lié à .Net et ne permettra
donc pas d'être interopérable avec d'autre technologies.
Du coup la solution de la file MSMQ ou de la base de données me semble
être le mieux. Je reste sur ma position que l'implémentation de la
communication par socket reste bien plus compliquée à implémenter et sera
certainement source de plus d'erreur. Et je ne parle même pas des
problèmes de sécurité et d'authentification ...
--
arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news:
4434b674$0$18264$Arnaud CLERET wrote:Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
Je suis d'accord sur le fait que Remoting est lié à .Net et ne permettra
donc pas d'être interopérable avec d'autre technologies.
Du coup la solution de la file MSMQ ou de la base de données me semble
être le mieux. Je reste sur ma position que l'implémentation de la
communication par socket reste bien plus compliquée à implémenter et sera
certainement source de plus d'erreur. Et je ne parle même pas des
problèmes de sécurité et d'authentification ...
--
arno - http://www.dotnetguru2.org/acleret/
"Delf" <no-one@nowhere.no> a écrit dans le message de news:
4434b674$0$18264$636a55ce@news.free.fr...
Arnaud CLERET wrote:
Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
Je suis d'accord sur le fait que Remoting est lié à .Net et ne permettra
donc pas d'être interopérable avec d'autre technologies.
Du coup la solution de la file MSMQ ou de la base de données me semble
être le mieux. Je reste sur ma position que l'implémentation de la
communication par socket reste bien plus compliquée à implémenter et sera
certainement source de plus d'erreur. Et je ne parle même pas des
problèmes de sécurité et d'authentification ...
--
arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news:
4434b674$0$18264$Arnaud CLERET wrote:Non c'est tout à fait ça avec des possibilité dans les choix
d'instantiation des objets exposés par le serveur au client, de
récupération de référence ou de valeur, de traitement "oneway" ...
En plus, il peut être géré au travers d'un service windows comme pour le
cas de Vincent au travers de TCP par sérialisation binaire ou SOAP mais
aussi au travers de Http par un hébergement au sein de IIS.
Pour ma part, vu ce que veut faire Vincent, je lui conseillerais
l'utilisation de socket. CA lui permettrait par la suite, on ne sait
jamais, de créer des clients sous d'autres environnements/langages.
Avec du Remoting, j'ai bien qu'il soit bloqué...
--
Delf
Do not use this email in Cc!
A New York les taxis sont jaunes, à Londres ils sont noirs et à Paris ils
sont cons.
soit y a un service windows qui a les droits ( car appartenant à admin ) et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
soit y a un service windows qui a les droits ( car appartenant à admin ) et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
soit y a un service windows qui a les droits ( car appartenant à admin ) et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:
soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
J'appui cette solution ! :) De loin la plus simple, la plus robuste et
performante mais certes pas totalement interoperable comme le soulignait
Delf.
--
arno - http://www.dotnetguru2.org/acleret/
"Mehdi" a écrit dans le message de news:
1eh0h0i4m8kyr.nple0lzrto9e$On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object
local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la
méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
J'appui cette solution ! :) De loin la plus simple, la plus robuste et
performante mais certes pas totalement interoperable comme le soulignait
Delf.
--
arno - http://www.dotnetguru2.org/acleret/
"Mehdi" <vioccc@REMOVEME.gmail.com> a écrit dans le message de news:
1eh0h0i4m8kyr.nple0lzrto9e$.dlg@40tude.net...
On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:
soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object
local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la
méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
J'appui cette solution ! :) De loin la plus simple, la plus robuste et
performante mais certes pas totalement interoperable comme le soulignait
Delf.
--
arno - http://www.dotnetguru2.org/acleret/
"Mehdi" a écrit dans le message de news:
1eh0h0i4m8kyr.nple0lzrto9e$On Thu, 6 Apr 2006 21:58:02 +0200, Vincent wrote:soit y a un service windows qui a les droits ( car appartenant à admin )
et
qui fait le createfile à la place du programme
(quand ce dernier le lui demande )
mon objectif serait que le programme envoi un message windows du style
GO1
( WM_Message ou équivalent ), quand le service voit
passer ce message il sait ce qu'il a à faire et il envoi à son tour un
message du style OKGO1.
Ca existe toujours les messages windows :) ?
Oui mais il n'y a pas a ma connaissance de maniere managée pour envoyer
des
messages windows a d'autres applis sous .NET donc il va falloir faire un
peu d'interop. Ce n'est pas bien compliqué et il y a des exemples partout
sur le net. L'autre probleme est que pour que ton service puisse choper
les
messages, il va lui falloir avoir une pompe a messages, ce qu'il n'a pas
par défaut.
A mon avis, .NET Remoting sera de loin la méthode la plus simple pour ton
probleme. C'est tout bete:
1) Tu cree une interface qui définit les méthode que l'appli cliente
souhaite faire executer au serveur et tu la met dans une DLL référencée
par
l'appli cliente et ton service Windows. Par exemple:
public interface IServiceHelper
{
void GO1();
int UneAutreMethode(string unParametreQuelconque);
}
2) Dans le service Windows, tu implémente les méthodes de cette interface
(c'est la que tu pourra appeler ton CreateFile). Puis, dans la méthode
OnStart du service, tu aura a écrires 3 lignes de code pour créer un
channel et exposer ton object via .NET Remoting.
3) Dans l'appli cliente, 3 lignes de code pour créer un channel et
récuperer une référence vers l'object hébergé par ton service windows.
Voila c'est tout. L'appli cliente peut maintenant appeler les méthode de
l'interface IServiceHelper comme si elle travaillait avec un object
local.
.NET Remoting s'occupe pour toi d'établir et de maintenir la connection
entre les 2 applis, de sérialiser les parametres et valeurs de retour des
fonctions appelées, de sérialiser et transmettre les exceptions...
L'avantage de .NET Remoting par rapport aux messages windows est que tu
peux passer n'importe quel parametres aux fonctions, avoir n'importe quel
valeurs de retour, les exceptions lancée lors de l'execution de la
méthode
dans ton service windows sont transmise a l'appli cliente qui peux les
catcher. En fait, du point de vue de l'appli cliente, c'est tout comme
elle
travaillait avec un object local "normal" et elle n'a pas a se préocuper
du
fait que le boulot est en fait fait par une autre appli (le service
Windows).
