soient deux serveurs (J2EE) S1 et S2 dialoguant entre eux selon le
protocole HTTP.
Pour des raisons de volonté de changement de protocole entre eux et ne
désirant pas réécrire tout le code de dialogue existant, je cherche des
infos sur la réalisation d'une passerelle HTTP --> RMI sur S1 et son
équivalent RMI --> HTTP sur S2.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Il va de soi que j'ai regardé sur Google mais rien trouvé de bien
probant sur une passerelle de ce type.
D'autre part, la remarque consistant à faire un changement de protocole
en HTTPS est tout à fait recevable mais ne fait pas l'objet de mon
propos...;-)
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
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets.
Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Etc.
-- Hervé AGNOUX http://www.diaam-informatique.com
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux,
et RMI un échange d'objets, il faut je pense placer vos flux dans un objet.
L'objet le plus simple adapté est un tableau d'octets.
Cela signifie qu'il faudra un coté client avec un objet qui simule être un
client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela
vous fera de gros tableaux d'octets.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets.
Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Etc.
-- Hervé AGNOUX http://www.diaam-informatique.com
Cenekemoi
Bonjour à Hervé AGNOUX qui
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets. Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
-- Cordialement, Thierry ;-)
Bonjour à Hervé AGNOUX <herve.xx.agnoux@diaam-informatique.com.zz> qui
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de
flux, et RMI un échange d'objets, il faut je pense placer vos flux
dans un objet. L'objet le plus simple adapté est un tableau d'octets.
Cela signifie qu'il faudra un coté client avec un objet qui simule
être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros,
sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un
StringBuffer ?
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets. Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
-- Cordialement, Thierry ;-)
ownowl
Bonjour à Hervé AGNOUX qui
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets. Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
si les flux ne doivent pas être trop gros il est tout à fait possible de compresser. Sachant que ca a un coup au niveau cpu, mais ca divise le flux par 2 ou 3. A utiliser si le maillon faible est plutot le reseau.
Olivier
Bonjour à Hervé AGNOUX <herve.xx.agnoux@diaam-informatique.com.zz> qui
Cenekemoi wrote:
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de
flux, et RMI un échange d'objets, il faut je pense placer vos flux
dans un objet. L'objet le plus simple adapté est un tableau d'octets.
Cela signifie qu'il faudra un coté client avec un objet qui simule
être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros,
sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un
StringBuffer ?
si les flux ne doivent pas être trop gros il est tout à fait possible de
compresser. Sachant que ca a un coup au niveau cpu, mais ca divise le
flux par 2 ou 3. A utiliser si le maillon faible est plutot le reseau.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Moi je n'ai pas des liens, mais une opinion. HTTP étant un échange de flux, et RMI un échange d'objets, il faut je pense placer vos flux dans un objet. L'objet le plus simple adapté est un tableau d'octets. Cela signifie qu'il faudra un coté client avec un objet qui simule être un client HTTP, et assimilé coté serveur.
La condition est que les flux à échanger ne soient pas trop gros, sinon cela vous fera de gros tableaux d'octets.
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
si les flux ne doivent pas être trop gros il est tout à fait possible de compresser. Sachant que ca a un coup au niveau cpu, mais ca divise le flux par 2 ou 3. A utiliser si le maillon faible est plutot le reseau.
Olivier
Cenekemoi
Bonjour à Hervé AGNOUX qui
Cenekemoi wrote:
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus proche d'un flux. Si tu as des contraintes de taille il me semble qu'il serait prudent de revoir un peu l'architecture pour le passage HTTP -> RMI, au moins pour les niveaux proches du dialogue. Mais j'ai l'impression que tu ne veux pas ?...
Ce que je veux n'a que peu d'importance. Je pense même que simplement un passage HTTP <--> HTTPS est suffisant. Non, le problème est que mon "client" y tient...quitte à changer de fusil d'épaule si les performances ne suivent pas.
En attendant je dois faire ce développement et demande toujours de l'aide pour toute info ;-)
-- Cordialement, Thierry
Bonjour à Hervé AGNOUX <herve.xx.agnoux@diaam-informatique.com.zz> qui
Cenekemoi wrote:
Est-ce qu'un tableau d'octets prend moins de place qu'une String ?
qu'un StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus
proche d'un flux. Si tu as des contraintes de taille il me semble
qu'il serait prudent de revoir un peu l'architecture pour le passage
HTTP -> RMI, au moins pour les niveaux proches du dialogue. Mais j'ai
l'impression que tu ne veux pas ?...
Ce que je veux n'a que peu d'importance. Je pense même que simplement un
passage HTTP <--> HTTPS est suffisant.
Non, le problème est que mon "client" y tient...quitte à changer de
fusil d'épaule si les performances ne suivent pas.
En attendant je dois faire ce développement et demande toujours de
l'aide pour toute info ;-)
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus proche d'un flux. Si tu as des contraintes de taille il me semble qu'il serait prudent de revoir un peu l'architecture pour le passage HTTP -> RMI, au moins pour les niveaux proches du dialogue. Mais j'ai l'impression que tu ne veux pas ?...
Ce que je veux n'a que peu d'importance. Je pense même que simplement un passage HTTP <--> HTTPS est suffisant. Non, le problème est que mon "client" y tient...quitte à changer de fusil d'épaule si les performances ne suivent pas.
En attendant je dois faire ce développement et demande toujours de l'aide pour toute info ;-)
-- Cordialement, Thierry
Hervé AGNOUX
Cenekemoi wrote:
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus proche d'un flux. Si tu as des contraintes de taille il me semble qu'il serait prudent de revoir un peu l'architecture pour le passage HTTP -> RMI, au moins pour les niveaux proches du dialogue. Mais j'ai l'impression que tu ne veux pas ?...
-- Hervé AGNOUX http://www.diaam-informatique.com
Cenekemoi wrote:
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un
StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus
proche d'un flux. Si tu as des contraintes de taille il me semble qu'il
serait prudent de revoir un peu l'architecture pour le passage HTTP -> RMI,
au moins pour les niveaux proches du dialogue. Mais j'ai l'impression que
tu ne veux pas ?...
Est-ce qu'un tableau d'octets prend moins de place qu'une String ? qu'un StringBuffer ?
Probablement.
(excusez la réponse de normand :-)
J'avais parlé du tableau d'octets parce que c'est ce qu'il y a de plus proche d'un flux. Si tu as des contraintes de taille il me semble qu'il serait prudent de revoir un peu l'architecture pour le passage HTTP -> RMI, au moins pour les niveaux proches du dialogue. Mais j'ai l'impression que tu ne veux pas ?...
-- Hervé AGNOUX http://www.diaam-informatique.com
fabrice-pas-despame.bacchella
On Thu, 6 Apr 2006 13:51:46 +0200, "Cenekemoi" wrote:
Ce que je veux n'a que peu d'importance. Je pense même que simplement un passage HTTP <--> HTTPS est suffisant. Non, le problème est que mon "client" y tient...quitte à changer de fusil d'épaule si les performances ne suivent pas.
Il tiens à quoi ? Au port 80 ou au protocole HTTP ? Parce qu'il est toujours possible de faire de RMI sur le port de son choix, sans rmid & autre rmiregistry. Après si effectivement faut traverser des proxy http, c'est moins drôle.
On Thu, 6 Apr 2006 13:51:46 +0200, "Cenekemoi" <thierry@no.spam>
wrote:
Ce que je veux n'a que peu d'importance. Je pense même que simplement un
passage HTTP <--> HTTPS est suffisant.
Non, le problème est que mon "client" y tient...quitte à changer de
fusil d'épaule si les performances ne suivent pas.
Il tiens à quoi ? Au port 80 ou au protocole HTTP ? Parce qu'il est
toujours possible de faire de RMI sur le port de son choix, sans rmid
& autre rmiregistry. Après si effectivement faut traverser des proxy
http, c'est moins drôle.
On Thu, 6 Apr 2006 13:51:46 +0200, "Cenekemoi" wrote:
Ce que je veux n'a que peu d'importance. Je pense même que simplement un passage HTTP <--> HTTPS est suffisant. Non, le problème est que mon "client" y tient...quitte à changer de fusil d'épaule si les performances ne suivent pas.
Il tiens à quoi ? Au port 80 ou au protocole HTTP ? Parce qu'il est toujours possible de faire de RMI sur le port de son choix, sans rmid & autre rmiregistry. Après si effectivement faut traverser des proxy http, c'est moins drôle.
TestMan
Bonjour,
En cas d'indisponibilité du port RMI entre deux machine, l'implementation de Sun bascule automatiquement en HTTP, il suffit d'avoir coté serveur un point d'entré HTTP comme par exemple la servlet
soient deux serveurs (J2EE) S1 et S2 dialoguant entre eux selon le protocole HTTP.
Pour des raisons de volonté de changement de protocole entre eux et ne désirant pas réécrire tout le code de dialogue existant, je cherche des infos sur la réalisation d'une passerelle HTTP --> RMI sur S1 et son équivalent RMI --> HTTP sur S2.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Il va de soi que j'ai regardé sur Google mais rien trouvé de bien probant sur une passerelle de ce type.
D'autre part, la remarque consistant à faire un changement de protocole en HTTPS est tout à fait recevable mais ne fait pas l'objet de mon propos...;-)
Bonjour,
En cas d'indisponibilité du port RMI entre deux machine,
l'implementation de Sun bascule automatiquement en HTTP, il suffit
d'avoir coté serveur un point d'entré HTTP comme par exemple la servlet
soient deux serveurs (J2EE) S1 et S2 dialoguant entre eux selon le
protocole HTTP.
Pour des raisons de volonté de changement de protocole entre eux et ne
désirant pas réécrire tout le code de dialogue existant, je cherche des
infos sur la réalisation d'une passerelle HTTP --> RMI sur S1 et son
équivalent RMI --> HTTP sur S2.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Il va de soi que j'ai regardé sur Google mais rien trouvé de bien
probant sur une passerelle de ce type.
D'autre part, la remarque consistant à faire un changement de protocole
en HTTPS est tout à fait recevable mais ne fait pas l'objet de mon
propos...;-)
En cas d'indisponibilité du port RMI entre deux machine, l'implementation de Sun bascule automatiquement en HTTP, il suffit d'avoir coté serveur un point d'entré HTTP comme par exemple la servlet
soient deux serveurs (J2EE) S1 et S2 dialoguant entre eux selon le protocole HTTP.
Pour des raisons de volonté de changement de protocole entre eux et ne désirant pas réécrire tout le code de dialogue existant, je cherche des infos sur la réalisation d'une passerelle HTTP --> RMI sur S1 et son équivalent RMI --> HTTP sur S2.
Auriez-vous, SVP, des liens ou autres à ce sujet ?
Il va de soi que j'ai regardé sur Google mais rien trouvé de bien probant sur une passerelle de ce type.
D'autre part, la remarque consistant à faire un changement de protocole en HTTPS est tout à fait recevable mais ne fait pas l'objet de mon propos...;-)
