Ma dernière question sur les services RMI n'ayant pas eu beaucoup de
succès - elle ne devait pas être très claire -, je me permet de la
reposer sous une autre forme...
Peut-on :
1 - établir une connexion réseau entre un service et un client RMI,
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité,
3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre
extrémité ?
Le but étant de permettre l'accès à un service RMI, tournant sur une
machine ayant une /adresse privée/, à un client, tournant sur une
machine ayant une /adresse publique/. Vous me direz que c'est le monde
à l'envers ! Mais si je veux permettre a un serveur d'application de
poser des questions à une applet, il me semble que cela pourrait être la
solution... Non ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Hervé AGNOUX
Valdo Tschantre wrote:
Peut-on : 1 - établir une connexion réseau entre un service et un client RMI,
Si par "service" tu entends un "serveur rmi", oui, heureusement. (j'ai un peu de mal à comprendre).
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub sont des objets que l'on n'utilise pas volontairement.
Le but étant de permettre l'accès à un service RMI, tournant sur une machine ayant une /adresse privée/, à un client, tournant sur une machine ayant une /adresse publique/. Vous me direz que c'est le monde à l'envers ! Mais si je veux permettre a un serveur d'application de poser des questions à une applet, il me semble que cela pourrait être la solution... Non ?
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à l'envers : le client fait une requête sur le serveur... qui ne répond que lorsqu'il a quelque chose à dire ou à demander au client. La réponse contient une demande au client, qui re-répond en se reconnectant au serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
L'ortodoxie pour se genre de problèmes est d'utiliser le RMI Callback, dont tu pourras trouver un exemple à http://djlweb.free.fr/java/faq/java-faq-12.html#ss12.4, ou, en anglais, " An in-depth look at RMI callbacks" 'http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html).
Je l'ai jamais fait, parce que je me suis éloigné du RMI en même temps que du java 1.1, mais je me suis dit que cela aurait été utile si j'avais continué.
Cordialement.
-- Hervé AGNOUX http://www.diaam-informatique.com
Valdo Tschantre wrote:
Peut-on :
1 - établir une connexion réseau entre un service et un client RMI,
Si par "service" tu entends un "serveur rmi", oui, heureusement. (j'ai un
peu de mal à comprendre).
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité,
3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre
extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne
comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub
sont des objets que l'on n'utilise pas volontairement.
Le but étant de permettre l'accès à un service RMI, tournant sur une
machine ayant une /adresse privée/, à un client, tournant sur une
machine ayant une /adresse publique/. Vous me direz que c'est le monde
à l'envers ! Mais si je veux permettre a un serveur d'application de
poser des questions à une applet, il me semble que cela pourrait être la
solution... Non ?
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à
l'envers : le client fait une requête sur le serveur... qui ne répond que
lorsqu'il a quelque chose à dire ou à demander au client. La réponse
contient une demande au client, qui re-répond en se reconnectant au
serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
L'ortodoxie pour se genre de problèmes est d'utiliser le RMI Callback, dont
tu pourras trouver un exemple à
http://djlweb.free.fr/java/faq/java-faq-12.html#ss12.4, ou, en anglais, "
An in-depth look at RMI callbacks"
'http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html).
Je l'ai jamais fait, parce que je me suis éloigné du RMI en même temps que
du java 1.1, mais je me suis dit que cela aurait été utile si j'avais
continué.
Peut-on : 1 - établir une connexion réseau entre un service et un client RMI,
Si par "service" tu entends un "serveur rmi", oui, heureusement. (j'ai un peu de mal à comprendre).
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub sont des objets que l'on n'utilise pas volontairement.
Le but étant de permettre l'accès à un service RMI, tournant sur une machine ayant une /adresse privée/, à un client, tournant sur une machine ayant une /adresse publique/. Vous me direz que c'est le monde à l'envers ! Mais si je veux permettre a un serveur d'application de poser des questions à une applet, il me semble que cela pourrait être la solution... Non ?
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à l'envers : le client fait une requête sur le serveur... qui ne répond que lorsqu'il a quelque chose à dire ou à demander au client. La réponse contient une demande au client, qui re-répond en se reconnectant au serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
L'ortodoxie pour se genre de problèmes est d'utiliser le RMI Callback, dont tu pourras trouver un exemple à http://djlweb.free.fr/java/faq/java-faq-12.html#ss12.4, ou, en anglais, " An in-depth look at RMI callbacks" 'http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html).
Je l'ai jamais fait, parce que je me suis éloigné du RMI en même temps que du java 1.1, mais je me suis dit que cela aurait été utile si j'avais continué.
Cordialement.
-- Hervé AGNOUX http://www.diaam-informatique.com
Valdo Tschantre
Valdo Tschantre wrote:
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub sont des objets que l'on n'utilise pas volontairement.
Qu'ils soient cachés à l'utilisation est une chose, mais ils seront malgré tout utilisés... Et dans mon cas, ce sont les informations d'adressages réseaux portées par le /stub/ du client, utilisé par le serveur, qui posent des problèmes.
En effet, le client étant dans un domaine d'adressage privé, le /stub/ de ce client utilisé par le serveur - qui est pour sa part dans un domaine d'adressage public - transporte des informations réseaux erronées au vue de ce serveur; le serveur ne sait pas atteindre le client. Et Malheureusement pour moi, les RMI CallBack ne résolvent pas ce problème.
Cependant, si le client initiait une connexion vers le serveur, alors le serveur aurait à sa disposition un canal de communication vers le client. Resterait alors à dérouter les requêtes du /stub/, coté serveur, vers ce canal et à faire écouté ce canal au /skeleton/, côté client.
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à l'envers : le client fait une requête sur le serveur... qui ne répond que lorsqu'il a quelque chose à dire ou à demander au client. La réponse contient une demande au client, qui re-répond en se reconnectant au serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
Ton approche me semble être une bonne alternative au /tunneling/ que je souhaiterais mettre en oeuvre...
Cordialement.
Merci Hervé.
Si d'autres personnes avaient des pistes... je suis toujours preneur ;)
--
Valdo Tschantre wrote:
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité,
3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre
extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne
comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub
sont des objets que l'on n'utilise pas volontairement.
Qu'ils soient cachés à l'utilisation est une chose, mais ils seront
malgré tout utilisés... Et dans mon cas, ce sont les informations
d'adressages réseaux portées par le /stub/ du client, utilisé par le
serveur, qui posent des problèmes.
En effet, le client étant dans un domaine d'adressage privé, le /stub/
de ce client utilisé par le serveur - qui est pour sa part dans un
domaine d'adressage public - transporte des informations réseaux
erronées au vue de ce serveur; le serveur ne sait pas atteindre le
client. Et Malheureusement pour moi, les RMI CallBack ne résolvent pas
ce problème.
Cependant, si le client initiait une connexion vers le serveur, alors le
serveur aurait à sa disposition un canal de communication vers le
client. Resterait alors à dérouter les requêtes du /stub/, coté
serveur, vers ce canal et à faire écouté ce canal au /skeleton/, côté
client.
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à
l'envers : le client fait une requête sur le serveur... qui ne répond que
lorsqu'il a quelque chose à dire ou à demander au client. La réponse
contient une demande au client, qui re-répond en se reconnectant au
serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
Ton approche me semble être une bonne alternative au /tunneling/ que je
souhaiterais mettre en oeuvre...
Cordialement.
Merci Hervé.
Si d'autres personnes avaient des pistes... je suis toujours preneur ;)
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Il est maladroit de parler en terme de skeleton et de stub, et je ne comprends pas pourquoi tu sembles y tenir ? Normalement, skeleton et stub sont des objets que l'on n'utilise pas volontairement.
Qu'ils soient cachés à l'utilisation est une chose, mais ils seront malgré tout utilisés... Et dans mon cas, ce sont les informations d'adressages réseaux portées par le /stub/ du client, utilisé par le serveur, qui posent des problèmes.
En effet, le client étant dans un domaine d'adressage privé, le /stub/ de ce client utilisé par le serveur - qui est pour sa part dans un domaine d'adressage public - transporte des informations réseaux erronées au vue de ce serveur; le serveur ne sait pas atteindre le client. Et Malheureusement pour moi, les RMI CallBack ne résolvent pas ce problème.
Cependant, si le client initiait une connexion vers le serveur, alors le serveur aurait à sa disposition un canal de communication vers le client. Resterait alors à dérouter les requêtes du /stub/, coté serveur, vers ce canal et à faire écouté ce canal au /skeleton/, côté client.
Il y a plusieurs solutions pour cela. Moi je fais un client / serveur à l'envers : le client fait une requête sur le serveur... qui ne répond que lorsqu'il a quelque chose à dire ou à demander au client. La réponse contient une demande au client, qui re-répond en se reconnectant au serveur... Ce n'est pas très ortodoxe, mais ça marche en java 1.1.
Ton approche me semble être une bonne alternative au /tunneling/ que je souhaiterais mettre en oeuvre...
Cordialement.
Merci Hervé.
Si d'autres personnes avaient des pistes... je suis toujours preneur ;)
--
Noe
"Valdo Tschantre" a écrit dans le message de news:417ccd85$0$7069$
Ma dernière question sur les services RMI n'ayant pas eu beaucoup de succès - elle ne devait pas être très claire -, je me permet de la reposer sous une autre forme...
Peut-on : 1 - établir une connexion réseau entre un service et un client RMI, 2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Le but étant de permettre l'accès à un service RMI, tournant sur une machine ayant une /adresse privée/, à un client, tournant sur une machine ayant une /adresse publique/. Vous me direz que c'est le monde à l'envers ! Mais si je veux permettre a un serveur d'application de poser des questions à une applet, il me semble que cela pourrait être la solution... Non ?
--
Salut Valdo,
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton applet à une queue de message, ainsi lorsque le serveur a quelque chose à dire à l'applet, il poste le message, et inversement. Ca marche très bien et surtout ca permet de travailler en mode asynchrone, avec transaction et tout et tout...
Regarde activemq, il est très bon.
bigoneosix at netscape.net
"Valdo Tschantre" <valdo.tschantre@ifrance-NOSPAM.com> a écrit dans le
message de news:417ccd85$0$7069$ba620e4c@news.skynet.be...
Ma dernière question sur les services RMI n'ayant pas eu beaucoup de
succès - elle ne devait pas être très claire -, je me permet de la
reposer sous une autre forme...
Peut-on :
1 - établir une connexion réseau entre un service et un client RMI,
2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité,
3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre
extrémité ?
Le but étant de permettre l'accès à un service RMI, tournant sur une
machine ayant une /adresse privée/, à un client, tournant sur une
machine ayant une /adresse publique/. Vous me direz que c'est le monde
à l'envers ! Mais si je veux permettre a un serveur d'application de
poser des questions à une applet, il me semble que cela pourrait être la
solution... Non ?
--
valdo.tschantre@ifrance-NOSPAM.com
Salut Valdo,
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton
applet à une queue de message, ainsi lorsque le serveur a quelque chose à
dire à l'applet, il poste le message, et inversement. Ca marche très bien et
surtout ca permet de travailler en mode asynchrone, avec transaction et tout
et tout...
"Valdo Tschantre" a écrit dans le message de news:417ccd85$0$7069$
Ma dernière question sur les services RMI n'ayant pas eu beaucoup de succès - elle ne devait pas être très claire -, je me permet de la reposer sous une autre forme...
Peut-on : 1 - établir une connexion réseau entre un service et un client RMI, 2 - forcer le /skeleton RMI/, du service, d'écouter à une extrémité, 3 - forcer le /stub RMI/, du client, d'envoyer ses requêtes via l'autre extrémité ?
Le but étant de permettre l'accès à un service RMI, tournant sur une machine ayant une /adresse privée/, à un client, tournant sur une machine ayant une /adresse publique/. Vous me direz que c'est le monde à l'envers ! Mais si je veux permettre a un serveur d'application de poser des questions à une applet, il me semble que cela pourrait être la solution... Non ?
--
Salut Valdo,
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton applet à une queue de message, ainsi lorsque le serveur a quelque chose à dire à l'applet, il poste le message, et inversement. Ca marche très bien et surtout ca permet de travailler en mode asynchrone, avec transaction et tout et tout...
Regarde activemq, il est très bon.
bigoneosix at netscape.net
Valdo Tschantre
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton applet à une queue de message, ainsi lorsque le serveur a quelque chose à dire à l'applet, il poste le message, et inversement. Ca marche très bien et surtout ca permet de travailler en mode asynchrone, avec transaction et tout et tout...
Merci pour l'idée... Je vais voir ce que je peux en faire.
-- valdo DOT tschantre AT ifrance DOT com
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton
applet à une queue de message, ainsi lorsque le serveur a quelque chose à
dire à l'applet, il poste le message, et inversement. Ca marche très bien et
surtout ca permet de travailler en mode asynchrone, avec transaction et tout
et tout...
Merci pour l'idée... Je vais voir ce que je peux en faire.
essaies plutôt d'utiliser du JMS (java messaging service), tu connectes ton applet à une queue de message, ainsi lorsque le serveur a quelque chose à dire à l'applet, il poste le message, et inversement. Ca marche très bien et surtout ca permet de travailler en mode asynchrone, avec transaction et tout et tout...
Merci pour l'idée... Je vais voir ce que je peux en faire.
