Bonjour à tous,
Quelqu'un peut il m'expliquer dans un français simple à quoi sert RabbitMQ?
J'ai vu plein de tuto en francais comme en anglais mais je n'y comprends rien de rien.
Ca fait pourtant presque 10 ans que je fais de l'informatique et plus précisément du système et réseau mais je ne comprends rien à cette histoire de message …
Qu'appelle t'on des messages? Est-ce des mails( j'ai du louper le coche car j'en étais resté à SMTP)?
A quoi servent'ils ?
Comment fonctionne rabbitMQ?
Merci de vos explications
# Un genre de dbus, à vue de nez
Posté par freem . Évalué à 5.
Le terme message est a prendre au bas niveau, j'ai l'impression, genre un message UCP (pas TCP, vu que c'est des flux). Tu balances tes données au serveur, les applications qui comprennent de quoi il s'agit les récupèrent quand elles veulent. Si j'ai bien compris.
Si tu aimes les buzzwords, c'est le genre de gadget qui aide à vendre les applications REST.
# C'est un courtier
Posté par chimrod (site web personnel) . Évalué à 5.
Comme dit plus haut, c'est un serveur de message. Mais c'est a prendre dans le cadre d'échange entre applications avec une haute charge de communication, un bus quoi. Sauf qu'elle peut garantir qu'aucun message ne sera perdu, et une bonne montée en charge.
Le paramétrage consiste ensuite à construire des routes pour aiguiller les messages (un peu comme avec syslog : on envoi le contenu vers un fichier, vers une base de données, vers un programme), ou appliquer des patterns sur le message (transformation, duplication, agrégation…).
Le cas de REST n'est qu'un exemple d'utilisation (chaque commande permettant la diffusion d'un message qui sera géré par une application dédiée, comme ça on découple le frontal du traitement), mais on peut l'envisager dans le cadre d'une application qui a besoin de répartition de charge (il suffit de mettre en place deux instances qui écoutent la même file), ou faire communiquer des applications différentes.
# Merci pour vos explications
Posté par Orwell . Évalué à 1.
Merci beaucoup pour vos explications, c'est un peu plus clair.
Est-ce que vous des exemples?
Dans vos explications vous parlez de Bus et de REST.
REST c'est une sorte de web service?
Et BUS je comprends donc que c'est un canal de communication entre 2 applications, c'est bien ça ?
Est-ce que ça peut donc être un autre moyen de faire communiquer des applications qui ne seraient pas conçu avec le même langage? exemple une appli en java avec une autre en php?
Merci de vos éclaircissements
[^] # Re: Merci pour vos explications
Posté par chimrod (site web personnel) . Évalué à 0.
REST c'est à l'opposé du web-service !
(Mode troll)Les ws réinventent une couche d'échange au sein de la couche http, alors que rest utilise juste http correctement.(/Mode troll)
Je ne connais pas PHP, donc je ne peux pas répondre sur ce point, mais oui, il est possible de faire communiquer des applications dans des langages différents.
Tiens un exemple qui permet de faire de la distribution de tâche en python : http://www.celeryproject.org/
[^] # Re: Merci pour vos explications
Posté par freem . Évalué à 3.
Non, REST est un style d'architecture. Je te conseille d'aller voir l'article de wikipedia. Les web service, c'est bâti uniquement sur du HTTP et, pire, HTML+JSon. REST peut très bien utiliser un protocole maison directement bâti sur TCP ou même UDP.
Pas entre 2 applications, mais entre plusieurs (pas forcément juste deux, donc) composants. Au début c'était utilisé juste en électronique (et donc au niveau carte-mère & co) mais on l'utilise aussi pour les logiciels maintenant. L'idée générale est la même de toute façon: permettre à plusieurs composants d'un même système de communiquer ensemble.
Il faut juste qu'elles soient capables de communiquer dans le format/protocole adéquat. Le langage n'a absolument aucun impact sur ça. Que tu ouvres une connexion réseau en Java, en PHP, en C, voire même en ASM, c'est la même chose, l'important c'est ce que tu demandes à la carte réseau d'envoyer. De toute façon, le code de ton application fini toujours à un moment ou l'autre en binaire.
[^] # Re: Merci pour vos explications
Posté par BAud (site web personnel) . Évalué à 3.
o_O pardon ? XML / SOAP tu voulais dire j'imagine ? L'intérêt étant d'avoir un WSDL facilitant la publication et une XSD facilitant la validation. C'est ce que j'ai le plus vu déployé en tout cas, même si ReST a permis de renouveler le genre et notamment amener aux Web API qui privilégient le ReST / JSON, plus léger, plus efficace.
Bon, après cela peut varier selon l'expérience de chacun, on va dire.
Concernant les bus, je te rejoins, l'image du bus en électronique me paraissant assez bonne, même si elle focalise sur un mécanisme d'acheminement (routage mais pas seulement) ; il y a tout de même les volets orchestration et transformation qui sont au cœur des EAI/ESB/ETL (oui, je range les ETL dans le volet bus depuis 5-6 ans… même si ce n'est généralement pas la norme).
et sinon, il y a le Business Loto pour compléter l'argumentaire :-)
[^] # Re: Merci pour vos explications
Posté par freem . Évalué à 2.
Hum, je ne voulais pas dire HTTP ça c'est certain (après tout, j'ose espérer que de nos jours y'a du httpS >:] ), et pour HTML je pensais plus XHTML (basé sur XML donc), mais j'ai tendance à confondre les deux de nos jours (reste-t-il encore du HTML non XHTML?). Quant au JS, j'admets avoir un poil trollé.
Je n'en ai pas des masses dans le web, je le reconnais. S'il y a un truc qui ne m'attire vraiment pas, c'est bien le tas de techno blindé de sables mouvants qu'est le web. Bon je suppose qu'un jour je devrais m'y mettre un minimum sérieusement, vu que c'est le marché le plus simple d'accès.
Si tu trouves mieux, fait moi savoir :)
Pour les EAI/ESB/ETL : aucune idée de ce que c'est, mes connaissances d'électroniques remontent au bac, il y a 10 ans, et je n'ai jamais eu l'occasion de les utiliser pour de vrai depuis (même si je garde amoureusement quelques bouquins de cours, et que le jour ou j'aurai a nouveau l'occase de causer routage je serai bien heureux). Je n'ose même pas chercher sur le net ce qu'ils signifient, vu les acronymes, ça risque de flooder sur des trucs qui n'ont rien a voir.
Héhé… je crois que quand j'aurai retrouvé (re-cherché déjà) du taf, si l'ambiance est bonne, je vais me monter un serveur perso pour ce jeu, pour les réunions, ça pourrait être fun! Encore faut-il avoir un expert en buzzword pour mettre à jour la base de données (ajouter ET supprimer les bw au fur et à mesure des tendances…).
# En français ?
Posté par steph1978 . Évalué à 2.
https://fr.wikipedia.org/wiki/Message-oriented_middleware
intergiciel (aïe!) orienté messages comme dirai un québécois.
En effet, ça s'apparente à du mail.
Sauf que le mail est plus orienté être humain et le MQ est plus orienté communication entre applications.
Au lieu d'avoir un serveur mail avec des boites mails et des conversations, tu as un MQS avec des files (queues) et des sujets (topics).
Plusieurs
patternspatrons d'intégration d'applications s’appuient sur cette brique.Bref le sujet est trop vaste pour tout décrire ici mais les ressources en ligne ne manquent pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.