Outre la nature asynchrone/synchrone d'un problème particulier et compte tenu du fait que les MOM (dans ce cas, ayant choisi JMS) offrent gratuitement des fonctionnalités supplémentaires comme l'équilibrage de la charge et autres, que peut-on considérer d'autre lorsqu'on choisit JMS plutôt que REST ou vice-versa ?
Gracias
Utilisez toujours REST. Il s'agit de l'approche d'intégration la plus moderne, la plus avancée et la plus évolutive disponible aujourd'hui. L'équilibrage de charge d'un service basé sur REST est réalisé simplement avec un équilibreur de charge HTTP matériel ou logiciel et peut être considéré comme aussi libre que l'équilibrage de charge en JMS.
MOM (Middleware orienté message) n'est pas facilement modulable (mais peut l'être suffisamment pour répondre à vos besoins). REST fonctionne à l'échelle du web.
MOM n'a pas économies d'échelle . Pour les demandes d'extraction de données, chaque fois qu'un élément de données particulier est demandé, un autre message doit être envoyé au serveur et ce dernier doit y répondre. Dans un système basé sur REST, les demandes pour les mêmes données peuvent être satisfaites par une Cache HTTP . Cela signifie que lorsque le volume des demandes augmente au fil du temps, un système basé sur MOM verra la charge du serveur augmenter au même rythme que les demandes. Un système basé sur REST verra la charge du serveur augmenter à un rythme plus lent que les demandes.
MOM vous tentera avec des messages de type "feu et oublie" avec une livraison garantie, pour ensuite vous mordre avec le le problème de la chaîne de contrôle .
MOM est terrible pour les requêtes-réponses synchrones car il échouera lentement (c'est-à-dire qu'il attendra le timeout) lorsque le serveur est hors service. Lorsqu'une requête doit échouer, vous voulez qu'elle échoue rapidement. Une requête HTTP vers un service REST échouera immédiatement (sur la connexion TCP) si le serveur est en panne.
MOM est utile pour la messagerie asynchrone de type demande-réponse, mais vous serez alors confronté au problème de savoir où stocker l'état entre la demande et la réponse (indice : vos options sont les suivantes Fichier ou base de données régulière le Message ou un Base de données NoSQL ). Souvent, l'effort supplémentaire de mise en œuvre ne vaut pas les avantages perçus de l'asynchronisme. Les services basés sur REST prennent également en charge les requêtes asynchrones si vous en avez vraiment besoin. 202 Accepté 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 la traction, qui sont beaucoup plus faciles à prendre en charge. Par exemple, disons que nous voulons déplacer des données d'un système A vers un système B. L'approche MOM consisterait à envoyer des messages de A vers B. Une approche basée sur REST consisterait à créer un service de flux de données dans A (comme un flux RSS) que B interrogerait pour obtenir de nouvelles données (de la même manière que votre lecteur RSS interroge pour obtenir de nouveaux articles). Lorsque B tombe en panne, 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, pendant que quelqu'un d'autre remet B en état. Dans l'exemple REST, l'équipe de support doit simplement se préoccuper de la remise en service de B. Il n'y a pas beaucoup de différence lorsque A échoue. Dans l'exemple MOM, B ne le sait pas et s'en moque. Dans l'exemple REST, B sait que A est en panne, mais il ne s'en soucie toujours pas, car il est évident qu'il n'y a pas de nouvelles données provenant de A lorsqu'il est en panne. Au départ, l'interrogation que nécessite l'intégration basée sur les flux tirés semble très inefficace, mais la mise en cache HTTP permet d'éviter ce problème.
En d'autres termes, au lieu d'investir dans un serveur JMS, investissez dans un bon équilibreur de charge HTTP avec mise en cache.
Vous ne pouvez pas comparer ces deux technologies.
REST est un service/modèle qui vous donne un moyen organisé d'accéder à des ressources sans état.
Systèmes MOM/JMS est un modèle conçu pour le partage de messages entre systèmes. Il s'agit de données entrantes et sortantes de manière fiable.
Vous ne pouvez pas vraiment comparer JMS à REST car ils résolvent des problèmes différents.
Mais si votre question est plutôt du type "Ai-je besoin d'une interface REST pour mes files d'attente JMS ? Tout dépend de la situation. J'ai vu des gens utiliser REST pour protéger les clients légers de la logique nécessaire à la mise en file d'attente des messages dans JMS. Par exemple, si vous avez un client Android qui veut parler JMS, il est beaucoup plus difficile de le faire naïvement que de pousser les messages vers une interface "rest" qui peut ensuite traduire et pousser vers un JMS.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
