Utiliser JMS (OpenMQ) avec le serveur deconnecté

**psecheresse** · 02/10/2009, 23h49

J'aimerais utiliser JMS dans un client Java SE pour envoyer des informations a un serveur JavaEE en utilisant une connexion Internet. Par definition, Internet n'est pas fiable et il arrive que la connexion soit interrompue pendant des semaines. Le probleme est que je dois obtenir la queue avec JNDI donc avec RMI si j'utilise GlassFish/OpenMQ.
- Existe-t-il un moyen d'utiliser une queue JMS avec un serveur Java EE meme si le serveur n'est pas disponible au demarrage?
- Cela peut-il fonctionner en utilisant HTTP comme protocole
- Que se passe-t-il si le client est arrete et que des messages sont en attente dans la queue?

**bdidier** · 03/10/2009, 20h44

bonjour,

qqs mots en préambule,

je trouve qu'internet est plutot fiable , étant donné la somme de services rendus et le nombre de messages échangés ...

ce qui est moins fiable, c'est le service de terminaison (last miles) et parfois (trops souvent) le service final (ce qui l'y a derrière le end-point)

pour rendre ce service JMS le plus fiable possible

- on le rend indépendant du serveur d'application : service JMS REMOTE dans glassfish: le service JMS est disponible en consommation et production de messages
- on met ce service en haute disponibilité (cluster logiciel de broker JMS) (fonction disponible depuis fort longtemps)
- si le broker (ou les brokers) ne sont pas joignables en tcp, aucun message ne partira (pas de local store temporaire coté client) - reste a ce moment le telegramme ou le satellite selon le budget disponible

- on peut utiliser une factory JNDI non basée sur celle de glassfish, en
configurant une factory de type fichier (fscontext), disponible localement "près" du client fournissant les objets dits "administrés

- le protocole jms est connecté (protocole proprietaire sur tcp/tls) donc une alternative a la mode pour le WAN ( si le brin de cuivre casse chez vous !)
est d'utiliser une passerellle OpenMQ/ UMS basée sur HTTP qui fourni une semantique jms encapsulée sur http (https://mq.dev.java.net/4.3-content/ums/umsIntro.html) - en fait c'est plus utilisé pour passer les firewall ou etre utilisé avec les clients .net,

le client OpenMQ dispose de mecanisme de reprise appelé client fail-over en œuvre sur pas mal de sites qui fait l'affaire (en prod en ce moment

(mecanisme de base sans http)

- si le client est arrêté, les messages restent sagement dans le broker JMS (memoire ou message store, selon l'option de persistence) en attendant d'tre consommés; le broker peut "basculer" le message dans une "dead message queue" au bout d'un certain temps pour eviter un engorgement ou permettre une prise de decision exceptionnelle par un consommateur dédié a ces messages en "vie de garage"

qqs pointeurs