eBook - ePub
RabbitMQ in Action
Jason Williams
This is a test
Partager le livre
- English
- ePUB (adapté aux mobiles)
- Disponible sur iOS et Android
eBook - ePub
RabbitMQ in Action
Jason Williams
DĂ©tails du livre
Aperçu du livre
Table des matiĂšres
Citations
Ă propos de ce livre
RabbitMQ in Action is a fast-paced run through building and managing scalable applications using the RabbitMQ messaging server. It starts by explaining how message queuing works, its history, and how RabbitMQ fits in. Then it shows you real-world examples you can apply to your own scalability and interoperability challenges.
Foire aux questions
Comment puis-je résilier mon abonnement ?
Il vous suffit de vous rendre dans la section compte dans paramĂštres et de cliquer sur « RĂ©silier lâabonnement ». Câest aussi simple que cela ! Une fois que vous aurez rĂ©siliĂ© votre abonnement, il restera actif pour le reste de la pĂ©riode pour laquelle vous avez payĂ©. DĂ©couvrez-en plus ici.
Puis-je / comment puis-je télécharger des livres ?
Pour le moment, tous nos livres en format ePub adaptĂ©s aux mobiles peuvent ĂȘtre tĂ©lĂ©chargĂ©s via lâapplication. La plupart de nos PDF sont Ă©galement disponibles en tĂ©lĂ©chargement et les autres seront tĂ©lĂ©chargeables trĂšs prochainement. DĂ©couvrez-en plus ici.
Quelle est la différence entre les formules tarifaires ?
Les deux abonnements vous donnent un accĂšs complet Ă la bibliothĂšque et Ă toutes les fonctionnalitĂ©s de Perlego. Les seules diffĂ©rences sont les tarifs ainsi que la pĂ©riode dâabonnement : avec lâabonnement annuel, vous Ă©conomiserez environ 30 % par rapport Ă 12 mois dâabonnement mensuel.
Quâest-ce que Perlego ?
Nous sommes un service dâabonnement Ă des ouvrages universitaires en ligne, oĂč vous pouvez accĂ©der Ă toute une bibliothĂšque pour un prix infĂ©rieur Ă celui dâun seul livre par mois. Avec plus dâun million de livres sur plus de 1 000 sujets, nous avons ce quâil vous faut ! DĂ©couvrez-en plus ici.
Prenez-vous en charge la synthÚse vocale ?
Recherchez le symbole Ăcouter sur votre prochain livre pour voir si vous pouvez lâĂ©couter. Lâoutil Ăcouter lit le texte Ă haute voix pour vous, en surlignant le passage qui est en cours de lecture. Vous pouvez le mettre sur pause, lâaccĂ©lĂ©rer ou le ralentir. DĂ©couvrez-en plus ici.
Est-ce que RabbitMQ in Action est un PDF/ePUB en ligne ?
Oui, vous pouvez accĂ©der Ă RabbitMQ in Action par Jason Williams en format PDF et/ou ePUB ainsi quâĂ dâautres livres populaires dans Computer Science et Open Source Programming. Nous disposons de plus dâun million dâouvrages Ă dĂ©couvrir dans notre catalogue.
Informations
Sujet
Computer ScienceSous-sujet
Open Source ProgrammingChapter 1. Pulling RabbitMQ out of the hat
This chapter covers
- The need for an open protocolâAMQP
- Brief history of RabbitMQ
- Installing RabbitMQ
- First programâHello World
We live in a world where real-time information is constantly available, and the applications we write need easy ways to be routed to multiple receivers reliably and quickly. More important, we need ways to change who gets the information our apps create without constantly rewriting them. Too often, our applicationâs information becomes siloed, inaccessible by new programs that need it without rewriting (and probably breaking) the original producers. You might be saying to yourself, âSure, but how can message queuing or RabbitMQ help me fix that?â Letâs start by asking whether the following scenario sounds familiar.
Youâve just finished implementing a great authentication module for your companyâs killer web app. Itâs beautiful. On every page hit, your code efficiently coordinates with the authentication server to make sure your users can only access what they should. Youâre feeling smug, because every page hit on your companyâs worldclass avocado distribution website activates your code. Thatâs about when your boss walks in and tells you the company needs a way to log every successful and failed permission attempt so that it can be data mined. After you lightly protest that thatâs the job of the authentication server, your boss not so gently informs you that thereâs no way to access that data. The authentication server logs it in a proprietary format; hence this is now your problem. Mulling over the situation causes a four-aspirin headache, as you realize youâre going to have to modify your authentication module and probably break every page in the process. After all, that wonderful code of yours touches every access to the site. Letâs stop for a moment though. Letâs punch the Easy button and time warp back to the beginning of the development of that great auth module. Letâs assume you leveraged message queuing heavily in its design from day one.
With RabbitMQ in place, you brilliantly leveraged message queuing to decouple your module from the authentication server. With every page request, your authentication module is designed to place an authorization request message into RabbitMQ. The authentication server then listens on a RabbitMQ queue that receives that request message. Once the request is approved, the auth server puts a reply message back into RabbitMQ where itâs routed to the queue that your module is listening on. In this world, your bossâs request doesnât faze you. You realize you donât need to touch your module or even write a new one. All you need to do is write a small app that connects to RabbitMQ and subscribes to the authorization requests your auth module is already publishing. No code changes. Nothing you already wrote knows anything has changed. Itâs so simple a smile almost breaks out on your face. Thatâs the power of messaging to make your day job easier.
Message queuing is simply connecting your applications together with messages that are routed between them by a message broker like RabbitMQ. Itâs like putting in a post office just for your applications. The reality is that this approach isnât just a solution to the real-time problems of the financial industry; itâs a solution to the problems we all face as developers every day. We, the authors, donât come from a financial services background. We had no idea what âenterprise messagingâ was when we needed to scale. We were simply devs like you with an itch that needed scratching: an itch to deal with real-time volumes of information and route it to multiple consumers quickly. We needed to do it all without blocking the producers of that information ... and without them needing to know who the final consumers might be. RabbitMQ helped us to solve those common problems easily, and in a standards-based way that ensured any app of ours could talk to any other app, be it Python, PHP, or even Scala.
Over the next few chapters, weâll take you on a ride. It starts by explaining how message queuing works, its history, and how RabbitMQ fits in. Then weâll take you all the way through to real-world examples you can apply to your own scalability and interoperability challenges ... ending with how to make Rabbit purr like a well-oiled machine in a âdowntime is not acceptable!â environment.
This is the book we wished was on the shelves when we entered the messaging wilderness. We hope it will help you benefit from our experience and battle scars and free you to make amazing applications with less pain. Before weâre done in this chapter, youâll have a short history of messaging under your belt, and RabbitMQ up and running. Without further ado, letâs take a look at where all this messaging fun started.
1.1. Living in other peopleâs dungeons
The world of message queuing didnât start out the dank and cramped one it is today, with most folks subservient to lock-in overlords. It started with a ray of light in an otherwise byzantine software landscape. It was 1983 when a 26-year-old engineer from Mumbai had a radical question: why wasnât there a common software âbusââa communication system that would do the heavy lifting of communicating information from one interested application to another? Coming from an education in hardware design at MIT, Vivek RanadivĂ© envisioned a common bus like the one on a motherboard, only this would be a software bus that applications could plug into. (See http://hbswk.hbs.edu/archive/1884.html.) Thus, in 1983 Teknekron was born. A freshly minted Harvard MBA in his hand and this powerful idea in his head, Vivek started plowing a path that would help developers everywhere.
Having the idea was one thing, but finding a killer application for it was something completely different. It was at Goldman Sachs in 1985 that RanadivĂ© found his first customer and the problem his software bus was born to solve: financial trading. A traderâs stall at that time was packed to the brim with different terminals for each type of information the trader needed to do his job. Teknekron saw an opportunity to replace all those terminals and their siloed applications. In their place would be RanadivĂ©âs software bus. What would remain would be a single workstation whose display programs could now plug into the Teknekron software bus as consumers and allow the trader to âsubscribeâ to the information the trader wanted to see. Publishsubscribe (PubSub) was born, as was the worldâs first modern message queuing software: Teknekronâs The Information Bus (TIB).
It didnât take long for this model of data transfer to find many more killer uses. After all, an application publishing data and an application consuming it no longer had to directly connect to each other. Heck, they didnât even have to know each other existed. What Teknekronâs TIB allowed application developers to do was establish a set of rules for describing message content. As long as the messages were published according to those rules, any consuming application could subscribe to a copy of the messages tagged with topics it was interested in. Producers and consumers of information could now be completely decoupled and flexibly mixed on-the-fly. Either side of the PubSub model (producer/consumer) was completely interchangeable without breaking the opposite side. The only thing that needed to remain stable was the TIB software and the rules for tagging and routing the information. Since the financial trading industry is full of information with a constantly changing set of interested folks, TIB spread like wildfire in that sector. It was also noticed by telecommunications and especially news organizations, who also had information that needed timely delivery to a dynamically changing set of interested consumers. Thatâs why mega news outfit Reuters purchased Teknekron in 1994.
Meanwhile, this burgeoning new segment of enterprise software didnât go unnoticed by Big Blue. After all, many of IBMâs biggest customers were in the financial services industry. Also, Teknekronâs TIB software was frequently run on IBM hardware and operating systems ... all without the boys in White Plains getting a cut. Thus, in the late â80s IBM began research into developing their own message-queuing software, leveraging their extensive experience in information delivery from developing DB2 (see http://www-01.ibm.com/software/integration/wmq/MQ15Anniversary.html). Development began in 1990 at IBMâs Hursely Park Laboratories near Winchester, United Kingdom. What emerged three years later was the IBM MQSeries family of messagequeuing server software. In the 17 years since, MQSeries has evolved into WebSphere MQ and is today the dominant commercial message-queuing platform. During that time, RanadivĂ©âs TIB hardly disappeared into the bowels of Reuters. Instead it has remained the other major player in enterprise messaging, thriving through a renaming to Rendezvous and Teknekronâs re-emergence as an independent company in the form of TIBCO in 1997. The same year, Microsoftâs first crack at the messaging market emerged: Microsoft Message Queue (MSMQ).
Through all of this evolution, message queuing (MQ) software primarily remained the domain of large-budgeted organizations with a need for reliable, decoupled, realtime message delivery. Why didnât MQ find a larger audience? How did it survive the information boom that was the late â90s internet bubble without exper...