[Réseau]Architecture d'une appli distribuée

Bonjour,

je souhaite réaliser une application qui est composée de différents modules réparties sur plusieurs PC.

Un premier module doit acquérir l'image d'une caméra IP, puis passer cette image à un module de traitement, qui par exemple inversera cette image.

Je me pose 2 questions :
1. Comment passer mon image à mon 2e module?
2. Comment vérifier que mon 2e module n'est pas occupé (en train d'effectuer un traitement) ?

Je pense utiliser RMI pour communiquer entre les modules, le 1er module appelant une méthode remote du 2e avec en paramètre l'image acquise (si elle est sérialisable).

Seulement pour vérifier si le 2e module est prêt, comment faire ? Car il peut traiter uniquement une image à la fois. Mes modules doivent-ils être des threads afin de pouvoir contrôler si ils "tournent" ou pas ?

Voilà j'aimerais vos avis sur la stratégie à adopter.
Merci d'avance, car je suis un peu à la bourre pour ce projet ;-)


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

Hello,

Une reponse rapide..

Concernant la notion d'information entre tes differents module regarde du coté de JMS... je pense que cela peut repondre à ton besoin!

Pour une architecture distruber regarde du coté des EJBs...

Voila j'espere que c pistes t'aideront!

Merci de ta réponse.

Cependant, j'aimerais rester dans J2SE

Hello,

Tu entends par J2SE un client lourd? (swing), si c le cas ce n'est pas incompatible .. notamment pour les EJBs... tu peux avoir un conteneur d'EJB qui tourne au meme titre qu'une Registry en RMI (remarque les EJb s'appuie sur le RMI)..

heu... ça ne me semble pas vraiment adapté les ejb... si on est pas dans un contexte qui le demande vraiment mieux vait s'en passer...et puis c assez lourd a mettre en oeuvre qd meme, il va faloir un serveur d'application juste pour faire tourner un mdb sur une queue jms...bof :-) c plus adapté dans les gros process business à accès concurents (et encore...)

Ce qui me semble plus adapté peut-être, serait de recréer un genre de queue fifo, du coté de ton serveur, à l'aide d'un arraylist ou un truc du genre, ou tu pourrais 'entasser' tes images en attente de traitement que le serveur pourrait traiter quand il le pourrait...
Mais il faut aussi voir si tu désire travailler en asynchrone (tu te fiche de quand tu auras la réponse du serveur) ou en synchrone (tu postes et tu attends que le serveur ait fini le traitement pour récupérer le résultat)...

Enfin c mon point de vue hein :-) ça marchera aussi avec des jms et consort et tu apprendras ptet de nouvelles choses mais... :-)

Les EJBs, il faut les utiliser quand on en a besoin (un peu comme tout). Et il se trouve qu'en fait, on en a très rarement besoin... (un peu comme Oracle, 90% des fois, postgres suffit...).

Pour une archi distribuée, dans le plus proche de J2SE, tu as RMI.
Bon courage.

amen :wink:

ok merci, je pense que je vais faire une pile FIFO et travailler de manière asynchrone ce sera plus simple. Ca m'évitera de devoir contrôler si un serveur est dispo ou pas.

Juste encore une ptite question, c'est possible de contrôler si une tâche est en cours d'exécution ? ( thread ??)

heu... ben ui :-)
tu peux imaginer lancer le traitement dans un thread et faire une méthode qui te renvois un booléen qui est mis a jour qd le thread se termine et que tu peux questionner en même tps que l'exécution de la tâche