Quand utiliser JMS et quand utiliser REST? [fermé]

toujours se reposer. Il s'agit de l'approche d'intégration la plus moderne, la plus évoluée et la plus évolutive disponible aujourd'hui. L'équilibrage de charge un service basé sur le repos est réalisé simplement avec le matériel ou le logiciel HTTP load balancer et peut être considéré tout aussi libre que l'équilibrage de charge dans JMS.

maman (Middleware Orienté Message) ne se dimensionne pas facilement (mais peut se dimensionner assez pour vos besoins). Le repos fonctionne à l'échelle du web.

maman 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 celui-ci. Dans un système basé sur le repos, les demandes pour les mêmes données peuvent être traitées par un cache HTTP. Cela signifie qu'à mesure que le volume de requêtes augmente avec le temps, un système basé sur MOM verra la charge du serveur augmenter au même rythme que les requêtes. Un système basé sur le repos verra l'augmentation de la charge du serveur à un rythme plus lent que le demande.

maman vous tentera avec des messages de feu et d'oubli avec une livraison garantie, seulement pour vous mordre avec le chaîne de problème de garde.

MOM est terrible pour la requête-réponse synchrone car elle échouera lentement (c'est-à-dire qu'elle attendra l'expiration du délai) lorsque le serveur est en panne. Quand une requête va échouer, vous voulez qu'elle échoue rapidement. Une requête HTTP vers un service basé sur le repos échouera immédiatement (sur la connexion TCP) si le serveur est en panne.

maman est utile pour la messagerie asynchrone request-reply, mais il vous restera le problème de savoir où stocker l'état entre la requête et la réponse (indice: vos options sont fichier ou base de données régulière, le Message et NoSQL Database). Souvent, l'effort supplémentaire de mise en œuvre ne vaut pas les avantages perçus de l'asynchronisme. Les services basés sur le repos 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 d'implémenter des intégrations basées sur pull, qui sont beaucoup plus faciles à prendre en charge. Par exemple, il suffit de dire 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 vers B. Une approche basée sur le repos serait de créer un service de flux de données dans A (comme un flux RSS) que b recherche pour de nouvelles données (de la même manière que votre lecteur RSS recherche pour de nouveaux articles). Quand B échoue, dans la mère par exemple, l'équipe de soutien devra surveiller les files d'attente de messages pour s'assurer qu'elles ne débordent pas, pendant que quelqu'un d'autre récupère son B. Dans l'exemple du reste, l'équipe de soutien n'a qu'à s'inquiéter de récupérer B. Il n'y a pas beaucoup de différence quand Un échec. Dans L'exemple de la mère B ne sait pas et ne s'en soucie pas. Dans le reste de L'exemple B sait que A est en baisse, mais il ne s'en soucie pas parce qu'il n'y a évidemment pas de nouvelles données de A quand il est en baisse. D'abord l'interrogation que basé sur l'extraction l'intégration nécessite des coutures très inefficaces, mais la mise en cache HTTP en fait un problème.

en d'autres termes, au lieu d'investir dans un serveur JMS, investissez dans un bon équilibreur de charge HTTP de cache.