Bonjour,
 
J'ai un problème de conception sur une application J2EE.
 
Voila le concept.
Cette application est de type batch (dans un contexte J2EE). Elle doit envoyer énormement de données à un service. Le contrat de service de ce dernier pour répondre au contrainte du batch est de répondre à 100 requetes / sec.
Ce service est capable de répondre à cette charge mais de manière unitaire (100 personnes appellent le service).
 
Il faut donc trouver un système pour envoyer les requetes en parallèle (de manière asynchrone). Afin que la charge de traitement soit repartie sur les différents serveur du service et donc ne pas faire les requetes de manière séquentiel.
 
Dans un premier temps je me suis dit, ca c'est le travail de JMS (il est fait pour ca normalement).
Le problème vient du fait que lorsque le client (qui dans ce cas est un serveur JMS) récupère les résultats il doit être capable de les réordonner. Et la je bloque (je ne vois pas comment implémenter un service JMS à double sens avec la possibilité de synchroniser les données).
 
Est ce que quelqu'un aurait une solution concrète à me donner?
 
Merci d'avance pour vos pistes.

marrant ton problème.
En fait à un moment tu est "désynchronisé (tes commandes sont indépendantes?) mais tu veux quand même pouvoir les "réordonné"? c'est pour retrouver le contexte du client? Si c'est le cas généralement on met un identifiant au messages, et quand on récupère la réponse on retrouve le contexte...
 
des pistes:
Utiliser un pool de connections, dédier à chaque requètes (par exemple spring executor fait ça bien :  
http://static.springframework.org/ [...] uling.html
 
Utiliser une librairie de type mina ( http://mina.apache.org/ ) pour faire de l'asyncrhone mais avoir le contexte par client

Bonjour Tempo14,
 
Merci pour ta réponse. La demande initiale est de pouvoir traiter un grand nombre de demande dans une plage horaire établie. Dans l'absolu la création de threads aurait pu etre une solution. Mais c'est plus que déconseillé dans un container J2EE (c'est au container de pouvoir gérer les Threads et non à l'applicatif).
C'est pour cela que je suis partie sur l'utilisation des JMS (premiere chose qui m'est venu à l'esprit). Maintenant le problème de JMS est le fait que l'on par dans de l'asynchronisme et donc pour réordonner les retours, je ne vois pas trop comment cela peut se faire (je pense que ce n'est pas possible).
 
Je vais voir Spring, et j'ai vu d'ailleurs dans leur article qu'ils parlent de commonJ (dont j'avais entendu parlé) mais qui me semble peu mature et moins standard.

Tu cherches à avoir des connexions en parallèle car sinon la transmission est trop lente ? tu utilises quoi comme techno ? web service ? Avec axis2 et des soap de quelques ko tu atteind facilement 100 requetes/ secondes.

 
Bonjour bugsan,
 
Il ne sagit pas de temps de connection (au sens acces réseau) mais de temps de traitement (un requete prend un certain temps de traitement incompresible).  Que cela soit du Web service ou de l'EJB (ou même du traitement local) ne change pas le probleme (modulo de tps d'execution du protocole).
 
Finalement une solution CommonJ semble être la meilleure solution, car c'est du multithreading mais c'est géré par le containeur (WorkManager). C'est la solution "ultime" qui devrait d'ailleurs être intégré (à l'avenir je l'espere) à la spécification JEE pour faire du multithreading de manière correcte dans une application JEE.