Quand utiliser JMS et quand utiliser REST?
Outre la nature asynchrone/synchrone d'un problème particulier et en tenant compte du fait que les MOM (dans ce cas, ayant choisi JMS) offrent gratuitement des fonctionnalités supplémentaires comme l'équilibrage de charge et d'autres, que peut-on considérer d'autre lors du choix de JMS plutôt que REST ou vice-versa?
Merci
Utilisez toujours REST. Il s'agit de l'approche d'intégration la plus moderne, avancée et évolutive disponible à ce jour. Équilibrage de charge a REST est réalisé simplement avec l'équilibreur de charge HTTP matériel ou logiciel et peut être considéré comme aussi gratuit que l'équilibrage de charge dans JMS.
MOM (Message Oriented Middleware) ne s'adapte pas facilement (mais peut évoluer assez grand pour vos besoins). REST fonctionne à l'échelle Web.
MOM n'a pas économies d'échelle . Pour les demandes de récupération de données, chaque fois qu'une donnée particulière est demandée, un autre message doit être envoyé au serveur et répondu par le serveur. Dans un système basé sur REST, les demandes pour les mêmes données peuvent être traitées par un cache HTTP . Cela signifie qu'à mesure que le volume des demandes augmente avec le temps, une base MOM Le système verra l'augmentation de la charge du serveur au même rythme que les demandes. Un système basé sur R REST verra l'augmentation de la charge du serveur à un rythme plus lent que les demandes.
MOM vous tentera avec des messages de tir et d'oubli avec livraison garantie, seulement pour vous mordre avec le problème de chaîne de possession .
MOM est terrible pour la demande-réponse synchrone car il échouera lentement (c'est-à-dire attendre le délai d'expiration) lorsque le serveur est en panne. Lorsqu'une demande va échouer, vous voulez qu'elle échoue rapidement. Une requête HTTP à un service basé sur REST échouera immédiatement (sur la connexion TCP) si le serveur est en panne).
MOM est utile pour la messagerie asynchrone de réponse à la demande, mais vous n'aurez alors que le problème de savoir où stocker l'état entre la demande et la réponse (indice: vos options sont fichier ou base de données régulière =, le Message ou un NoSQL Database ). Souvent, l'effort supplémentaire de mise en œuvre ne vaut pas les avantages perçus de l'asynchronicité. De plus, les services basés sur REST prennent en charge les demandes asynchrones si vous en avez vraiment besoin. 202 Accepted est votre ami dans cette situation.
Enfin, l'utilisation de la mise en cache permet aux systèmes basés sur REST de mettre en œuvre des intégrations basées sur l'extraction, qui sont beaucoup plus faciles à prendre en charge. Par exemple, disons simplement que nous voulons déplacer les données du système A vers le système B. L'approche MOM serait d'envoyer des messages de A à B. A REST serait de créer un service de flux de données dans A (comme un flux RSS) que B interroge pour de nouvelles données (le de la même manière que votre lecteur RSS recherche de nouveaux articles.) En cas d'échec de B, dans l'exemple MOM, l'équipe de support devra surveiller les files d'attente de messages pour s'assurer qu'elles ne débordent pas, tandis que quelqu'un d'autre récupère le B. REST, l'équipe de support n'a qu'à s'inquiéter de récupérer B. Il n'y a pas beaucoup de différence quand A échoue. Dans l'exemple MOM, B ne sait pas et ne se soucie pas . Dans l'exemple REST B sait que A est en panne, mais il s'en fout car il n'y a évidemment pas de nouvelles données de A quand il est en panne. Initialement, l'interrogation de cette intégration basée sur l'extraction. nécessite des coutures très inefficace, mais la mise en cache HTTP en fait un non-problème.
En d'autres termes, au lieu d'investir dans un serveur JMS, investissez dans un bon équilibreur de charge HTTP de mise en cache.
Vous ne pouvez pas comparer ces deux technologies.
RESTE est un service/modèle pour vous donner un moyen organisé d'accéder à des ressources sans état.
MOM Systems/JMS est un modèle conçu pour partager des messages entre les systèmes. Il s'agit de données entrantes, de données fiables.
Vous ne pouvez pas vraiment comparer JMS à REST car ils résolvent différents problèmes.
Mais si votre question va plus dans le sens de: ai-je besoin d'une interface REST pour mes files d'attente JMS? C'est toute la situation, j'ai vu des gens utiliser REST pour protéger les clients légers de la logique nécessaire pour mettre les messages en file d'attente dans JMS. Par exemple, si vous avez un client Android qui veut parler JMS, il est beaucoup plus difficile de le faire naitvelement que de pousser les messages à un "repos" "interface qui peut ensuite traduire et pousser vers un JMS.