Supporting multiple virtual chatrooms (e.g. with NServiceBus) - azure

Question

I just started to read a lot about service bus architectures and looked more closely into the NServiceBus framework. I am not really getting an idea on how to design multiple private contexts where a set of clients are interested in the copies of the same message (e.g. a chatroom application).
Is the service bus supposed to exist only once or would I create multiple service bus instances, one for each virtual chatroom, and subscribe a message handler instance for each interested client?
Does it have something to do with the concept of topics and subscribes which I already read about in the context of Azure?

Answer 1

Is the service bus supposed to exist only once or would I create multiple service bus instances, one for each virtual chatroom, and subscribe a message handler instance for each interested client?
When using NServiceBus, you will configure a bus for each endpoint that you create. You could think of an endpoint as a service which handles certain messages. Endpoints aren't dynamic, they need to specify a name so that other endpoints can be configured to send messages to or receive messages from them.
It depends on what the requirements of your system are, but I'm assuming that a virtual chatroom is something that you can generate dynamically and/or remove when it's no longer in use.
Does it have something to do with the concept of topics and subscribes which I already read about in the context of Azure?
NServiceBus and Azure Service Bus both provide the infrastructure to do pub/sub.
I am not really getting an idea on how to design multiple private contexts where a set of clients are interested in the copies of the same message
What exactly do you mean by multiple private contexts? I am understanding your question as how to establish a relationship between a client and a chatroom. The part that is missing from your description is persistence, i.e. storing the relationship between a client and a chatroom.
Using NServiceBus as an example, you could have a ClientService that handles messages regarding any actions that clients take and a ChatroomService that handles messages regarding actions that occur within Chatrooms. Then the workflow could go:
Client enters chatroom (client sends command to client service)
ClientService adds information to Client object and updates it (persistence)
ClientService sends command to ChatroomService to update the list of clients associated with the corresponding chat room. (command)
Chatroom service updates list of subscribing clients (persistence)
Another client creates a Post in the chat room. (client sends command to ClientService)
ClientService sends command to ChatroomService with new Post and ID of client who created it, and the ID of the chatroom it was sent to (command)
ChatroomService adds the Post to the list of Posts in the corresponding chatroom (persistence)
ChatroomService generates events for all other clients in the list subscribing to the corresponding chatroom (publish)
ClientService handles the events raised by ChatroomService and distributes the Post to the other subscribed clients. (subscribe)
I haven't actually created a chat room application, so this may not be the best design for your idea but it provided a means of describing how you can use NServiceBus to create your application. You can set up services with endpoints that handle messages corresponding to objects in your system. With this or similar design, you have separation of concern and can scale your services as required based on the traffic that each object type must handle.
Editing to add a more specific example based on question in comments
Note: changed all references of text message to Post so that theres no ambiguity between chat message and IMessage in NServiceBus. I've been using terms command and event on purpose. In NServiceBus, ICommand is a type of message that can only be sent to 1 endpoint, whereas IEvent is a type of message that can be published and subscribed to by many endpoints.
Apologies if the example wasn't clear. What I was trying to convey is that you can store the relationship between Clients and Chatrooms so that when a Chatroom gets a new Post, it can be distributed to only the Clients that are related to it. Imagine that you have a chatroom CR and 3 clients A, B, and C that are all in CR. Also, lets say we have the following classes:
class Chatroom
{
Guid Id { get; set; }
List<Client> Subscribers { get; set; }
List<Posts> Posts { get; set; }
}
class Client
{
Guid Id { get; set; }
List<Chatroom> Chatrooms { get; set; }
ConnectionInfo Info { get; set; }
}
class Post
{
Guid Id { get; set; }
Guid ClientId { get; set; }
Guid ChatroomId { get; set; }
string Text { get; set; }
}
class NewPostCommand : ICommand
{
Post NewPost { get; set; }
}
class NewChatroomPostEvent : IEvent
{
Post NewPost { get; set; }
Chatroom Chatroom { get; set; }
List<Client> Subscribers { get; set; }
}
A creates a Post to CR, and this is implemented using a HTTP call from the client to an API. The API is part of an NServiceBus service that serves as the ClientService. The API call creates a Post that contains the text, A.Id, and CR.Id.
ClientService sends a NewPostCommand to ChatroomService with the Post that was just created.
ChatroomService receives NewPostCommand and passes it to the appropriate handler.
Handler searches for the corresponding Chatroom (CR) in your database using ChatroomId on the Post. The new Post is added to CR.Posts and updates the database.
Handler gets the list of CR.Clients minus Post.ClientId from the CR (resulting in B and C).
Handler publishes a new NewChatroomPostEvent that contains the Post, Chatroom and Subscribers.
ClientService subscribes to NewChatroomPostEvent, receives the message and passes it to the approriate handler.
ClientService has all the functionality for communicating with Clients (using Client.Info) and sends the new Post to each client in the NewChatroomPostEvent.Subscribers list (B and C).
Now that we've walked through the message flow of a new post, you can imagine how you would handle adding and removing subscribers from each chatroom. A client would send a message to the HTTP API when it enters or leaves a chatroom, the ClientService sends a message to the ChatroomService, which would update the appropriate Chatroom.Subscribers list. Hopefully this clarifies how you control which clients are sent updates when new posts arrive.