Version imprimable
j'en ai pas sous la main, mais c'est pas compliqué
en .NET tu écrit dans la sortie standard, tu lit depuis l'entrée standard
en java, tu fais pareil sur les input/ouputStream de l'objet Process que tu obtien en lançant l'application .NET
Et c'est parti, t'as un flux binaire à double sens entre les deux application, reste plus qu'à l'utiliser
C'est quelque chose de très courant en tout cas sous linux de faire ce genre de chose pour réutiliser une application existante
Si tu utilises les entrées/sorties standards, tu ne risques pas d'avoir des conflits avec d'autres applications qui les utilisent aussi ?Citation:
Envoyé par tchize_
Dans ce cas là, il faudrait que la partie .NET fasse le rôle de serveur et ne saurait pas quand elle doit lire l'entrée standard car elle ne sait pas quand une appli va se connecter à elle.
houlà:
la partie .net est lancée par chaque application java qui en a besoin (tu nous a clairement dit que tu ne voulais pas que ce soit un serveur), donc je vois pas ce que cette histoire de serveur viens faire là dedans.
Tu application .net va effectivement avoir un Thread qui lit sur l'inputstream, traite le message, et renvoie la réponse vers l'outputstream.
Chaque application a sa propre entrée standard, donc non tu n'aura pas de conflit avec les autres applications puisqu'elles ne rentrent pas dans ce système.
Quand sous linux, je faire un
C'est exactement ce que je fais, je prend la sortie standard de ls, et je l'envoie dans l'entrée standard de grep. Dans ton cas, tu va juste avoir ça en double sens.Code:ls *.java | grep Impl
http://java.developpez.com/faq/java/...icationExterne
Je voulais dire que la partie .NET devrait dans ce cas comme un serveur, en attente qu'un client se connecte dessus. On a donc le problème du fait qu'on ne sait pas quand on doit lire l'entrée standard, à moins de faire une attente active qui lit ce qui se passe toutes les secondes par exemple, mais ce n'est pas forcément conseillé.Citation:
Envoyé par tchize_
A moins que la lecture attende que qqch arrive.
Ce qui veut dire que je dois relier la partie .NET à l'entrée/sortie standard de l'application Java pour que ça fonctionne ?Citation:
Envoyé par tchize_
comme je l'ai dit, ton .net n'est pas un serveur mais une application à part entière, lancée en soutien de l'application java. Ce n'est pas bien différente que si l'application java, tout d'un coup, lancait les processus "ls" poru récupérer le contenu d'un dossier ou "cdrdao" pour graver un disque. La seul particularité c'est que l'application .net lira sur l'entrée standard jusuqu'à ce qu'on la tue. Il y aura donc une application .net par application java qui l'utilise, lancée par l'application java, tuée par l'application java ;)
Petit tutoriel:
http://ydisanto.developpez.com/tutoriels/j2se/runtime/
Merci pour votre aide, je suis en train de faire des tests sur cette solution pour voir si ça fonctionne bien. :ccool:
Bonjour,
en fait cette solution est difficilement viable car tout ne passe qu'en string entre les 2 applications sans pouvoir définir de protocole de communication.
En effet, cela signifie qu'il faut recréer les classes en Java, on peut imaginer qu'on a une désérialisation/sérialisation des objets en string, mais ensuite, il faut tout de même synchroniser toutes les propriétés de chaque objet.
Je m'explique, on a par exemple un objet a du type A et un objet b du type B (qui possède une propriété Taille), chacun possède une référence vers l'autre.
On appelle une méthode de l'objet a qui va incrémenter la taille de l'objet b, puis on souhaite afficher la taille de l'objet b.
On ne doit pas pouvoir la valeur stockée en local mais bien récupérer la valeur dynamiquement via la communication en stream entre les 2 applications.
Il faut donc que les propriétés ne soient pas stockées dans l'application Java mais aient des get et set qui communiquent en streaming avec l'autre application. Donc utiliser un identifiant unique par exemple afin que l'application distante sache quel objet demande la valeur d'une propriété.
Enfin, je pense que cette solution serait difficilement maintenable et viable, je suis donc toujours à la recherche d'une bonne solution.
Les entrées sortie sont des streams, ca ne change rien par rapport à l'utilisation d'un socket, tu peux très bien faire du binaire dessus. Si tu te limite en String, c'est parce que tu l'a choisiCitation:
Envoyé par WebPac
Que tu le face là ou dans ton connecteur JNI qui ferait l'hypothétique interfaceage, tu devra le faire ;). Les objet .NEt ne sont pas des objet Java, quoi qu'il arrive. Ils ne sont par traités par la même VM ni par le même système de garbage collection.Citation:
En effet, cela signifie qu'il faut recréer les classes en Java, on peut imaginer qu'on a une désérialisation/sérialisation des objets en string, mais ensuite, il faut tout de même synchroniser toutes les propriétés de chaque objet.
Il reste plus que le CORBA et deux application séparée, c'est le seul protocole objet que je connaisse qui soit indépendant du language.Citation:
Enfin, je pense que cette solution serait difficilement maintenable et viable, je suis donc toujours à la recherche d'une bonne solution.
En effet, mais ça reste qu'on n'utilise que des types primaires, string, int, float. Et il faut qu'on le gère à la main.Citation:
Envoyé par tchize_
Tout à fait, mais dans ce cas, on n'a pas besoin de gérer comment la communication se fait.Citation:
Envoyé par tchize_
En fait, j'ai une mauvaise expérience où il fallait faire communiquer 2 applications en TCP/IP, donc en string et autres types primaires et l'évolution des applications avec gestion de la compatibilité des versions précédentes était une véritable galère et je ne souhaite pas devoir le refaire.
Je ne connais pas CORBA mais je vais me renseigner dessus quand j'aurai le temps.Citation:
Envoyé par tchize_