Discussion :

[tiboudchou]

Bonjour à tous,

J'ai deux programmes Java qui doivent entrer en communication :

1. Une application J2EE
2. Un programme Java qui exécute un traitement

L'appli J2EE doit appeler le programme Java en lui passant une map d'objets Java.
Le programme Java retourne un fichier.

Bon vous voyez, le traitement est assez simple.
Du coup, je suis entrain de me demander quelle est la meilleure technologie à utiliser :

1. HTTP (mettre le programme Java dans une Servlet). Mais pourquoi créer un contexte Web alors qu'il n'y en a pas besoin ?
2. RMI. N'est-ce pas de la grosse artillerie pour pas grand chose ?
3. WebServices. Pas trop la meilleure solution pour transférer des fichiers...
4. Autres ?

De part vos expériences, que me conseillez-vous ?

Contrainte supplémentaire : il faudra que l'architecture mise en place supporte un système de Load Balancing.

Merci pour vos avis éclairés.

[gifffftane]

Perso le 1 (servlet coté serveur, n'importe quoi coté client) me semble la meilleure solution.

Sur cette base, tu peux dériver soit un service web (on peut finasser sur les termes, mais il n'y a pas forcément un site web associé à une servlet) avec Rest ou autre.

Le défaut est que cela t'oblige à mapper les objets ; il y a différentes techniques déjà prêtes comme Jaxb, ou si tes objets sont simples avec des Properties.

Je préfère cette approche à RMI à cause que RMI utilise un port particulier, et que un jour ou l'autre tu te retrouves coincé avec les us et coutumes des responsables sécurité, qui laissent tout passer par le port 80 et rien ou presque par les autres, comprenne qui pourra. Il y a certes le RMI over HTTP mais là tu retombes pratiquement sur la solution 1.

Tu peux également, sous l'empire de la dogme simplicité, considérer que le protocole est hyper simple et que le HTTP est trop lourd compliqué, et faire tout à l'arrache avec pas de protocole du tout ou quasi, mais un jour ou l'autre tu te retrouves coincé par des bugs bizarres ; au moins avec la solution 1 rien ou presque ne peut t'arriver de ce coté là.

S'il s'agit juste de transférer des fichiers, tu peux également te baser sur un serveur FTP coté serveur.

[tiboudchou]

Merci pour ta réponse.

Je vais en effet me diriger vers la solution 1. Servlet.
Reste à voir comment passer mes objets Java en paramètre du post http

[gifffftane]

Comme je t'ai dit, c'est le mapping ; à ce niveau là, tu peux même utiliser la sérialization, ou jaxb, ou etc tout est possible, l'imagination est au pouvoir !

[tiboudchou]

Cela m'ennuie tout de même d'utiliser une servlet Web pour un programme qui n'a aucunement besoin du contexte Web

Solution 5. Communication Socket.
Un avis la dessus ?

[gifffftane]

Pour le mapping il y a tellement de choses à prendre à considération que, en l'état de ce que tu nous dis, il m'est difficile de te conseiller autre chose que Renseigne-toi à droite et à gauche !.

Pour la requête HTTP, il faut utiliser HTTPClient. Le faire avec le JDK seul revient à faire une thèse. Mais cela dépend de tes outils de mapping, car il y a quelques fois des fonctions http avec (souvent basées sur httpclient, d'ailleurs).

Coté serveur, tu peux utiliser jetty, si tu considères que tomcat est trop gros.

[tiboudchou]

Ah zut, tu as répondu pendant que je mettais à jour mon message.
Merci pour les renseignements pour la solution servlet.

Je t'invite à lire mon dernier message que j'ai donc édité. Cela concerne la solution "Socket" pour éviter de passer par un contexte web inutile.

[gifffftane]

Oui, oui, j'ai vu j'ai vu

Et bien, si le contexte web est inutile, quel est le problème ?... Par socket c'est très simple : tu ouvres ta socket des deux cotés, tu envoies des données... il y a des write, des read... et même plein d'exemples sur le web. C'est le même principe que lire / écrire un fichier. Que faut-il de plus ?

Bon courage.

[tiboudchou]

Je vais essayer ça