Message Queue (MQ) Testing
Download as pptx, pdf2 likes4,182 views
I've covered below topics in current presentation: - Message Queue Introduction - Architecture - Key Capabilities - Simple Use Case - Difference between Web Service and Message Queue - ActiveMQ Portal I'll be adding one more presentation on MQ Testing through Parasoft SOATest. Please feel free to contact if you need more information.
More Related Content
What's hot (20)
Similar to Message Queue (MQ) Testing (20)
![[OSC2016] マイクロサービスを支える MQ を考える](https://cdn.slidesharecdn.com/ss_thumbnails/event-161105054759-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (20)
Message Queue (MQ) Testing
- 1. Message Queue (MQ) Testing UJJWAL GUPTA
- 2. Introduction: MESSAGE QUEUE (MQ) Message queuing allow applications to communicate by sending messages to each other. The message queue provide a temporary message storage when the destination program is busy or not connected. Message Queuing provides guaranteed message delivery, efficient routing, security, and priority- based messaging. “Message Queue provides an asynchronous communications protocol, a system that puts a message onto a message queue does not require an immediate response to continue processing”. Email is probably the best example of asynchronous messaging. When an email is sent can the sender continue processing other things without an immediate response from the receiver. This way of handling messages decouple the producer from the consumer. The producer and the consumer of the message do not need to interact with the message queue at the same time. A Queue is a line of things waiting to be handled - in sequential order starting at the beginning of the line. A message queue is a queue of messages sent between applications. A Message is the data transported between sender and receiver application, it's essentially a byte array with some headers on top.
- 3. MQ Architecture The Basic architecture of Message Queue is simple, there are client applications called producers that create messages and deliver them to the message queue. An other application, called consumer, connect to the queue and get the messages to be processed. Messages placed onto the queue are stored until the consumer retrieves them.
- 4. KEY CAPABILITIES Guaranteed message delivery Message prioritization Message backup and restore Sending messages to multiple destinations Cross-platform integration Message routing Dynamic queue creation Compatible with various transport protocols High-performance computing and high availability Asynchronous Communication
- 5. MQ - Simple Use Case / Purpose Let’s imagine that we’ve a web service that receives many requests every second (i.e., Google), where no request is afford to get lost and all requests needs to be processed by a process that is time consuming. Let’s suppose that our web service always has to be highly available and ready to receive new request instead of being locked by the processing of previous received requests. In this case it is ideal to put a queue between the web service and the processing service. The web service can put the "start processing"-message on a queue and the other process can take and handle messages in order. The two processes will be decoupled from each other and does not need to wait for each other. If you have a lot of requests coming in a short amount of time, the processing system will be able to process them all anyway. The queue will persist requests if their number becomes really huge.
- 6. Web Services vs. Message Queue (MQ) Conditions Web Service Message Queue If Server Fails: Client must take responsibility to handle the error Message Queue persist the message (optionally, even if the machine shutdown) If Server is working again: Client is responsible of resending it It receives the pending message If Server gives a response to the call & the client fails Operation is lost If Client didn't acknowledge the response, the message is persisted Contention You don't have contention, i.e: if million of clients call a web service on one server in a second, most probably your server will go down. You have contention, you can decide how many requests are handled by the server Expect an immediate response from the server You can expect an immediate response from the server, but you can handle asynchronous calls too. You don't expect an immediate synchronous response, but you can implement/simulate synchronous calls.