Plusieurs instances d'une application Web Java partageant une ressource

Question

J'ai un service Web, qui prend un message xml d'entrée, le transforme, puis le transmet à un autre service Web.

L'application est déployée sur deux serveurs d'applications de logique Web pour des raisons de performances et de résilience.

Je voudrais une page unique de suivi de site Web qui permet deux choses

• capacité d'arrêt/démarrage transmission des messages

• capacité à contrôler le débit du nombre de messages dans la dernière heure, etc. Nombre d'expéditeurs différents dans le service Web, etc.

Je me demandais quelle était la meilleure façon de l'implémenter. Mon idée actuelle est d'avoir une base de données en mémoire (par exemple Debry ou HSQL) qui réplique des données pour partager les informations entre les deux (ou plus) instances de mon application qui s'exécutent dans différentes instances du serveur d'applications. J'imagine que je devrais configurer une sorte de configuration maître/esclave.

J'aimerais un lien vers un article qui explique comment résoudre ce problème.

(Notez que ceci est une simple application de ressort à l'aide Spring MVC)

merci,

David.

Answer 1

On dirait que vous êtes à la recherche d'une file d'attente de messages, de certains MDB et d'un design configurable vous permettant de faire tout cela. Spring a un support pour JMS Queues si je ne me trompe pas

Answer 2

Cela sonne comme un bon match pour Java Management Extensions (JMX)

• JMX vous permet d'exposer certaines opérations (par exemple: démarrage/arrêt Transfert de messages)
• JMX vous permet de surveiller certains indicateurs de performance (par exemple: moyenne mobile des messages traités)

Printemps a un bon support pour exposer les beans comme MBeans JMX. Voir here pour plus d'informations.

Ensuite, vous pouvez utiliser une console JMX Web open-source, comme jManage

Hope this helps.

Answer 3

Je pense que vous recherchez une file d'attente de messages. Si vous avez besoin d'une surveillance supplémentaire, l'utilisation d'un service Web comme point final peut ne pas suffire - en ce qui concerne l'arrêt/le démarrage ou la transmission de messages; La surveillance des requêtes http vers le service Web est plus lourde que le suivi des messages dans une file d'attente (même si vous pouvez le faire).

Si vous exposez ce service à un tiers, le service Web sera placé au-dessus de la file d'attente de messages et lui sera délégué. Dans mon expérience, RabbitMQ est un service de file d'attente de messagerie fine avec une courbe d'apprentissage relativement simple.