Design consideration to use MQ for Notifications and Reporting Request.

Introduction

This wiki page encourage the use of MQ instead of a Worker process for Notification and reporting request. MQ reduces unnecessary threads (Notification Thread) and also reduce memory consumption. The bottom line is the Notification and reporting request are REST based and it makes complete sense to exercise a solution which horizontally scalable, reliable and fault tolerant.

Why MQ ?

1. ActiveMQ offers proven scalaibility,availability, and performance that will grow with the customer's requirements. You may end up bringing down your server if one or more of the Notification Thread is in a deadlock situation.
2. The Active MQ message broker is writtern in langugae and its very portable.
3. ActiveMQ can facilitate a wide range of general purpose solutions via multiple messaging pattern.
4. ActiveMQ is an OSS based Service Oriented Architecture (SOA) deployment. Features
5. Active MQ is fast and feature rich open source JMS message broker primarily targeted for loosely coupled distributed application environments. Its provides persistence and once and only once assurance message delivery and can be highly scalable through clustering ,peer to peer federated network.
6. Active Message Queing supports both the point to point and publisher and subscribe messaging models.
7. ActiveMQ provides high availablity and high performance clustering and general purpose asynchronous mesaging.
8. Active MQ Support variety of transport protocol such as TCP,SSL,UDP and Multicast.
9. Embedded and standlone broker mechanism one of the unique featues of Active MQ.
10. One advantage of using an embedded broker is that if the network fails , its embedded clients can still use the services of the broker.
11. Strutucred architecture provide more binded and reliable messgae queueing mechanism.
12. Best for Large Resource Mangement architecture.
13. Authentication using JNDI-LDAP -SSL
14. Active MQ also provides scheduling mechanism so we could deliver the message based on a schedule too.

Design

A notification/report request comes into HMIS in the form of a REST call which is pushed into the Queue. We could have 2 different Queues 1 for notification and the other one for reporting which will be part of a fancy Queue cluster which can be horizotally scalable via a configuration change.We shall also have 2 error queues one for notification and reports.Active MQ has loggingInterceptor which will provide us enough logging for messages. The message consumers shall perform the notification/reporting tasks using the Notification/Reports Builder process.The messages from the error queue can be processed by another process which will perform a configurable number of retries before notifying the system administrator.

Conclusion

The bottom line here is MQs are more scalable,reliable, fault tolerant and portable solution when compared to a bunch of threads waiting to act upon something inserted inside a DB.