Meilleur support de messagerie pour les applications SOA en temps réel?

Question

Je travaille sur une application en temps réel mise en œuvre dans un style SOA (lire des composants faiblement couplés connectés via un protocole de messagerie - JMS, MQ ou HTTP).

L'architecte qui a conçu ce système a choisi d'utiliser JMS pour connecter les composants. Ce système est en temps réel, il n’est donc pas nécessaire de mettre les messages en file d’attente en cas de défaillance d’un composant (la transaction expirera tout simplement). De plus, il n'est pas nécessaire de garantir la livraison ou la restauration.

Dans ce cas, l'utilisation de JMS par rapport à un service Web HTTP (vitesse, encombrement des ressources, etc.) présente-t-elle un avantage?

Je pense que l’approche JMS nous oblige à définir une taille de pool de threads (le nombre de composants écoutant un sujet / une file d’attente JMS). Un service HTTP ne conviendrait-il pas mieux la configuration n'est pas nécessaire (un nouveau thread est créé pour chaque requête HTTP, ce qui rend l'application extensible à un nombre "illimité" de requêtes jusqu'à ce que le serveur manque de ressources).

Est-ce que je manque quelque chose?

Answer 1

Je ne suis absolument pas en désaccord avec les remarques de S.Lott, mais voici quelques remarques à prendre en compte concernant les services Web HTTP:

• Vos clients doivent seulement savoir comment communiquer via HTTP - un protocole bien supporté par presque toutes les langues modernes sous une forme ou une autre. JMS, bien que populaire, est plus spécialisé que HTTP et limite donc les langues que vos systèmes interconnectés peuvent utiliser. Ce n’est peut-être pas un problème pour votre système pour le moment, mais devrez-vous ultérieurement connecter d’autres systèmes qui pourraient avoir du mal à supporter la connectivité JMS?

• Les normes telles que WSDL et SOAP que vous pourriez utiliser pour vos services sont bien supportées par de nombreuses langues et il existe de nombreux outils permettant de générer du code pour implémenter les deux extrémités du pipeline (client et serveur). un fichier WSDL, réduisant la quantité de dev que vous aurez à faire. Ces normes simplifient également la définition et la publication des spécifications des données que vous allez transmettre entre vos systèmes, ce que vous devrez probablement faire manuellement à l'aide d'une technologie de file d'attente telle que JMS.

• En revanche, comme l'a souligné S.Lott, JMS vous offre une fonctionnalité que vous jetez à l'aide du protocole HTTP (sans état): garantie de commande & amp; fiabilité; surveillance; l'évolutivité; etc. Êtes-vous sûr de ne pas en avoir besoin et de ne pas en avoir besoin pour l'avenir?

Excellente question, d'ailleurs.

Answer 2

Je pense que cela dépend vraiment de la situation. Là où je travaille, nous prenons en charge les services Remoting, JMS, MQ, HTTP et sFTP. Nous mettons en œuvre une appliance middleware qui parle Remoting, JMS, MQ et HTTP, ainsi qu'un composant logiciel intermédiaire qui parle JMS, MQ et HTTP.

Comme il est mentionné ci-dessus, les normes nous aident à devenir flexibles, mais les formats propriétaires permettent davantage de fonctionnalités.

En un mot, je dirais que vous devez utiliser HTTP pour les appels sans état (qui pourraient éventuellement répondre à presque tous vos besoins), et quels que soient les formats propriétaires dont vous avez besoin pour les appels avec état. Si vous travaillez dans une grande entreprise, une appliance matérielle est généralement bien adaptée à un middleware: compression, cryptage, transformation et traduction rapides, avec un coût total de possession très faible.

Answer 3

Je ne connais pas suffisamment vos exigences, mais vous pouvez peut-être oublier la facilité de gestion, la flexibilité et les performances.

JMS vous permet de surveiller et de gérer la file d'attente. Ce sont des fonctionnalités qui manquent à HTTP, et il faudrait construire plutôt que d’acheter à un fournisseur.

De plus, il existe des files d'attente et des rubriques dans JMS, permettant à plusieurs abonnés d'un seul éditeur. Pas possible en HTTP.

Bien que vous n'ayez peut-être pas besoin de ces éléments dans la version 1.0, vous pouvez les souhaiter ultérieurement.

De plus, JMS peut éventuellement utiliser d'autres mécanismes de transport, tels que les sockets nommés, ce qui réduit les frais généraux s'il n'y a pas toute cette négociation de socket en cours avec (presque) chaque requête.

Answer 4

Si vous suivez la route HTTP et que vous souhaitez prendre en charge plusieurs machines ou une sorte de fiabilité - vous aurez besoin d'un équilibreur de charge capable de détecter les serveurs Web disponibles et de charger des demandes sur ces derniers - puis de basculer sur un autre serveur Web si une boîte / un processus particulier meurt. Les clients effectuant des requêtes HTTP devront également faire face aux échecs des serveurs et aux tentatives de nouvelle tentative dans une boucle.

C’est l’une des principales caractéristiques d’une file de messages - équilibrage fiable de la charge avec basculement et couplage lâche entre producteurs et consommateurs sans qu’ils aient à inclure de logique de nouvelle tentative - pour que votre code client ou serveur ne s’inquiète pas pour cela. un peu la chose. Cela est totalement indépendant du fait que vous souhaitiez ou non la persistance des messages ou que vous souhaitiez utiliser des transactions ACID pour produire / consommer des messages (ce qui peut être très pratique, BTW).

Si vous vous concentrez uniquement sur le côté serveur en utilisant Java - que ce soit des servlets ou des MessageListener / MDB, ils sont en quelque sorte similaires. La différence est l’équilibreur de charge.

La question devrait donc vraiment être: est-ce qu'un courtier JMS est plus facile à configurer & amp; travailler avec que la configuration de votre infrastructure d'équilibrage de charge DNS / NAT / IP / HTTP?

Answer 5

Je suppose que cela dépend de ce que vous entendez par temps réel ... Ni JMS ni HTTP, à mon avis, ne prennent en charge "en temps réel". bien les applications, ce qui signifie qu’elles ne peuvent offrir des performances prévisibles / déterministes, ni hiérarchiser correctement les flux en présence de conflits.

Cela tient en partie au fait que ces technologies reposent sur TCP, qui sérialise tout le trafic dans une seule FIFO, ce qui signifie que différents flux de trafic ne peuvent pas être facilement hiérarchisés. De plus, les temporisateurs TCP ne sont pas faciles à contrôler, ce qui entraîne des blocages et des délais imprévisibles. C'est pourquoi de nombreuses applications de streaming utilisent UDP au lieu de TCP comme protocole sous-jacent.

Un autre problème avec JMS est que les implémentations classiques utilisent un courtier qui centralise la distribution des messages. Ce n'est pas la meilleure architecture pour obtenir des performances déterministes.

Si vous recherchez un middleware capable de vous offrir le type de garantie de fiabilité et la sémantique de publication / abonnement que vous obtenez avec JMS, mais qui a été développé pour s'adapter au domaine des applications en temps réel, je vous recommande de consulter OMG Data. Service de distribution (DDS). Voir dds.omg.org et cet article que j'ai écrit expliquant pourquoi DDS est le meilleur middleware pour implémenter une SOA en temps réel. http://soa.sys-con.com/node/467488