Case study: Initial design of the CSN

The following diagram extends the general overview of a CSN in regard to a client browser that provides client-side interaction with the system:

Now that we have seen how to implement messaging patterns in RabbitMQ, we can apply this to implement the following:

• Global event handling; we can use the default exchange along with a single queue called event_queue. The worker nodes as illustrated in the preceding diagram will subscribe to the event_queue and start handling events for long-running tasks in a round-robin fashion; the CompetingReceiver class is a proper alternative for the implementation of a point-to-point receiver on the worker nodes.
• Chat service; each user of the system will have a separate queue that will receive messages for that queue. You can use a variant—a point-to-point channel—to send a message from one user to the other. For group chatting, you can have a fanout or topic exchange (based on the implementation strategy) for the particular group that will be used to deliver messages to all use queues.

To implement a chat client that is displayed in the client's browser you have a number of alternatives, such as:

• Using the WebSocket protocol, since it allows two-way communication between the browser and the CSN frontend server; the frontend server sends the message to the RabbitMQ server for further handling. In this case, you may need to create a mapping between the WebSocket endpoints and AMQP queues.
• Implementing a browser plugin that makes use of the AMQP protocol directly; this allows you to connect clients directly to the RabbitMQ broker.
• Ajax requests with long polling; this option is not preferred since it implies a heavy footprint on network bandwidth but it is still another alternative.