Fixes typos in introduction.txt

docs/userguide/introduction.rst

@@ -2,31 +2,33 @@ What is messaging?
 ==================
 
 In times long ago people didn't have email.
-They had the postal service, which would couragely deliver mail,
+They had the postal service, which with great courage would deliver mail
 from hand to hand all over the globe.  Soldiers deployed at wars far away could only
 communicate with their families through the postal service, and
 posting a letter would mean that the recipient wouldn't actually
-receive the letter until weeks or months, and sometimes years later.
+receive the letter until weeks or months, sometimes years later.
+
 It's hard to imagine this today when people are expected to be available
 for phone calls every minute of the day.
 
 So humans need to communicate with each other, this shouldn't
-be news to anyone, but why would applications want to send
-messages?
+be news to anyone, but why would applications?
 
-One example is the banks.
-When you transfer money from one bank to another, this is sent
-as a message to the banks messaging central. Banks
-need to send and receive millions and millions of these
+One example is banks.
+When you transfer money from one bank to another, your bank sends
+a message to the banks messaging central.  The messaging central
+then record and coordinate the transaction.  Banks
+need to send and receive millions and millions of
 messages every day, and losing a single message would mean either losing
 your money (bad) or the banks money (very bad)
 
-Another is the stock exchange, which also have a need
-for very high message througputs and strict reliability requirements.
+Another example is the stock exchanges, which also have a need
+for very high message throughputs and have strict reliability
+requirements.
 
 Email is a great way for people to communicate.  It is much faster
 than using the postal service, but still using email as a means for
-programs to communicate would be like the solider above, waiting
+programs to communicate would be like the soldier above, waiting
 for signs of life from his girlfriend back home.
 
 Messaging Scenarios
@@ -36,28 +38,40 @@ Messaging Scenarios
 
   The request/reply pattern works like the postal service example.
   A message is addressed to a single recipient, with a return address
-  printed on the back.  The receipient may or may not reply to the
+  printed on the back.  The recipient may or may not reply to the
   message by sending it back to the original sender.
 
   Request-Reply is achieved using *direct* exchanges.
 
 * Broadcast
 
+  In a broadcast scenario a message is sent to all parties.
+  This could be none, one or many recipients.
+
   Broadcast is achieved using *fanout* exchanges.
 
 * Publish/Subscribe
 
-  Pubsub is achieved using *topic* exchanges.
+  In a publish/subscribe scenario producers publish messages
+  to topics, and consumers subscribe to the topics they are
+  interested in.
+
+  If no consumers subscribe to the topic, then the message
+  will not be delivered to anyone.  If several consumers
+  subscribe to the topic, then the message will be delivered
+  to all of them.
+
+  Pub-sub is achieved using *topic* exchanges.
 
 Reliability
 ===========
 
 For some applications reliability is very important.  Losing a message is
-a critical situtation that must never happen.  For other applications
+a critical situation that must never happen.  For other applications
 losing a message is fine, it can maybe recover in other ways,
 or the message is resent anyway as periodic updates.
 
-AMQP comes with two persistency modes:
+AMQP defines two built-in delivery modes:
 
 * persistent
 
@@ -70,6 +84,5 @@ AMQP comes with two persistency modes:
     restart.
 
 Transient messaging is by far the fastest way to send and receive messages,
-so persistency comes with a price, but a necessary cost.
-
-
+so having persistent messages comes with a price, but for some
+applications this is a necessary cost.